Changelog in Linux kernel 4.19.322

 
ACPI: processor: Fix memory leaks in error paths of processor_add() [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Wed May 29 14:34:32 2024 +0100

    ACPI: processor: Fix memory leaks in error paths of processor_add()
    
    [ Upstream commit 47ec9b417ed9b6b8ec2a941cd84d9de62adc358a ]
    
    If acpi_processor_get_info() returned an error, pr and the associated
    pr->throttling.shared_cpu_map were leaked.
    
    The unwind code was in the wrong order wrt to setup, relying on
    some unwind actions having no affect (clearing variables that were
    never set etc).  That makes it harder to reason about so reorder
    and add appropriate labels to only undo what was actually set up
    in the first place.
    
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Gavin Shan <gshan@redhat.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20240529133446.28446-6-Jonathan.Cameron@huawei.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: processor: Return an error if acpi_processor_get_info() fails in processor_add() [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Wed May 29 14:34:31 2024 +0100

    ACPI: processor: Return an error if acpi_processor_get_info() fails in processor_add()
    
    [ Upstream commit fadf231f0a06a6748a7fc4a2c29ac9ef7bca6bfd ]
    
    Rafael observed [1] that returning 0 from processor_add() will result in
    acpi_default_enumeration() being called which will attempt to create a
    platform device, but that makes little sense when the processor is known
    to be not available.  So just return the error code from acpi_processor_get_info()
    instead.
    
    Link: https://lore.kernel.org/all/CAJZ5v0iKU8ra9jR+EmgxbuNm=Uwx2m1-8vn_RAZ+aCiUVLe3Pw@mail.gmail.com/ [1]
    Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Gavin Shan <gshan@redhat.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20240529133446.28446-5-Jonathan.Cameron@huawei.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
af_unix: Remove put_pid()/put_cred() in copy_peercred(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Jun 20 13:56:22 2024 -0700

    af_unix: Remove put_pid()/put_cred() in copy_peercred().
    
    [ Upstream commit e4bd881d987121dbf1a288641491955a53d9f8f7 ]
    
    When (AF_UNIX, SOCK_STREAM) socket connect()s to a listening socket,
    the listener's sk_peer_pid/sk_peer_cred are copied to the client in
    copy_peercred().
    
    Then, the client's sk_peer_pid and sk_peer_cred are always NULL, so
    we need not call put_pid() and put_cred() there.
    
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: hda/conexant: Add pincfg quirk to enable top speakers on Sirius devices [+ + +]
Author: Christoffer Sandberg <cs@tuxedo.de>
Date:   Tue Aug 27 12:25:40 2024 +0200

    ALSA: hda/conexant: Add pincfg quirk to enable top speakers on Sirius devices
    
    commit 4178d78cd7a86510ba68d203f26fc01113c7f126 upstream.
    
    The Sirius notebooks have two sets of speakers 0x17 (sides) and
    0x1d (top center). The side speakers are active by default but
    the top speakers aren't.
    
    This patch provides a pincfg quirk to activate the top speakers.
    
    Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Cc: stable@vger.kernel.org
    Link: https://patch.msgid.link/20240827102540.9480-1-wse@tuxedocomputers.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: Add input value sanity checks to HDMI channel map controls [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Jun 16 09:34:47 2024 +0200

    ALSA: hda: Add input value sanity checks to HDMI channel map controls
    
    [ Upstream commit 6278056e42d953e207e2afd416be39d09ed2d496 ]
    
    Add a simple sanity check to HD-audio HDMI Channel Map controls.
    Although the value might not be accepted for the actual connection, we
    can filter out some bogus values beforehand, and that should be enough
    for making kselftest happier.
    
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/20240616073454.16512-7-tiwai@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Fix gpf in snd_usb_pipe_sanity_check [+ + +]
Author: Hillf Danton <hdanton@sina.com>
Date:   Thu Sep 5 15:38:13 2024 +0300

    ALSA: usb-audio: Fix gpf in snd_usb_pipe_sanity_check
    
    [ Upstream commit 5d78e1c2b7f4be00bbe62141603a631dc7812f35 ]
    
    syzbot found the following crash on:
    
      general protection fault: 0000 [#1] SMP KASAN
      RIP: 0010:snd_usb_pipe_sanity_check+0x80/0x130 sound/usb/helper.c:75
      Call Trace:
        snd_usb_motu_microbookii_communicate.constprop.0+0xa0/0x2fb  sound/usb/quirks.c:1007
        snd_usb_motu_microbookii_boot_quirk sound/usb/quirks.c:1051 [inline]
        snd_usb_apply_boot_quirk.cold+0x163/0x370 sound/usb/quirks.c:1280
        usb_audio_probe+0x2ec/0x2010 sound/usb/card.c:576
        usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
        really_probe+0x281/0x650 drivers/base/dd.c:548
        ....
    
    It was introduced in commit 801ebf1043ae for checking pipe and endpoint
    types. It is fixed by adding a check of the ep pointer in question.
    
    BugLink: https://syzkaller.appspot.com/bug?extid=d59c4387bfb6eced94e2
    Reported-by: syzbot <syzbot+d59c4387bfb6eced94e2@syzkaller.appspotmail.com>
    Fixes: 801ebf1043ae ("ALSA: usb-audio: Sanity checks for each pipe and EP types")
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Sanity checks for each pipe and EP types [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Sep 5 15:38:07 2024 +0300

    ALSA: usb-audio: Sanity checks for each pipe and EP types
    
    [ Upstream commit 801ebf1043ae7b182588554cc9b9ad3c14bc2ab5 ]
    
    The recent USB core code performs sanity checks for the given pipe and
    EP types, and it can be hit by manipulated USB descriptors by syzbot.
    For making syzbot happier, this patch introduces a local helper for a
    sanity check in the driver side and calls it at each place before the
    message handling, so that we can avoid the WARNING splats.
    
    Reported-by: syzbot+d952e5e28f5fb7718d23@syzkaller.appspotmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
apparmor: fix possible NULL pointer dereference [+ + +]
Author: Leesoo Ahn <lsahn@ooseel.net>
Date:   Wed May 8 01:12:29 2024 +0900

    apparmor: fix possible NULL pointer dereference
    
    [ Upstream commit 3dd384108d53834002be5630132ad5c3f32166ad ]
    
    profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made
    from __create_missing_ancestors(..) and 'ent->old' is NULL in
    aa_replace_profiles(..).
    In that case, it must return an error code and the code, -ENOENT represents
    its state that the path of its parent is not existed yet.
    
    BUG: kernel NULL pointer dereference, address: 0000000000000030
    PGD 0 P4D 0
    PREEMPT SMP PTI
    CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
    RIP: 0010:aafs_create.constprop.0+0x7f/0x130
    Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
    RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
    Call Trace:
     <TASK>
     ? show_regs+0x6d/0x80
     ? __die+0x24/0x80
     ? page_fault_oops+0x99/0x1b0
     ? kernelmode_fixup_or_oops+0xb2/0x140
     ? __bad_area_nosemaphore+0x1a5/0x2c0
     ? find_vma+0x34/0x60
     ? bad_area_nosemaphore+0x16/0x30
     ? do_user_addr_fault+0x2a2/0x6b0
     ? exc_page_fault+0x83/0x1b0
     ? asm_exc_page_fault+0x27/0x30
     ? aafs_create.constprop.0+0x7f/0x130
     ? aafs_create.constprop.0+0x51/0x130
     __aafs_profile_mkdir+0x3d6/0x480
     aa_replace_profiles+0x83f/0x1270
     policy_update+0xe3/0x180
     profile_load+0xbc/0x150
     ? rw_verify_area+0x47/0x140
     vfs_write+0x100/0x480
     ? __x64_sys_openat+0x55/0xa0
     ? syscall_exit_to_user_mode+0x86/0x260
     ksys_write+0x73/0x100
     __x64_sys_write+0x19/0x30
     x64_sys_call+0x7e/0x25c0
     do_syscall_64+0x7f/0x180
     entry_SYSCALL_64_after_hwframe+0x78/0x80
    RIP: 0033:0x7be9f211c574
    Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
    RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574
    RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004
    RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000
    R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80
    R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30
     </TASK>
    Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas
    CR2: 0000000000000030
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:aafs_create.constprop.0+0x7f/0x130
    Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
    RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
    
    Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: libata: Fix memory leak for error path in ata_host_alloc() [+ + +]
Author: Zheng Qixing <zhengqixing@huawei.com>
Date:   Thu Aug 22 11:30:50 2024 +0800

    ata: libata: Fix memory leak for error path in ata_host_alloc()
    
    commit 284b75a3d83c7631586d98f6dede1d90f128f0db upstream.
    
    In ata_host_alloc(), if devres_alloc() fails to allocate the device host
    resource data pointer, the already allocated ata_host structure is not
    freed before returning from the function. This results in a potential
    memory leak.
    
    Call kfree(host) before jumping to the error handling path to ensure
    that the ata_host structure is properly freed if devres_alloc() fails.
    
    Fixes: 2623c7a5f279 ("libata: add refcounting to ata_host")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ata: pata_macio: Use WARN instead of BUG [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Aug 20 13:04:07 2024 +1000

    ata: pata_macio: Use WARN instead of BUG
    
    [ Upstream commit d4bc0a264fb482b019c84fbc7202dd3cab059087 ]
    
    The overflow/underflow conditions in pata_macio_qc_prep() should never
    happen. But if they do there's no need to kill the system entirely, a
    WARN and failing the IO request should be sufficient and might allow the
    system to keep running.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: initialize integrity buffer to zero before writing it to media [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Jun 13 10:48:11 2024 +0200

    block: initialize integrity buffer to zero before writing it to media
    
    commit 899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f upstream.
    
    Metadata added by bio_integrity_prep is using plain kmalloc, which leads
    to random kernel memory being written media.  For PI metadata this is
    limited to the app tag that isn't used by kernel generated metadata,
    but for non-PI metadata the entire buffer leaks kernel memory.
    
    Fix this by adding the __GFP_ZERO flag to allocations for writes.
    
    Fixes: 7ba1ba12eeef ("block: Block layer data integrity support")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reviewed-by: Kanchan Joshi <joshi.k@samsung.com>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Link: https://lore.kernel.org/r/20240613084839.1044015-2-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bridge: switchdev: Allow clearing FDB entry offload indication [+ + +]
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Wed Oct 17 08:53:29 2018 +0000

    bridge: switchdev: Allow clearing FDB entry offload indication
    
    [ Upstream commit e9ba0fbc7dd23a74e77960c98c988f59a1ff75aa ]
    
    Currently, an FDB entry only ceases being offloaded when it is deleted.
    This changes with VxLAN encapsulation.
    
    Devices capable of performing VxLAN encapsulation usually have only one
    FDB table, unlike the software data path which has two - one in the
    bridge driver and another in the VxLAN driver.
    
    Therefore, bridge FDB entries pointing to a VxLAN device are only
    offloaded if there is a corresponding entry in the VxLAN FDB.
    
    Allow clearing the offload indication in case the corresponding entry
    was deleted from the VxLAN FDB.
    
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reviewed-by: Petr Machata <petrm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: bee2ef946d31 ("net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: clean up our handling of refs == 0 in snapshot delete [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue May 7 14:12:13 2024 -0400

    btrfs: clean up our handling of refs == 0 in snapshot delete
    
    [ Upstream commit b8ccef048354074a548f108e51d0557d6adfd3a3 ]
    
    In reada we BUG_ON(refs == 0), which could be unkind since we aren't
    holding a lock on the extent leaf and thus could get a transient
    incorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which
    could happen if we have extent tree corruption.  Change that to return
    -EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,
    however we return -EIO, which -EUCLEAN is a more appropriate error code.
    Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert
    that to proper error handling.  Also adjust the error message so we can
    actually do something with the information.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: initialize location to fix -Wmaybe-uninitialized in btrfs_lookup_dentry() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Mon Jul 29 21:59:24 2024 +0200

    btrfs: initialize location to fix -Wmaybe-uninitialized in btrfs_lookup_dentry()
    
    [ Upstream commit b8e947e9f64cac9df85a07672b658df5b2bcff07 ]
    
    Some arch + compiler combinations report a potentially unused variable
    location in btrfs_lookup_dentry(). This is a false alert as the variable
    is passed by value and always valid or there's an error. The compilers
    cannot probably reason about that although btrfs_inode_by_name() is in
    the same file.
    
       >  + /kisskb/src/fs/btrfs/inode.c: error: 'location.objectid' may be used
       +uninitialized in this function [-Werror=maybe-uninitialized]:  => 5603:9
       >  + /kisskb/src/fs/btrfs/inode.c: error: 'location.type' may be used
       +uninitialized in this function [-Werror=maybe-uninitialized]:  => 5674:5
    
       m68k-gcc8/m68k-allmodconfig
       mips-gcc8/mips-allmodconfig
       powerpc-gcc5/powerpc-all{mod,yes}config
       powerpc-gcc5/ppc64_defconfig
    
    Initialize it to zero, this should fix the warnings and won't change the
    behaviour as btrfs_inode_by_name() accepts only a root or inode item
    types, otherwise returns an error.
    
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Link: https://lore.kernel.org/linux-btrfs/bd4e9928-17b3-9257-8ba7-6b7f9bbb639a@linux-m68k.org/
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: replace BUG_ON with ASSERT in walk_down_proc() [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Tue May 7 14:12:12 2024 -0400

    btrfs: replace BUG_ON with ASSERT in walk_down_proc()
    
    [ Upstream commit 1f9d44c0a12730a24f8bb75c5e1102207413cc9b ]
    
    We have a couple of areas where we check to make sure the tree block is
    locked before looking up or messing with references.  This is old code
    so it has this as BUG_ON().  Convert this to ASSERT() for developers.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
can: bcm: Remove proc entry when dev is unregistered. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Mon Jul 22 12:28:42 2024 -0700

    can: bcm: Remove proc entry when dev is unregistered.
    
    [ Upstream commit 76fe372ccb81b0c89b6cd2fec26e2f38c958be85 ]
    
    syzkaller reported a warning in bcm_connect() below. [0]
    
    The repro calls connect() to vxcan1, removes vxcan1, and calls
    connect() with ifindex == 0.
    
    Calling connect() for a BCM socket allocates a proc entry.
    Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().
    
    However, removing the bound device resets bcm_sk(sk)->bound to 0
    in bcm_notify().
    
    The 2nd connect() tries to allocate a proc entry with the same
    name and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking the
    original proc entry.
    
    Since the proc entry is available only for connect()ed sockets,
    let's clean up the entry when the bound netdev is unregistered.
    
    [0]:
    proc_dir_entry 'can-bcm/2456' already registered
    WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375
    Modules linked in:
    CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
    RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375
    Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48
    RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246
    RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
    RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0
    R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000
    R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec
    FS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220
     bcm_connect+0x472/0x840 net/can/bcm.c:1673
     __sys_connect_file net/socket.c:2049 [inline]
     __sys_connect+0x5d2/0x690 net/socket.c:2066
     __do_sys_connect net/socket.c:2076 [inline]
     __se_sys_connect net/socket.c:2073 [inline]
     __x64_sys_connect+0x8f/0x100 net/socket.c:2073
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    RIP: 0033:0x7fbd708b0e5d
    Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
    RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d
    RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003
    RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040
    R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098
    R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000
     </TASK>
    remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'
    
    Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/all/20240722192842.37421-1-kuniyu@amazon.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cgroup: Protect css->cgroup write under css_set_lock [+ + +]
Author: Waiman Long <longman@redhat.com>
Date:   Wed Jul 3 14:52:29 2024 -0400

    cgroup: Protect css->cgroup write under css_set_lock
    
    [ Upstream commit 57b56d16800e8961278ecff0dc755d46c4575092 ]
    
    The writing of css->cgroup associated with the cgroup root in
    rebind_subsystems() is currently protected only by cgroup_mutex.
    However, the reading of css->cgroup in both proc_cpuset_show() and
    proc_cgroup_show() is protected just by css_set_lock. That makes the
    readers susceptible to racing problems like data tearing or caching.
    It is also a problem that can be reported by KCSAN.
    
    This can be fixed by using READ_ONCE() and WRITE_ONCE() to access
    css->cgroup. Alternatively, the writing of css->cgroup can be moved
    under css_set_lock as well which is done by this patch.
    
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: qcom: clk-alpha-pll: Fix the pll post div mask [+ + +]
Author: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
Date:   Wed Jul 31 11:59:09 2024 +0530

    clk: qcom: clk-alpha-pll: Fix the pll post div mask
    
    commit 2c4553e6c485a96b5d86989eb9654bf20e51e6dd upstream.
    
    The PLL_POST_DIV_MASK should be 0 to (width - 1) bits. Fix it.
    
    Fixes: 1c3541145cbf ("clk: qcom: support for 2 bit PLL post divider")
    Cc: stable@vger.kernel.org
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
    Link: https://lore.kernel.org/r/20240731062916.2680823-2-quic_skakitap@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
clocksource/drivers/imx-tpm: Fix next event not taking effect sometime [+ + +]
Author: Jacky Bai <ping.bai@nxp.com>
Date:   Thu Jul 25 15:33:55 2024 -0400

    clocksource/drivers/imx-tpm: Fix next event not taking effect sometime
    
    commit 3d5c2f8e75a55cfb11a85086c71996af0354a1fb upstream.
    
    The value written into the TPM CnV can only be updated into the hardware
    when the counter increases. Additional writes to the CnV write buffer are
    ignored until the register has been updated. Therefore, we need to check
    if the CnV has been updated before continuing. This may require waiting for
    1 counter cycle in the worst case.
    
    Cc: stable@vger.kernel.org
    Fixes: 059ab7b82eec ("clocksource/drivers/imx-tpm: Add imx tpm timer support")
    Signed-off-by: Jacky Bai <ping.bai@nxp.com>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Ye Li <ye.li@nxp.com>
    Reviewed-by: Jason Liu <jason.hui.liu@nxp.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20240725193355.1436005-2-Frank.Li@nxp.com
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clocksource/drivers/imx-tpm: Fix return -ETIME when delta exceeds INT_MAX [+ + +]
Author: Jacky Bai <ping.bai@nxp.com>
Date:   Thu Jul 25 15:33:54 2024 -0400

    clocksource/drivers/imx-tpm: Fix return -ETIME when delta exceeds INT_MAX
    
    commit 5b8843fcd49827813da80c0f590a17ae4ce93c5d upstream.
    
    In tpm_set_next_event(delta), return -ETIME by wrong cast to int when delta
    is larger than INT_MAX.
    
    For example:
    
    tpm_set_next_event(delta = 0xffff_fffe)
    {
            ...
            next = tpm_read_counter(); // assume next is 0x10
            next += delta; // next will 0xffff_fffe + 0x10 = 0x1_0000_000e
            now = tpm_read_counter();  // now is 0x10
            ...
    
            return (int)(next - now) <= 0 ? -ETIME : 0;
                         ^^^^^^^^^^
                         0x1_0000_000e - 0x10 = 0xffff_fffe, which is -2 when
                         cast to int. So return -ETIME.
    }
    
    To fix this, introduce a 'prev' variable and check if 'now - prev' is
    larger than delta.
    
    Cc: stable@vger.kernel.org
    Fixes: 059ab7b82eec ("clocksource/drivers/imx-tpm: Add imx tpm timer support")
    Signed-off-by: Jacky Bai <ping.bai@nxp.com>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Ye Li <ye.li@nxp.com>
    Reviewed-by: Jason Liu <jason.hui.liu@nxp.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20240725193355.1436005-1-Frank.Li@nxp.com
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cx82310_eth: fix error return code in cx82310_bind() [+ + +]
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Fri Nov 13 14:07:07 2020 +0800

    cx82310_eth: fix error return code in cx82310_bind()
    
    commit cfbaa8b33e022aca62a3f2815ffbc02874d4cb8b upstream.
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: ca139d76b0d9 ("cx82310_eth: re-enable ethernet mode after router reboot")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Link: https://lore.kernel.org/r/1605247627-15385-1-git-send-email-zhangchangzhong@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cx82310_eth: re-enable ethernet mode after router reboot [+ + +]
Author: Ondrej Zary <linux@zary.sk>
Date:   Sat Oct 10 16:00:46 2020 +0200

    cx82310_eth: re-enable ethernet mode after router reboot
    
    [ Upstream commit ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 ]
    
    When the router is rebooted without a power cycle, the USB device
    remains connected but its configuration is reset. This results in
    a non-working ethernet connection with messages like this in syslog:
            usb 2-2: RX packet too long: 65535 B
    
    Re-enable ethernet mode when receiving a packet with invalid size of
    0xffff.
    
    Signed-off-by: Ondrej Zary <linux@zary.sk>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: bab8eb0dd4cb ("usbnet: modern method to get random MAC")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
devres: Initialize an uninitialized struct member [+ + +]
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Tue Jul 2 22:51:52 2024 +0800

    devres: Initialize an uninitialized struct member
    
    [ Upstream commit 56a20ad349b5c51909cf8810f7c79b288864ad33 ]
    
    Initialize an uninitialized struct member for driver API
    devres_open_group().
    
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/1719931914-19035-4-git-send-email-quic_zijuhu@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/net/usb: Remove all strcpy() uses [+ + +]
Author: Len Baker <len.baker@gmx.com>
Date:   Sun Aug 1 19:12:26 2021 +0200

    drivers/net/usb: Remove all strcpy() uses
    
    [ Upstream commit 493c3ca6bd754d8587604496eb814f72e933075d ]
    
    strcpy() performs no bounds checking on the destination buffer. This
    could result in linear overflows beyond the end of the buffer, leading
    to all kinds of misbehaviors. The safe replacement is strscpy().
    
    Signed-off-by: Len Baker <len.baker@gmx.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: bab8eb0dd4cb ("usbnet: modern method to get random MAC")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Drivers: hv: vmbus: Fix rescind handling in uio_hv_generic [+ + +]
Author: Naman Jain <namjain@linux.microsoft.com>
Date:   Thu Aug 29 12:43:12 2024 +0530

    Drivers: hv: vmbus: Fix rescind handling in uio_hv_generic
    
    commit 6fd28941447bf2c8ca0f26fda612a1cabc41663f upstream.
    
    Rescind offer handling relies on rescind callbacks for some of the
    resources cleanup, if they are registered. It does not unregister
    vmbus device for the primary channel closure, when callback is
    registered. Without it, next onoffer does not come, rescind flag
    remains set and device goes to unusable state.
    
    Add logic to unregister vmbus for the primary channel in rescind callback
    to ensure channel removal and relid release, and to ensure that next
    onoffer can be received and handled properly.
    
    Cc: stable@vger.kernel.org
    Fixes: ca3cda6fcf1e ("uio_hv_generic: add rescind support")
    Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
    Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
    Link: https://lore.kernel.org/r/20240829071312.1595-3-namjain@linux.microsoft.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: fix mc_data out-of-bounds read warning [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Mon May 6 16:30:01 2024 +0800

    drm/amdgpu: fix mc_data out-of-bounds read warning
    
    [ Upstream commit 51dfc0a4d609fe700750a62f41447f01b8c9ea50 ]
    
    Clear warning that read mc_data[i-1] may out-of-bounds.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: fix overflowed array index read warning [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Thu Apr 25 13:15:27 2024 +0800

    drm/amdgpu: fix overflowed array index read warning
    
    [ Upstream commit ebbc2ada5c636a6a63d8316a3408753768f5aa9f ]
    
    Clear overflowed array index read warning by cast operation.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: fix ucode out-of-bounds read warning [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Mon May 6 16:21:00 2024 +0800

    drm/amdgpu: fix ucode out-of-bounds read warning
    
    [ Upstream commit 8944acd0f9db33e17f387fdc75d33bb473d7936f ]
    
    Clear warning that read ucode[] may out-of-bounds.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix uninitialized variable warning in amdgpu_afmt_acr [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Wed Apr 24 10:50:54 2024 +0800

    drm/amdgpu: Fix uninitialized variable warning in amdgpu_afmt_acr
    
    [ Upstream commit c0d6bd3cd209419cc46ac49562bef1db65d90e70 ]
    
    Assign value to clock to fix the warning below:
    "Using uninitialized value res. Field res.clock is uninitialized"
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdkfd: Reconcile the definition and use of oem_id in struct kfd_topology_device [+ + +]
Author: Michael Chen <michael.chen@amd.com>
Date:   Fri May 3 15:31:08 2024 -0400

    drm/amdkfd: Reconcile the definition and use of oem_id in struct kfd_topology_device
    
    [ Upstream commit 10f624ef239bd136cdcc5bbc626157a57b938a31 ]
    
    Currently oem_id is defined as uint8_t[6] and casted to uint64_t*
    in some use case. This would lead code scanner to complain about
    access beyond. Re-define it in union to enforce 8-byte size and
    alignment to avoid potential issue.
    
    Signed-off-by: Michael Chen <michael.chen@amd.com>
    Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/fence: Mark debug_fence_free() with __maybe_unused [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Aug 29 18:58:38 2024 +0300

    drm/i915/fence: Mark debug_fence_free() with __maybe_unused
    
    [ Upstream commit f99999536128b14b5d765a9982763b5134efdd79 ]
    
    When debug_fence_free() is unused
    (CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS=n), it prevents kernel builds
    with clang, `make W=1` and CONFIG_WERROR=y:
    
    .../i915_sw_fence.c:118:20: error: unused function 'debug_fence_free' [-Werror,-Wunused-function]
      118 | static inline void debug_fence_free(struct i915_sw_fence *fence)
          |                    ^~~~~~~~~~~~~~~~
    
    Fix this by marking debug_fence_free() with __maybe_unused.
    
    See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static
    inline functions for W=1 build").
    
    Fixes: fc1584059d6c ("drm/i915: Integrate i915_sw_fence with debugobjects")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240829155950.1141978-3-andriy.shevchenko@linux.intel.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    (cherry picked from commit 8be4dce5ea6f2368cc25edc71989c4690fa66964)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915/fence: Mark debug_fence_init_onstack() with __maybe_unused [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Aug 29 18:58:37 2024 +0300

    drm/i915/fence: Mark debug_fence_init_onstack() with __maybe_unused
    
    [ Upstream commit fcd9e8afd546f6ced378d078345a89bf346d065e ]
    
    When debug_fence_init_onstack() is unused (CONFIG_DRM_I915_SELFTEST=n),
    it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y:
    
    .../i915_sw_fence.c:97:20: error: unused function 'debug_fence_init_onstack' [-Werror,-Wunused-function]
       97 | static inline void debug_fence_init_onstack(struct i915_sw_fence *fence)
          |                    ^~~~~~~~~~~~~~~~~~~~~~~~
    
    Fix this by marking debug_fence_init_onstack() with __maybe_unused.
    
    See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static
    inline functions for W=1 build").
    
    Fixes: 214707fc2ce0 ("drm/i915/selftests: Wrap a timer into a i915_sw_fence")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240829155950.1141978-2-andriy.shevchenko@linux.intel.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    (cherry picked from commit 5bf472058ffb43baf6a4cdfe1d7f58c4c194c688)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fuse: use unsigned type for getxattr/listxattr size truncation [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Mon Aug 19 19:52:30 2024 +0200

    fuse: use unsigned type for getxattr/listxattr size truncation
    
    commit b18915248a15eae7d901262f108d6ff0ffb4ffc1 upstream.
    
    The existing code uses min_t(ssize_t, outarg.size, XATTR_LIST_MAX) when
    parsing the FUSE daemon's response to a zero-length getxattr/listxattr
    request.
    On 32-bit kernels, where ssize_t and outarg.size are the same size, this is
    wrong: The min_t() will pass through any size values that are negative when
    interpreted as signed.
    fuse_listxattr() will then return this userspace-supplied negative value,
    which callers will treat as an error value.
    
    This kind of bug pattern can lead to fairly bad security bugs because of
    how error codes are used in the Linux kernel. If a caller were to convert
    the numeric error into an error pointer, like so:
    
        struct foo *func(...) {
          int len = fuse_getxattr(..., NULL, 0);
          if (len < 0)
            return ERR_PTR(len);
          ...
        }
    
    then it would end up returning this userspace-supplied negative value cast
    to a pointer - but the caller of this function wouldn't recognize it as an
    error pointer (IS_ERR_VALUE() only detects values in the narrow range in
    which legitimate errno values are), and so it would just be treated as a
    kernel pointer.
    
    I think there is at least one theoretical codepath where this could happen,
    but that path would involve virtio-fs with submounts plus some weird
    SELinux configuration, so I think it's probably not a concern in practice.
    
    Cc: stable@vger.kernel.org # v4.9
    Fixes: 63401ccdb2ca ("fuse: limit xattr returned size")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup [+ + +]
Author: Camila Alvarez <cam.alvarez.i@gmail.com>
Date:   Tue Jul 30 19:42:43 2024 -0400

    HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup
    
    [ Upstream commit a6e9c391d45b5865b61e569146304cff72821a5d ]
    
    report_fixup for the Cougar 500k Gaming Keyboard was not verifying
    that the report descriptor size was correct before accessing it
    
    Reported-by: syzbot+24c0361074799d02c452@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=24c0361074799d02c452
    Signed-off-by: Camila Alvarez <cam.alvarez.i@gmail.com>
    Reviewed-by: Silvan Jegen <s.jegen@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (adc128d818) Fix underflows seen when writing limit attributes [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Jul 6 23:43:04 2024 -0700

    hwmon: (adc128d818) Fix underflows seen when writing limit attributes
    
    [ Upstream commit 8cad724c8537fe3e0da8004646abc00290adae40 ]
    
    DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
    negative number such as -9223372036854775808 is provided by the user.
    Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (lm95234) Fix underflows seen when writing limit attributes [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Jul 6 23:48:42 2024 -0700

    hwmon: (lm95234) Fix underflows seen when writing limit attributes
    
    [ Upstream commit af64e3e1537896337405f880c1e9ac1f8c0c6198 ]
    
    DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
    negative number such as -9223372036854775808 is provided by the user.
    Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (nct6775-core) Fix underflows seen when writing limit attributes [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Jul 6 23:50:08 2024 -0700

    hwmon: (nct6775-core) Fix underflows seen when writing limit attributes
    
    [ Upstream commit 0403e10bf0824bf0ec2bb135d4cf1c0cc3bf4bf0 ]
    
    DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
    negative number such as -9223372036854775808 is provided by the user.
    Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (w83627ehf) Fix underflows seen when writing limit attributes [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Jul 6 23:51:34 2024 -0700

    hwmon: (w83627ehf) Fix underflows seen when writing limit attributes
    
    [ Upstream commit 5c1de37969b7bc0abcb20b86e91e70caebbd4f89 ]
    
    DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
    negative number such as -9223372036854775808 is provided by the user.
    Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
igb: Fix not clearing TimeSync interrupts for 82580 [+ + +]
Author: Daiwei Li <daiweili@google.com>
Date:   Tue Aug 13 21:55:53 2024 -0700

    igb: Fix not clearing TimeSync interrupts for 82580
    
    [ Upstream commit ba8cf80724dbc09825b52498e4efacb563935408 ]
    
    82580 NICs have a hardware bug that makes it
    necessary to write into the TSICR (TimeSync Interrupt Cause) register
    to clear it:
    https://lore.kernel.org/all/CDCB8BE0.1EC2C%25matthew.vick@intel.com/
    
    Add a conditional so only for 82580 we write into the TSICR register,
    so we don't risk losing events for other models.
    
    Without this change, when running ptp4l with an Intel 82580 card,
    I get the following output:
    
    > timed out while polling for tx timestamp increasing tx_timestamp_timeout or
    > increasing kworker priority may correct this issue, but a driver bug likely
    > causes it
    
    This goes away with this change.
    
    This (partially) reverts commit ee14cc9ea19b ("igb: Fix missing time sync events").
    
    Fixes: ee14cc9ea19b ("igb: Fix missing time sync events")
    Closes: https://lore.kernel.org/intel-wired-lan/CAN0jFd1kO0MMtOh8N2Ztxn6f7vvDKp2h507sMryobkBKe=xk=w@mail.gmail.com/
    Tested-by: Daiwei Li <daiweili@google.com>
    Suggested-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Signed-off-by: Daiwei Li <daiweili@google.com>
    Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: buffer-dmaengine: fix releasing dma channel on error [+ + +]
Author: David Lechner <dlechner@baylibre.com>
Date:   Tue Jul 23 11:32:21 2024 -0500

    iio: buffer-dmaengine: fix releasing dma channel on error
    
    commit 84c65d8008764a8fb4e627ff02de01ec4245f2c4 upstream.
    
    If dma_get_slave_caps() fails, we need to release the dma channel before
    returning an error to avoid leaking the channel.
    
    Fixes: 2d6ca60f3284 ("iio: Add a DMAengine framework based buffer")
    Signed-off-by: David Lechner <dlechner@baylibre.com>
    Link: https://patch.msgid.link/20240723-iio-fix-dmaengine-free-on-error-v1-1-2c7cbc9b92ff@baylibre.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: fix scale application in iio_convert_raw_to_processed_unlocked [+ + +]
Author: Matteo Martelli <matteomartelli3@gmail.com>
Date:   Tue Jul 30 10:11:53 2024 +0200

    iio: fix scale application in iio_convert_raw_to_processed_unlocked
    
    commit 8a3dcc970dc57b358c8db2702447bf0af4e0d83a upstream.
    
    When the scale_type is IIO_VAL_INT_PLUS_MICRO or IIO_VAL_INT_PLUS_NANO
    the scale passed as argument is only applied to the fractional part of
    the value. Fix it by also multiplying the integer part by the scale
    provided.
    
    Fixes: 48e44ce0f881 ("iio:inkern: Add function to read the processed value")
    Signed-off-by: Matteo Martelli <matteomartelli3@gmail.com>
    Link: https://patch.msgid.link/20240730-iio-fix-scale-v1-1-6246638c8daa@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ila: call nf_unregister_net_hooks() sooner [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Sep 4 14:44:18 2024 +0000

    ila: call nf_unregister_net_hooks() sooner
    
    commit 031ae72825cef43e4650140b800ad58bf7a6a466 upstream.
    
    syzbot found an use-after-free Read in ila_nf_input [1]
    
    Issue here is that ila_xlat_exit_net() frees the rhashtable,
    then call nf_unregister_net_hooks().
    
    It should be done in the reverse way, with a synchronize_rcu().
    
    This is a good match for a pre_exit() method.
    
    [1]
     BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
     BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]
     BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]
     BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672
    Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16
    
    CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:93 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
      print_address_description mm/kasan/report.c:377 [inline]
      print_report+0x169/0x550 mm/kasan/report.c:488
      kasan_report+0x143/0x180 mm/kasan/report.c:601
      rht_key_hashfn include/linux/rhashtable.h:159 [inline]
      __rhashtable_lookup include/linux/rhashtable.h:604 [inline]
      rhashtable_lookup include/linux/rhashtable.h:646 [inline]
      rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672
      ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]
      ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]
      ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312
      __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
      __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775
      process_backlog+0x662/0x15b0 net/core/dev.c:6108
      __napi_poll+0xcb/0x490 net/core/dev.c:6772
      napi_poll net/core/dev.c:6841 [inline]
      net_rx_action+0x89b/0x1240 net/core/dev.c:6963
      handle_softirqs+0x2c4/0x970 kernel/softirq.c:554
      run_ksoftirqd+0xca/0x130 kernel/softirq.c:928
      smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164
      kthread+0x2f0/0x390 kernel/kthread.c:389
      ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
      ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
     </TASK>
    
    The buggy address belongs to the physical page:
    page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620
    flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
    page_type: 0xbfffffff(buddy)
    raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000
    raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as freed
    page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187
      set_page_owner include/linux/page_owner.h:32 [inline]
      post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493
      prep_new_page mm/page_alloc.c:1501 [inline]
      get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439
      __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695
      __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
      alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
      ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103
      __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130
      __do_kmalloc_node mm/slub.c:4146 [inline]
      __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164
      __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650
      bucket_table_alloc lib/rhashtable.c:186 [inline]
      rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071
      ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613
      ops_init+0x359/0x610 net/core/net_namespace.c:139
      setup_net+0x515/0xca0 net/core/net_namespace.c:343
      copy_net_ns+0x4e2/0x7b0 net/core/net_namespace.c:508
      create_new_namespaces+0x425/0x7b0 kernel/nsproxy.c:110
      unshare_nsproxy_namespaces+0x124/0x180 kernel/nsproxy.c:228
      ksys_unshare+0x619/0xc10 kernel/fork.c:3328
      __do_sys_unshare kernel/fork.c:3399 [inline]
      __se_sys_unshare kernel/fork.c:3397 [inline]
      __x64_sys_unshare+0x38/0x40 kernel/fork.c:3397
    page last free pid 11846 tgid 11846 stack trace:
      reset_page_owner include/linux/page_owner.h:25 [inline]
      free_pages_prepare mm/page_alloc.c:1094 [inline]
      free_unref_page+0xd22/0xea0 mm/page_alloc.c:2612
      __folio_put+0x2c8/0x440 mm/swap.c:128
      folio_put include/linux/mm.h:1486 [inline]
      free_large_kmalloc+0x105/0x1c0 mm/slub.c:4565
      kfree+0x1c4/0x360 mm/slub.c:4588
      rhashtable_free_and_destroy+0x7c6/0x920 lib/rhashtable.c:1169
      ila_xlat_exit_net+0x55/0x110 net/ipv6/ila/ila_xlat.c:626
      ops_exit_list net/core/net_namespace.c:173 [inline]
      cleanup_net+0x802/0xcc0 net/core/net_namespace.c:640
      process_one_work kernel/workqueue.c:3231 [inline]
      process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
      worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
      kthread+0x2f0/0x390 kernel/kthread.c:389
      ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
      ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
    
    Memory state around the buggy address:
     ffff88806461ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff88806461ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff888064620000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                          ^
     ffff888064620080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
     ffff888064620100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    
    Fixes: 7f00feaf1076 ("ila: Add generic ILA translation facility")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Tom Herbert <tom@herbertland.com>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Link: https://patch.msgid.link/20240904144418.1162839-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Input: uinput - reject requests with unreasonable number of slots [+ + +]
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Sun Aug 4 17:50:25 2024 -0700

    Input: uinput - reject requests with unreasonable number of slots
    
    [ Upstream commit 206f533a0a7c683982af473079c4111f4a0f9f5e ]
    
    From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    
    When exercising uinput interface syzkaller may try setting up device
    with a really large number of slots, which causes memory allocation
    failure in input_mt_init_slots(). While this allocation failure is
    handled properly and request is rejected, it results in syzkaller
    reports. Additionally, such request may put undue burden on the
    system which will try to free a lot of memory for a bogus request.
    
    Fix it by limiting allowed number of slots to 100. This can easily
    be extended if we see devices that can track more than 100 contacts.
    
    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reported-by: syzbot <syzbot+0122fa359a69694395d5@syzkaller.appspotmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
    Link: https://lore.kernel.org/r/Zqgi7NYEbpRsJfa2@google.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/vt-d: Handle volatile descriptor status read [+ + +]
Author: Jacob Pan <jacob.jun.pan@linux.intel.com>
Date:   Tue Jul 2 21:08:33 2024 +0800

    iommu/vt-d: Handle volatile descriptor status read
    
    [ Upstream commit b5e86a95541cea737394a1da967df4cd4d8f7182 ]
    
    Queued invalidation wait descriptor status is volatile in that IOMMU
    hardware writes the data upon completion.
    
    Use READ_ONCE() to prevent compiler optimizations which ensures memory
    reads every time. As a side effect, READ_ONCE() also enforces strict
    types and may add an extra instruction. But it should not have negative
    performance impact since we use cpu_relax anyway and the extra time(by
    adding an instruction) may allow IOMMU HW request cacheline ownership
    easier.
    
    e.g. gcc 12.3
    BEFORE:
            81 38 ad de 00 00       cmpl   $0x2,(%rax)
    
    AFTER (with READ_ONCE())
        772f:       8b 00                   mov    (%rax),%eax
        7731:       3d ad de 00 00          cmp    $0x2,%eax
                                            //status data is 32 bit
    
    Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Yi Liu <yi.l.liu@intel.com>
    Link: https://lore.kernel.org/r/20240607173817.3914600-1-jacob.jun.pan@linux.intel.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Link: https://lore.kernel.org/r/20240702130839.108139-2-baolu.lu@linux.intel.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/armada-370-xp: Do not allow mapping IRQ 0 and 1 [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Fri Jun 21 11:38:28 2024 +0200

    irqchip/armada-370-xp: Do not allow mapping IRQ 0 and 1
    
    [ Upstream commit 3cef738208e5c3cb7084e208caf9bbf684f24feb ]
    
    IRQs 0 (IPI) and 1 (MSI) are handled internally by this driver,
    generic_handle_domain_irq() is never called for these IRQs.
    
    Disallow mapping these IRQs.
    
    [ Marek: changed commit message ]
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 4.19.322 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 12 11:02:56 2024 +0200

    Linux 4.19.322
    
    Link: https://lore.kernel.org/r/20240910092541.383432924@linuxfoundation.org
    Link: https://lore.kernel.org/r/20240910094253.246228054@linuxfoundation.org
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: qcom: camss: Add check for v4l2_fwnode_endpoint_parse [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Fri Jun 21 09:35:22 2024 +0800

    media: qcom: camss: Add check for v4l2_fwnode_endpoint_parse
    
    [ Upstream commit 4caf6d93d9f2c11d6441c64e1c549c445fa322ed ]
    
    Add check for the return value of v4l2_fwnode_endpoint_parse() and
    return the error if it fails in order to catch the error.
    
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: uvcvideo: Enforce alignment of frame and interval [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Thu Apr 4 17:56:18 2024 +0000

    media: uvcvideo: Enforce alignment of frame and interval
    
    [ Upstream commit c8931ef55bd325052ec496f242aea7f6de47dc9c ]
    
    Struct uvc_frame and interval (u32*) are packaged together on
    streaming->formats on a single contiguous allocation.
    
    Right now they are allocated right after uvc_format, without taking into
    consideration their required alignment.
    
    This is working fine because both structures have a field with a
    pointer, but it will stop working when the sizeof() of any of those
    structs is not a multiple of the sizeof(void*).
    
    Enforce that alignment during the allocation.
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://lore.kernel.org/r/20240404-uvc-align-v2-1-9e104b0ecfbd@chromium.org
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K [+ + +]
Author: Sam Protsenko <semen.protsenko@linaro.org>
Date:   Wed Mar 6 17:20:52 2024 -0600

    mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K
    
    commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890 upstream.
    
    Commit 616f87661792 ("mmc: pass queue_limits to blk_mq_alloc_disk") [1]
    revealed the long living issue in dw_mmc.c driver, existing since the
    time when it was first introduced in commit f95f3850f7a9 ("mmc: dw_mmc:
    Add Synopsys DesignWare mmc host driver."), also making kernel boot
    broken on platforms using dw_mmc driver with 16K or 64K pages enabled,
    with this message in dmesg:
    
        mmcblk: probe of mmc0:0001 failed with error -22
    
    That's happening because mmc_blk_probe() fails when it calls
    blk_validate_limits() consequently, which returns the error due to
    failed max_segment_size check in this code:
    
        /*
         * The maximum segment size has an odd historic 64k default that
         * drivers probably should override.  Just like the I/O size we
         * require drivers to at least handle a full page per segment.
         */
        ...
        if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))
            return -EINVAL;
    
    In case when IDMAC (Internal DMA Controller) is used, dw_mmc.c always
    sets .max_seg_size to 4 KiB:
    
        mmc->max_seg_size = 0x1000;
    
    The comment in the code above explains why it's incorrect. Arnd
    suggested setting .max_seg_size to .max_req_size to fix it, which is
    also what some other drivers are doing:
    
       $ grep -rl 'max_seg_size.*=.*max_req_size' drivers/mmc/host/ | \
         wc -l
       18
    
    This change is not only fixing the boot with 16K/64K pages, but also
    leads to a better MMC performance. The linear write performance was
    tested on E850-96 board (eMMC only), before commit [1] (where it's
    possible to boot with 16K/64K pages without this fix, to be able to do
    a comparison). It was tested with this command:
    
        # dd if=/dev/zero of=somefile bs=1M count=500 oflag=sync
    
    Test results are as follows:
    
      - 4K pages,  .max_seg_size = 4 KiB:                   94.2 MB/s
      - 4K pages,  .max_seg_size = .max_req_size = 512 KiB: 96.9 MB/s
      - 16K pages, .max_seg_size = 4 KiB:                   126 MB/s
      - 16K pages, .max_seg_size = .max_req_size = 2 MiB:   128 MB/s
      - 64K pages, .max_seg_size = 4 KiB:                   138 MB/s
      - 64K pages, .max_seg_size = .max_req_size = 8 MiB:   138 MB/s
    
    Unfortunately, SD card controller is not enabled in E850-96 yet, so it
    wasn't possible for me to run the test on some cheap SD cards to check
    this patch's impact on those. But it's possible that this change might
    also reduce the writes count, thus improving SD/eMMC longevity.
    
    All credit for the analysis and the suggested solution goes to Arnd.
    
    [1] https://lore.kernel.org/all/20240215070300.2200308-18-hch@lst.de/
    
    Fixes: f95f3850f7a9 ("mmc: dw_mmc: Add Synopsys DesignWare mmc host driver.")
    Suggested-by: Arnd Bergmann <arnd@arndb.de>
    Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Closes: https://lore.kernel.org/all/CA+G9fYtddf2Fd3be+YShHP6CmSDNcn0ptW8qg+stUKW+Cn0rjQ@mail.gmail.com/
    Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240306232052.21317-1-semen.protsenko@linaro.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket [+ + +]
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Thu Jul 4 08:41:57 2024 +0200

    net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
    
    commit 626dfed5fa3bfb41e0dffd796032b555b69f9cde upstream.
    
    When using a BPF program on kernel_connect(), the call can return -EPERM. This
    causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
    the kernel to potentially freeze up.
    
    Neil suggested:
    
      This will propagate -EPERM up into other layers which might not be ready
      to handle it. It might be safer to map EPERM to an error we would be more
      likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
    
    ECONNREFUSED as error seems reasonable. For programs setting a different error
    can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
    which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err
    instead of allow boolean"), thus given that it is better to simply remap for
    consistent behavior. UDP does handle EPERM in xs_udp_send_request().
    
    Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
    Fixes: 4fbac77d2d09 ("bpf: Hooks for sys_bind")
    Co-developed-by: Lex Siegel <usiegl00@gmail.com>
    Signed-off-by: Lex Siegel <usiegl00@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Neil Brown <neilb@suse.de>
    Cc: Trond Myklebust <trondmy@kernel.org>
    Cc: Anna Schumaker <anna@kernel.org>
    Link: https://github.com/cilium/cilium/issues/33395
    Link: https://lore.kernel.org/bpf/171374175513.12877.8993642908082014881@noble.neil.brown.name
    Link: https://patch.msgid.link/9069ec1d59e4b2129fc23433349fd5580ad43921.1720075070.git.daniel@iogearbox.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: bridge: add support for sticky fdb entries [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Tue Sep 11 09:39:53 2018 +0300

    net: bridge: add support for sticky fdb entries
    
    [ Upstream commit 435f2e7cc0b783615d7fbcf08f5f00d289f9caeb ]
    
    Add support for entries which are "sticky", i.e. will not change their port
    if they show up from a different one. A new ndm flag is introduced for that
    purpose - NTF_STICKY. We allow to set it only to non-local entries.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: bee2ef946d31 ("net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN [+ + +]
Author: Jonas Gorski <jonas.gorski@bisdn.de>
Date:   Tue Sep 3 10:19:57 2024 +0200

    net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN
    
    [ Upstream commit bee2ef946d3184e99077be526567d791c473036f ]
    
    When userspace wants to take over a fdb entry by setting it as
    EXTERN_LEARNED, we set both flags BR_FDB_ADDED_BY_EXT_LEARN and
    BR_FDB_ADDED_BY_USER in br_fdb_external_learn_add().
    
    If the bridge updates the entry later because its port changed, we clear
    the BR_FDB_ADDED_BY_EXT_LEARN flag, but leave the BR_FDB_ADDED_BY_USER
    flag set.
    
    If userspace then wants to take over the entry again,
    br_fdb_external_learn_add() sees that BR_FDB_ADDED_BY_USER and skips
    setting the BR_FDB_ADDED_BY_EXT_LEARN flags, thus silently ignores the
    update.
    
    Fix this by always allowing to set BR_FDB_ADDED_BY_EXT_LEARN regardless
    if this was a user fdb entry or not.
    
    Fixes: 710ae7287737 ("net: bridge: Mark FDB entries that were added by user as such")
    Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Link: https://patch.msgid.link/20240903081958.29951-1-jonas.gorski@bisdn.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: fdb: convert added_by_external_learn to use bitops [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Tue Oct 29 13:45:57 2019 +0200

    net: bridge: fdb: convert added_by_external_learn to use bitops
    
    [ Upstream commit b5cd9f7c42480ede119a390607a9dbe6263f6795 ]
    
    Convert the added_by_external_learn field to a flag and use bitops.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: bee2ef946d31 ("net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: fdb: convert added_by_user to bitops [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Tue Oct 29 13:45:56 2019 +0200

    net: bridge: fdb: convert added_by_user to bitops
    
    [ Upstream commit ac3ca6af443aa495c7907e5010ac77fbd2450eaa ]
    
    Straight-forward convert of the added_by_user field to bitops.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: bee2ef946d31 ("net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: fdb: convert is_local to bitops [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Tue Oct 29 13:45:53 2019 +0200

    net: bridge: fdb: convert is_local to bitops
    
    [ Upstream commit 6869c3b02b596eba931a754f56875d2e2ac612db ]
    
    The patch adds a new fdb flags field in the hole between the two cache
    lines and uses it to convert is_local to bitops.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: bee2ef946d31 ("net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: fdb: convert is_static to bitops [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Tue Oct 29 13:45:54 2019 +0200

    net: bridge: fdb: convert is_static to bitops
    
    [ Upstream commit 29e63fffd666f1945756882d4b02bc7bec132101 ]
    
    Convert the is_static to bitops, make use of the combined
    test_and_set/clear_bit to simplify expressions in fdb_add_entry.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: bee2ef946d31 ("net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: fdb: convert is_sticky to bitops [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Tue Oct 29 13:45:55 2019 +0200

    net: bridge: fdb: convert is_sticky to bitops
    
    [ Upstream commit e0458d9a733ba71a2821d0c3fc0745baac697db0 ]
    
    Straight-forward convert of the is_sticky field to bitops.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: bee2ef946d31 ("net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: vsc73xx: fix possible subblocks range of CAPT block [+ + +]
Author: Pawel Dembicki <paweldembicki@gmail.com>
Date:   Tue Sep 3 22:33:41 2024 +0200

    net: dsa: vsc73xx: fix possible subblocks range of CAPT block
    
    [ Upstream commit 8e69c96df771ab469cec278edb47009351de4da6 ]
    
    CAPT block (CPU Capture Buffer) have 7 sublocks: 0-3, 4, 6, 7.
    Function 'vsc73xx_is_addr_valid' allows to use only block 0 at this
    moment.
    
    This patch fix it.
    
    Fixes: 05bd97fc559d ("net: dsa: Add Vitesse VSC73xx DSA router driver")
    Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://patch.msgid.link/20240903203340.1518789-1-paweldembicki@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: don't write directly to netdev->dev_addr [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Oct 21 06:12:06 2021 -0700

    net: usb: don't write directly to netdev->dev_addr
    
    [ Upstream commit 2674e7ea22ba0e22a2d1603bd51e0b8f6442a267 ]
    
    Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
    of VLANs...") introduced a rbtree for faster Ethernet address look
    up. To maintain netdev->dev_addr in this tree we need to make all
    the writes to it got through appropriate helpers.
    
    Manually fix all net/usb drivers without separate maintainers.
    
    v2: catc does DMA to the buffer, leave the conversion to Oliver
    
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: bab8eb0dd4cb ("usbnet: modern method to get random MAC")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: qmi_wwan: add MeiG Smart SRM825L [+ + +]
Author: ZHANG Yuntian <yt@radxa.com>
Date:   Sat Aug 3 15:46:51 2024 +0800

    net: usb: qmi_wwan: add MeiG Smart SRM825L
    
    [ Upstream commit 1ca645a2f74a4290527ae27130c8611391b07dbf ]
    
    Add support for MeiG Smart SRM825L which is based on Qualcomm 315 chip.
    
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2dee ProdID=4d22 Rev= 4.14
    S:  Manufacturer=MEIG
    S:  Product=LTE-A Module
    S:  SerialNumber=6f345e48
    C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=896mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: ZHANG Yuntian <yt@radxa.com>
    Link: https://patch.msgid.link/D1EB81385E405DFE+20240803074656.567061-1-yt@radxa.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
netfilter: nf_conncount: fix wrong variable type [+ + +]
Author: Yunjian Wang <wangyunjian@huawei.com>
Date:   Fri May 31 11:48:47 2024 +0800

    netfilter: nf_conncount: fix wrong variable type
    
    [ Upstream commit 0b88d1654d556264bcd24a9cb6383f0888e30131 ]
    
    Now there is a issue is that code checks reports a warning: implicit
    narrowing conversion from type 'unsigned int' to small type 'u8' (the
    'keylen' variable). Fix it by removing the 'keylen' variable.
    
    Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netns: add pre_exit method to struct pernet_operations [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 18 11:08:59 2019 -0700

    netns: add pre_exit method to struct pernet_operations
    
    commit d7d99872c144a2c2f5d9c9d83627fa833836cba5 upstream.
    
    Current struct pernet_operations exit() handlers are highly
    discouraged to call synchronize_rcu().
    
    There are cases where we need them, and exit_batch() does
    not help the common case where a single netns is dismantled.
    
    This patch leverages the existing synchronize_rcu() call
    in cleanup_net()
    
    Calling optional ->pre_exit() method before ->exit() or
    ->exit_batch() allows to benefit from a single synchronize_rcu()
    call.
    
    Note that the synchronize_rcu() calls added in this patch
    are only in error paths or slow paths.
    
    Tested:
    
    $ time for i in {1..1000}; do unshare -n /bin/false;done
    
    real    0m2.612s
    user    0m0.171s
    sys     0m2.216s
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netns: restore ops before calling ops_exit_list [+ + +]
Author: Li RongQing <lirongqing@baidu.com>
Date:   Thu Jun 20 19:24:40 2019 +0800

    netns: restore ops before calling ops_exit_list
    
    commit b272a0ad730103e84fb735fd0a8cc050cdf7f77c upstream.
    
    ops has been iterated to first element when call pre_exit, and
    it needs to restore from save_ops, not save ops to save_ops
    
    Fixes: d7d99872c144 ("netns: add pre_exit method to struct pernet_operations")
    Signed-off-by: Li RongQing <lirongqing@baidu.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nilfs2: fix missing cleanup on rollforward recovery error [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sat Aug 10 15:52:42 2024 +0900

    nilfs2: fix missing cleanup on rollforward recovery error
    
    commit 5787fcaab9eb5930f5378d6a1dd03d916d146622 upstream.
    
    In an error injection test of a routine for mount-time recovery, KASAN
    found a use-after-free bug.
    
    It turned out that if data recovery was performed using partial logs
    created by dsync writes, but an error occurred before starting the log
    writer to create a recovered checkpoint, the inodes whose data had been
    recovered were left in the ns_dirty_files list of the nilfs object and
    were not freed.
    
    Fix this issue by cleaning up inodes that have read the recovery data if
    the recovery routine fails midway before the log writer starts.
    
    Link: https://lkml.kernel.org/r/20240810065242.3701-1-konishi.ryusuke@gmail.com
    Fixes: 0f3e1c7f23f8 ("nilfs2: recovery functions")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix state management in error path of log writing function [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Aug 14 19:11:19 2024 +0900

    nilfs2: fix state management in error path of log writing function
    
    commit 6576dd6695f2afca3f4954029ac4a64f82ba60ab upstream.
    
    After commit a694291a6211 ("nilfs2: separate wait function from
    nilfs_segctor_write") was applied, the log writing function
    nilfs_segctor_do_construct() was able to issue I/O requests continuously
    even if user data blocks were split into multiple logs across segments,
    but two potential flaws were introduced in its error handling.
    
    First, if nilfs_segctor_begin_construction() fails while creating the
    second or subsequent logs, the log writing function returns without
    calling nilfs_segctor_abort_construction(), so the writeback flag set on
    pages/folios will remain uncleared.  This causes page cache operations to
    hang waiting for the writeback flag.  For example,
    truncate_inode_pages_final(), which is called via nilfs_evict_inode() when
    an inode is evicted from memory, will hang.
    
    Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared.
    As a result, if the next log write involves checkpoint creation, that's
    fine, but if a partial log write is performed that does not, inodes with
    NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files"
    list, and their data and b-tree blocks may not be written to the device,
    corrupting the block mapping.
    
    Fix these issues by uniformly calling nilfs_segctor_abort_construction()
    on failure of each step in the loop in nilfs_segctor_do_construct(),
    having it clean up logs and segment usages according to progress, and
    correcting the conditions for calling nilfs_redirty_inodes() to ensure
    that the NILFS_I_COLLECTED flag is cleared.
    
    Link: https://lkml.kernel.org/r/20240814101119.4070-1-konishi.ryusuke@gmail.com
    Fixes: a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: protect references to superblock parameters exposed in sysfs [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sun Aug 11 19:03:20 2024 +0900

    nilfs2: protect references to superblock parameters exposed in sysfs
    
    [ Upstream commit 683408258917541bdb294cd717c210a04381931e ]
    
    The superblock buffers of nilfs2 can not only be overwritten at runtime
    for modifications/repairs, but they are also regularly swapped, replaced
    during resizing, and even abandoned when degrading to one side due to
    backing device issues.  So, accessing them requires mutual exclusion using
    the reader/writer semaphore "nilfs->ns_sem".
    
    Some sysfs attribute show methods read this superblock buffer without the
    necessary mutual exclusion, which can cause problems with pointer
    dereferencing and memory access, so fix it.
    
    Link: https://lkml.kernel.org/r/20240811100320.9913-1-konishi.ryusuke@gmail.com
    Fixes: da7141fb78db ("nilfs2: add /sys/fs/nilfs2/<device> group")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nilfs2: replace snprintf in show functions with sysfs_emit [+ + +]
Author: Qing Wang <wangqing@vivo.com>
Date:   Mon Nov 8 18:34:58 2021 -0800

    nilfs2: replace snprintf in show functions with sysfs_emit
    
    [ Upstream commit 3bcd6c5bd483287f4a09d3d59a012d47677b6edc ]
    
    Patch series "nilfs2 updates".
    
    This patch (of 2):
    
    coccicheck complains about the use of snprintf() in sysfs show functions.
    
    Fix the coccicheck warning:
    
      WARNING: use scnprintf or sprintf.
    
    Use sysfs_emit instead of scnprintf or sprintf makes more sense.
    
    Link: https://lkml.kernel.org/r/1635151862-11547-1-git-send-email-konishi.ryusuke@gmail.com
    Link: https://lkml.kernel.org/r/1634095759-4625-1-git-send-email-wangqing@vivo.com
    Link: https://lkml.kernel.org/r/1635151862-11547-2-git-send-email-konishi.ryusuke@gmail.com
    Signed-off-by: Qing Wang <wangqing@vivo.com>
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Stable-dep-of: 683408258917 ("nilfs2: protect references to superblock parameters exposed in sysfs")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmem: Fix return type of devm_nvmem_device_get() in kerneldoc [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Sep 2 15:25:09 2024 +0100

    nvmem: Fix return type of devm_nvmem_device_get() in kerneldoc
    
    commit c69f37f6559a8948d70badd2b179db7714dedd62 upstream.
    
    devm_nvmem_device_get() returns an nvmem device, not an nvmem cell.
    
    Fixes: e2a5402ec7c6d044 ("nvmem: Add nvmem_device based consumer apis.")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240902142510.71096-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
of/irq: Prevent device address out-of-bounds read in interrupt map walk [+ + +]
Author: Stefan Wiehler <stefan.wiehler@nokia.com>
Date:   Mon Aug 12 12:06:51 2024 +0200

    of/irq: Prevent device address out-of-bounds read in interrupt map walk
    
    [ Upstream commit b739dffa5d570b411d4bdf4bb9b8dfd6b7d72305 ]
    
    When of_irq_parse_raw() is invoked with a device address smaller than
    the interrupt parent node (from #address-cells property), KASAN detects
    the following out-of-bounds read when populating the initial match table
    (dyndbg="func of_irq_parse_* +p"):
    
      OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0
      OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2
      OF:  intspec=4
      OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2
      OF:  -> addrsize=3
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0
      Read of size 4 at addr ffffff81beca5608 by task bash/764
    
      CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1
      Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023
      Call trace:
       dump_backtrace+0xdc/0x130
       show_stack+0x1c/0x30
       dump_stack_lvl+0x6c/0x84
       print_report+0x150/0x448
       kasan_report+0x98/0x140
       __asan_load4+0x78/0xa0
       of_irq_parse_raw+0x2b8/0x8d0
       of_irq_parse_one+0x24c/0x270
       parse_interrupts+0xc0/0x120
       of_fwnode_add_links+0x100/0x2d0
       fw_devlink_parse_fwtree+0x64/0xc0
       device_add+0xb38/0xc30
       of_device_add+0x64/0x90
       of_platform_device_create_pdata+0xd0/0x170
       of_platform_bus_create+0x244/0x600
       of_platform_notify+0x1b0/0x254
       blocking_notifier_call_chain+0x9c/0xd0
       __of_changeset_entry_notify+0x1b8/0x230
       __of_changeset_apply_notify+0x54/0xe4
       of_overlay_fdt_apply+0xc04/0xd94
       ...
    
      The buggy address belongs to the object at ffffff81beca5600
       which belongs to the cache kmalloc-128 of size 128
      The buggy address is located 8 bytes inside of
       128-byte region [ffffff81beca5600, ffffff81beca5680)
    
      The buggy address belongs to the physical page:
      page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4
      head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0
      flags: 0x8000000000010200(slab|head|zone=2)
      raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300
      raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
    
      Memory state around the buggy address:
       ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                            ^
       ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      OF:  -> got it !
    
    Prevent the out-of-bounds read by copying the device address into a
    buffer of sufficient size.
    
    Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
    Link: https://lore.kernel.org/r/20240812100652.3800963-1-stefan.wiehler@nokia.com
    Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv [+ + +]
Author: Krishna Kumar <krishnak@linux.ibm.com>
Date:   Mon Jul 1 13:15:06 2024 +0530

    pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv
    
    [ Upstream commit 335e35b748527f0c06ded9eebb65387f60647fda ]
    
    The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
    crash when we try to hot-unplug/disable the PCIe switch/bridge from
    the PHB.
    
    The crash occurs because although the MSI data structure has been
    released during disable/hot-unplug path and it has been assigned
    with NULL, still during unregistration the code was again trying to
    explicitly disable the MSI which causes the NULL pointer dereference and
    kernel crash.
    
    The patch fixes the check during unregistration path to prevent invoking
    pci_disable_msi/msix() since its data structure is already freed.
    
    Reported-by: Timothy Pearson <tpearson@raptorengineering.com>
    Closes: https://lore.kernel.org/all/1981605666.2142272.1703742465927.JavaMail.zimbra@raptorengineeringinc.com/
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Shawn Anastasio <sanastasio@raptorengineering.com>
    Signed-off-by: Krishna Kumar <krishnak@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240701074513.94873-2-krishnak@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI: Add missing bridge lock to pci_bus_lock() [+ + +]
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu May 30 18:04:35 2024 -0700

    PCI: Add missing bridge lock to pci_bus_lock()
    
    [ Upstream commit a4e772898f8bf2e7e1cf661a12c60a5612c4afab ]
    
    One of the true positives that the cfg_access_lock lockdep effort
    identified is this sequence:
    
      WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70
      RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70
      Call Trace:
       <TASK>
       ? __warn+0x8c/0x190
       ? pci_bridge_secondary_bus_reset+0x5d/0x70
       ? report_bug+0x1f8/0x200
       ? handle_bug+0x3c/0x70
       ? exc_invalid_op+0x18/0x70
       ? asm_exc_invalid_op+0x1a/0x20
       ? pci_bridge_secondary_bus_reset+0x5d/0x70
       pci_reset_bus+0x1d8/0x270
       vmd_probe+0x778/0xa10
       pci_device_probe+0x95/0x120
    
    Where pci_reset_bus() users are triggering unlocked secondary bus resets.
    Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses
    pci_bus_lock() before issuing the reset which locks everything *but* the
    bridge itself.
    
    For the same motivation as adding:
    
      bridge = pci_upstream_bridge(dev);
      if (bridge)
        pci_dev_lock(bridge);
    
    to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add
    pci_dev_lock() for @bus->self to pci_bus_lock().
    
    Link: https://lore.kernel.org/r/171711747501.1628941.15217746952476635316.stgit@dwillia2-xfh.jf.intel.com
    Reported-by: Imre Deak <imre.deak@intel.com>
    Closes: http://lore.kernel.org/r/6657833b3b5ae_14984b29437@dwillia2-xfh.jf.intel.com.notmuch
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    [bhelgaas: squash in recursive locking deadlock fix from Keith Busch:
    https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Kalle Valo <kvalo@kernel.org>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pcmcia: Use resource_size function on resource object [+ + +]
Author: Jules Irenge <jbi.octave@gmail.com>
Date:   Sun May 12 23:31:21 2024 +0100

    pcmcia: Use resource_size function on resource object
    
    [ Upstream commit 24a025497e7e883bd2adef5d0ece1e9b9268009f ]
    
    Cocinnele reports a warning
    
    WARNING: Suspicious code. resource_size is maybe missing with root
    
    The root cause is the function resource_size is not used when needed
    
    Use resource_size() on variable "root" of type resource
    
    Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: dell-smbios: Fix error path in dell_smbios_init() [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Fri Aug 30 09:54:28 2024 +0300

    platform/x86: dell-smbios: Fix error path in dell_smbios_init()
    
    [ Upstream commit ffc17e1479e8e9459b7afa80e5d9d40d0dd78abb ]
    
    In case of error in build_tokens_sysfs(), all the memory that has been
    allocated is freed at end of this function. But then free_group() is
    called which performs memory deallocation again.
    
    Also, instead of free_group() call, there should be exit_dell_smbios_smm()
    and exit_dell_smbios_wmi() calls, since there is initialization, but there
    is no release of resources in case of an error.
    
    Fix these issues by replacing free_group() call with
    exit_dell_smbios_wmi() and exit_dell_smbios_smm().
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 33b9ca1e53b4 ("platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Link: https://lore.kernel.org/r/20240830065428.9544-1-amishin@t-argos.ru
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "parisc: Use irq_enter_rcu() to fix warning at kernel/context_tracking.c:367" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 11 15:01:37 2024 +0200

    Revert "parisc: Use irq_enter_rcu() to fix warning at kernel/context_tracking.c:367"
    
    This reverts commit fea29d479eb470102cd025d9279503a2bfd28c60 which is
    commit 73cb4a2d8d7e0259f94046116727084f21e4599f upstream.
    
    It breaks the build on parisc systems, so revert it.
    
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/092aa55c-0538-41e5-8ed0-d0a96b06f32e@roeck-us.net
    Reported-by: Helge Deller <deller@gmx.de>
    Link: https://lore.kernel.org/r/72b133a6-c221-4906-9184-30b4e6ee4260@gmx.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rfkill: fix spelling mistake contidion to condition [+ + +]
Author: Richard Guy Briggs <rgb@redhat.com>
Date:   Mon Jul 23 15:41:38 2018 -0400

    rfkill: fix spelling mistake contidion to condition
    
    [ Upstream commit f404c3ecc401b3617c454c06a3d36a43a01f1aaf ]
    
    This came about while trying to determine if there would be any pattern
    match on contid, a new audit container identifier internal variable.
    This was the only one.
    
    Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: bee2ef946d31 ("net: bridge: br_fdb_external_learn_add(): always set EXT_LEARN")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance() [+ + +]
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Mar 17 17:32:25 2020 -0400

    ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance()
    
    [ Upstream commit bc1a72afdc4a91844928831cac85731566e03bc6 ]
    
    When the ring buffer was first created, the iterator followed the normal
    producer/consumer operations where it had both a peek() operation, that just
    returned the event at the current location, and a read(), that would return
    the event at the current location and also increment the iterator such that
    the next peek() or read() will return the next event.
    
    The only use of the ring_buffer_read() is currently to move the iterator to
    the next location and nothing now actually reads the event it returns.
    Rename this function to its actual use case to ring_buffer_iter_advance(),
    which also adds the "iter" part to the name, which is more meaningful. As
    the timestamp returned by ring_buffer_read() was never used, there's no
    reason that this new version should bother having returning it. It will also
    become a void function.
    
    Link: http://lkml.kernel.org/r/20200317213416.018928618@goodmis.org
    
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Stable-dep-of: 49aa8a1f4d68 ("tracing: Avoid possible softlockup in tracing_iter_reset()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rtmutex: Drop rt_mutex::wait_lock before scheduling [+ + +]
Author: Roland Xu <mu001999@outlook.com>
Date:   Thu Aug 15 10:58:13 2024 +0800

    rtmutex: Drop rt_mutex::wait_lock before scheduling
    
    commit d33d26036a0274b472299d7dcdaa5fb34329f91b upstream.
    
    rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the
    good case it returns with the lock held and in the deadlock case it emits a
    warning and goes into an endless scheduling loop with the lock held, which
    triggers the 'scheduling in atomic' warning.
    
    Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning
    and dropping into the schedule for ever loop.
    
    [ tglx: Moved unlock before the WARN(), removed the pointless comment,
            massaged changelog, added Fixes tag ]
    
    Fixes: 3d5c9340d194 ("rtmutex: Handle deadlock detection smarter")
    Signed-off-by: Roland Xu <mu001999@outlook.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/ME0P300MB063599BEF0743B8FA339C2CECC802@ME0P300MB0635.AUSP300.PROD.OUTLOOK.COM
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sch/netem: fix use after free in netem_dequeue [+ + +]
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Sun Sep 1 11:16:07 2024 -0700

    sch/netem: fix use after free in netem_dequeue
    
    commit 3b3a2a9c6349e25a025d2330f479bc33a6ccb54a upstream.
    
    If netem_dequeue() enqueues packet to inner qdisc and that qdisc
    returns __NET_XMIT_STOLEN. The packet is dropped but
    qdisc_tree_reduce_backlog() is not called to update the parent's
    q.qlen, leading to the similar use-after-free as Commit
    e04991a48dbaf382 ("netem: fix return value if duplicate enqueue
    fails")
    
    Commands to trigger KASAN UaF:
    
    ip link add type dummy
    ip link set lo up
    ip link set dummy0 up
    tc qdisc add dev lo parent root handle 1: drr
    tc filter add dev lo parent 1: basic classid 1:1
    tc class add dev lo classid 1:1 drr
    tc qdisc add dev lo parent 1:1 handle 2: netem
    tc qdisc add dev lo parent 2: handle 3: drr
    tc filter add dev lo parent 3: basic classid 3:1 action mirred egress
    redirect dev dummy0
    tc class add dev lo classid 3:1 drr
    ping -c1 -W0.01 localhost # Trigger bug
    tc class del dev lo classid 1:1
    tc class add dev lo classid 1:1 drr
    ping -c1 -W0.01 localhost # UaF
    
    Fixes: 50612537e9ab ("netem: fix classful handling")
    Reported-by: Budimir Markovic <markovicbudimir@gmail.com>
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Link: https://patch.msgid.link/20240901182438.4992-1-stephen@networkplumber.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smack: tcp: ipv4, fix incorrect labeling [+ + +]
Author: Casey Schaufler <casey@schaufler-ca.com>
Date:   Wed Jun 5 15:41:50 2024 -0700

    smack: tcp: ipv4, fix incorrect labeling
    
    [ Upstream commit 2fe209d0ad2e2729f7e22b9b31a86cc3ff0db550 ]
    
    Currently, Smack mirrors the label of incoming tcp/ipv4 connections:
    when a label 'foo' connects to a label 'bar' with tcp/ipv4,
    'foo' always gets 'foo' in returned ipv4 packets. So,
    1) returned packets are incorrectly labeled ('foo' instead of 'bar')
    2) 'bar' can write to 'foo' without being authorized to write.
    
    Here is a scenario how to see this:
    
    * Take two machines, let's call them C and S,
       with active Smack in the default state
       (no settings, no rules, no labeled hosts, only builtin labels)
    
    * At S, add Smack rule 'foo bar w'
       (labels 'foo' and 'bar' are instantiated at S at this moment)
    
    * At S, at label 'bar', launch a program
       that listens for incoming tcp/ipv4 connections
    
    * From C, at label 'foo', connect to the listener at S.
       (label 'foo' is instantiated at C at this moment)
       Connection succeedes and works.
    
    * Send some data in both directions.
    * Collect network traffic of this connection.
    
    All packets in both directions are labeled with the CIPSO
    of the label 'foo'. Hence, label 'bar' writes to 'foo' without
    being authorized, and even without ever being known at C.
    
    If anybody cares: exactly the same happens with DCCP.
    
    This behavior 1st manifested in release 2.6.29.4 (see Fixes below)
    and it looks unintentional. At least, no explanation was provided.
    
    I changed returned packes label into the 'bar',
    to bring it into line with the Smack documentation claims.
    
    Signed-off-by: Konstantin Andreev <andreev@swemel.ru>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

smack: unix sockets: fix accept()ed socket label [+ + +]
Author: Konstantin Andreev <andreev@swemel.ru>
Date:   Mon Jun 17 01:44:30 2024 +0300

    smack: unix sockets: fix accept()ed socket label
    
    [ Upstream commit e86cac0acdb1a74f608bacefe702f2034133a047 ]
    
    When a process accept()s connection from a unix socket
    (either stream or seqpacket)
    it gets the socket with the label of the connecting process.
    
    For example, if a connecting process has a label 'foo',
    the accept()ed socket will also have 'in' and 'out' labels 'foo',
    regardless of the label of the listener process.
    
    This is because kernel creates unix child sockets
    in the context of the connecting process.
    
    I do not see any obvious way for the listener to abuse
    alien labels coming with the new socket, but,
    to be on the safe side, it's better fix new socket labels.
    
    Signed-off-by: Konstantin Andreev <andreev@swemel.ru>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
smp: Add missing destroy_work_on_stack() call in smp_call_on_cpu() [+ + +]
Author: Zqiang <qiang.zhang1211@gmail.com>
Date:   Thu Jul 4 14:52:13 2024 +0800

    smp: Add missing destroy_work_on_stack() call in smp_call_on_cpu()
    
    [ Upstream commit 77aeb1b685f9db73d276bad4bb30d48505a6fd23 ]
    
    For CONFIG_DEBUG_OBJECTS_WORK=y kernels sscs.work defined by
    INIT_WORK_ONSTACK() is initialized by debug_object_init_on_stack() for
    the debug check in __init_work() to work correctly.
    
    But this lacks the counterpart to remove the tracked object from debug
    objects again, which will cause a debug object warning once the stack is
    freed.
    
    Add the missing destroy_work_on_stack() invocation to cure that.
    
    [ tglx: Massaged changelog ]
    
    Signed-off-by: Zqiang <qiang.zhang1211@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Paul E. McKenney <paulmck@kernel.org>
    Link: https://lore.kernel.org/r/20240704065213.13559-1-qiang.zhang1211@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Squashfs: sanity check symbolic link size [+ + +]
Author: Phillip Lougher <phillip@squashfs.org.uk>
Date:   Mon Aug 12 00:28:21 2024 +0100

    Squashfs: sanity check symbolic link size
    
    [ Upstream commit 810ee43d9cd245d138a2733d87a24858a23f577d ]
    
    Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.
    
    This is caused by an uninitialised page, which is ultimately caused
    by a corrupted symbolic link size read from disk.
    
    The reason why the corrupted symlink size causes an uninitialised
    page is due to the following sequence of events:
    
    1. squashfs_read_inode() is called to read the symbolic
       link from disk.  This assigns the corrupted value
       3875536935 to inode->i_size.
    
    2. Later squashfs_symlink_read_folio() is called, which assigns
       this corrupted value to the length variable, which being a
       signed int, overflows producing a negative number.
    
    3. The following loop that fills in the page contents checks that
       the copied bytes is less than length, which being negative means
       the loop is skipped, producing an uninitialised page.
    
    This patch adds a sanity check which checks that the symbolic
    link size is not larger than expected.
    
    --
    
    Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
    Link: https://lore.kernel.org/r/20240811232821.13903-1-phillip@squashfs.org.uk
    Reported-by: Lizhi Xu <lizhi.xu@windriver.com>
    Reported-by: syzbot+24ac24ff58dc5b0d26b9@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/all/000000000000a90e8c061e86a76b@google.com/
    V2: fix spelling mistake.
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracing: Avoid possible softlockup in tracing_iter_reset() [+ + +]
Author: Zheng Yejian <zhengyejian@huaweicloud.com>
Date:   Tue Aug 27 20:46:54 2024 +0800

    tracing: Avoid possible softlockup in tracing_iter_reset()
    
    [ Upstream commit 49aa8a1f4d6800721c7971ed383078257f12e8f9 ]
    
    In __tracing_open(), when max latency tracers took place on the cpu,
    the time start of its buffer would be updated, then event entries with
    timestamps being earlier than start of the buffer would be skipped
    (see tracing_iter_reset()).
    
    Softlockup will occur if the kernel is non-preemptible and too many
    entries were skipped in the loop that reset every cpu buffer, so add
    cond_resched() to avoid it.
    
    Cc: stable@vger.kernel.org
    Fixes: 2f26ebd549b9a ("tracing: use timestamp to determine start of latency traces")
    Link: https://lore.kernel.org/20240827124654.3817443-1-zhengyejian@huaweicloud.com
    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udf: Avoid excessive partition lengths [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Thu Jun 20 12:52:17 2024 +0200

    udf: Avoid excessive partition lengths
    
    [ Upstream commit ebbe26fd54a9621994bc16b14f2ba8f84c089693 ]
    
    Avoid mounting filesystems where the partition would overflow the
    32-bits used for block number. Also refuse to mount filesystems where
    the partition length is so large we cannot safely index bits in a
    block bitmap.
    
    Link: https://patch.msgid.link/20240620130403.14731-1-jack@suse.cz
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udf: Limit file size to 4TB [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jan 25 17:56:06 2023 +0100

    udf: Limit file size to 4TB
    
    commit c2efd13a2ed4f29bf9ef14ac2fbb7474084655f8 upstream.
    
    UDF disk format supports in principle file sizes up to 1<<64-1. However
    the file space (including holes) is described by a linked list of
    extents, each of which can have at most 1GB. Thus the creation and
    handling of extents gets unusably slow beyond certain point. Limit the
    file size to 4TB to avoid locking up the kernel too easily.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind [+ + +]
Author: Saurabh Sengar <ssengar@linux.microsoft.com>
Date:   Thu Aug 29 12:43:11 2024 +0530

    uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind
    
    commit fb1adbd7e50f3d2de56d0a2bb0700e2e819a329e upstream.
    
    For primary VM Bus channels, primary_channel pointer is always NULL. This
    pointer is valid only for the secondary channels. Also, rescind callback
    is meant for primary channels only.
    
    Fix NULL pointer dereference by retrieving the device_obj from the parent
    for the primary channel.
    
    Cc: stable@vger.kernel.org
    Fixes: ca3cda6fcf1e ("uio_hv_generic: add rescind support")
    Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
    Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
    Link: https://lore.kernel.org/r/20240829071312.1595-2-namjain@linux.microsoft.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
um: line: always fill *error_out in setup_one_line() [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jul 3 17:22:36 2024 +0200

    um: line: always fill *error_out in setup_one_line()
    
    [ Upstream commit 824ac4a5edd3f7494ab1996826c4f47f8ef0f63d ]
    
    The pointer isn't initialized by callers, but I have
    encountered cases where it's still printed; initialize
    it in all possible cases in setup_one_line().
    
    Link: https://patch.msgid.link/20240703172235.ad863568b55f.Iaa1eba4db8265d7715ba71d5f6bb8c7ff63d27e9@changeid
    Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
uprobes: Use kzalloc to allocate xol area [+ + +]
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Tue Sep 3 12:23:12 2024 +0200

    uprobes: Use kzalloc to allocate xol area
    
    commit e240b0fde52f33670d1336697c22d90a4fe33c84 upstream.
    
    To prevent unitialized members, use kzalloc to allocate
    the xol area.
    
    Fixes: b059a453b1cf1 ("x86/vdso: Add mremap hook to vm_special_mapping")
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Link: https://lore.kernel.org/r/20240903102313.3402529-1-svens@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc3: st: add missing depopulate in probe error path [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Aug 14 11:39:57 2024 +0200

    usb: dwc3: st: add missing depopulate in probe error path
    
    [ Upstream commit cd4897bfd14f6a5388b21ba45a066541a0425199 ]
    
    Depopulate device in probe error paths to fix leak of children
    resources.
    
    Fixes: f83fca0707c6 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240814093957.37940-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: st: Add of_node_put() before return in probe function [+ + +]
Author: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date:   Mon Aug 19 12:54:35 2019 +0530

    usb: dwc3: st: Add of_node_put() before return in probe function
    
    [ Upstream commit e36721b90144bb46e1b6477be3ab63439c7fb79b ]
    
    The local variable child in the function st_dwc3_probe takes the return
    value of of_get_child_by_name, which gets a node and does not put it. If
    the function returns without releasing child, this could cause a memory
    error. Hence put child as soon as there is no more use for it. Also
    create a new label, err_node_put, just before label undo_softreset; so
    that err_node_put puts child. In between initialisation of child and its
    first put, modify all statements that go to undo_softreset to now go to
    err_node_put instead, from where they can fall through to
    undo_softreset.
    Issue found with Coccinelle.
    
    Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
    Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Stable-dep-of: cd4897bfd14f ("usb: dwc3: st: add missing depopulate in probe error path")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usbip: Don't submit special requests twice [+ + +]
Author: Simon Holesch <simon@holesch.de>
Date:   Sun May 19 16:15:38 2024 +0200

    usbip: Don't submit special requests twice
    
    [ Upstream commit 8b6b386f9aa936ed0c190446c71cf59d4a507690 ]
    
    Skip submitting URBs, when identical requests were already sent in
    tweak_special_requests(). Instead call the completion handler directly
    to return the result of the URB.
    
    Even though submitting those requests twice should be harmless, there
    are USB devices that react poorly to some duplicated requests.
    
    One example is the ChipIdea controller implementation in U-Boot: The
    second SET_CONFIGURATION request makes U-Boot disable and re-enable all
    endpoints. Re-enabling an endpoint in the ChipIdea controller, however,
    was broken until U-Boot commit b272c8792502 ("usb: ci: Fix gadget
    reinit").
    
    Signed-off-by: Simon Holesch <simon@holesch.de>
    Acked-by: Shuah Khan <skhan@linuxfoundation.org>
    Reviewed-by: Hongren Zheng <i@zenithal.me>
    Tested-by: Hongren Zheng <i@zenithal.me>
    Link: https://lore.kernel.org/r/20240519141922.171460-1-simon@holesch.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usbnet: ipheth: race between ipheth_close and error handling [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Aug 6 19:28:05 2024 +0200

    usbnet: ipheth: race between ipheth_close and error handling
    
    [ Upstream commit e5876b088ba03a62124266fa20d00e65533c7269 ]
    
    ipheth_sndbulk_callback() can submit carrier_work
    as a part of its error handling. That means that
    the driver must make sure that the work is cancelled
    after it has made sure that no more URB can terminate
    with an error condition.
    
    Hence the order of actions in ipheth_close() needs
    to be inverted.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Foster Snowhill <forst@pen.gy>
    Tested-by: Georgi Valkov <gvalkov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usbnet: modern method to get random MAC [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Aug 29 19:50:55 2024 +0200

    usbnet: modern method to get random MAC
    
    [ Upstream commit bab8eb0dd4cb995caa4a0529d5655531c2ec5e8e ]
    
    The driver generates a random MAC once on load
    and uses it over and over, including on two devices
    needing a random MAC at the same time.
    
    Jakub suggested revamping the driver to the modern
    API for setting a random MAC rather than fixing
    the old stuff.
    
    The bug is as old as the driver.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Link: https://patch.msgid.link/20240829175201.670718-1-oneukum@suse.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio_net: Fix napi_skb_cache_put warning [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Fri Jul 12 04:53:25 2024 -0700

    virtio_net: Fix napi_skb_cache_put warning
    
    commit f8321fa75102246d7415a6af441872f6637c93ab upstream.
    
    After the commit bdacf3e34945 ("net: Use nested-BH locking for
    napi_alloc_cache.") was merged, the following warning began to appear:
    
             WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0
    
              __warn+0x12f/0x340
              napi_skb_cache_put+0x82/0x4b0
              napi_skb_cache_put+0x82/0x4b0
              report_bug+0x165/0x370
              handle_bug+0x3d/0x80
              exc_invalid_op+0x1a/0x50
              asm_exc_invalid_op+0x1a/0x20
              __free_old_xmit+0x1c8/0x510
              napi_skb_cache_put+0x82/0x4b0
              __free_old_xmit+0x1c8/0x510
              __free_old_xmit+0x1c8/0x510
              __pfx___free_old_xmit+0x10/0x10
    
    The issue arises because virtio is assuming it's running in NAPI context
    even when it's not, such as in the netpoll case.
    
    To resolve this, modify virtnet_poll_tx() to only set NAPI when budget
    is available. Same for virtnet_poll_cleantx(), which always assumed that
    it was in a NAPI context.
    
    Fixes: df133f3f9625 ("virtio_net: bulk free tx skbs")
    Suggested-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: Jakub Kicinski <kuba@kernel.org>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Heng Qi <hengqi@linux.alibaba.com>
    Link: https://patch.msgid.link/20240712115325.54175-1-leitao@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [Shivani: Modified to apply on v4.19.y-v5.10.y]
    Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
VMCI: Fix use-after-free when removing resource in vmci_resource_remove() [+ + +]
Author: David Fernandez Gonzalez <david.fernandez.gonzalez@oracle.com>
Date:   Wed Aug 28 15:43:37 2024 +0000

    VMCI: Fix use-after-free when removing resource in vmci_resource_remove()
    
    commit 48b9a8dabcc3cf5f961b2ebcd8933bf9204babb7 upstream.
    
    When removing a resource from vmci_resource_table in
    vmci_resource_remove(), the search is performed using the resource
    handle by comparing context and resource fields.
    
    It is possible though to create two resources with different types
    but same handle (same context and resource fields).
    
    When trying to remove one of the resources, vmci_resource_remove()
    may not remove the intended one, but the object will still be freed
    as in the case of the datagram type in vmci_datagram_destroy_handle().
    vmci_resource_table will still hold a pointer to this freed resource
    leading to a use-after-free vulnerability.
    
    BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
    BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
    Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106
     print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239
     __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425
     kasan_report+0x38/0x51 mm/kasan/report.c:442
     vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
     vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
     vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182
     ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444
     kref_put include/linux/kref.h:65 [inline]
     vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]
     vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195
     vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143
     __fput+0x261/0xa34 fs/file_table.c:282
     task_work_run+0xf0/0x194 kernel/task_work.c:164
     tracehook_notify_resume include/linux/tracehook.h:189 [inline]
     exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187
     exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220
     __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]
     syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313
     do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86
     entry_SYSCALL_64_after_hwframe+0x6e/0x0
    
    This change ensures the type is also checked when removing
    the resource from vmci_resource_table in vmci_resource_remove().
    
    Fixes: bc63dedb7d46 ("VMCI: resource object implementation.")
    Cc: stable@vger.kernel.org
    Reported-by: George Kennedy <george.kennedy@oracle.com>
    Signed-off-by: David Fernandez Gonzalez <david.fernandez.gonzalez@oracle.com>
    Link: https://lore.kernel.org/r/20240828154338.754746-1-david.fernandez.gonzalez@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: brcmsmac: advertise MFP_CAPABLE to enable WPA3 [+ + +]
Author: Arend van Spriel <arend.vanspriel@broadcom.com>
Date:   Mon Jun 17 14:26:09 2024 +0200

    wifi: brcmsmac: advertise MFP_CAPABLE to enable WPA3
    
    [ Upstream commit dbb5265a5d7cca1cdba7736dba313ab7d07bc19d ]
    
    After being asked about support for WPA3 for BCM43224 chipset it
    was found that all it takes is setting the MFP_CAPABLE flag and
    mac80211 will take care of all that is needed [1].
    
    Link: https://lore.kernel.org/linux-wireless/20200526155909.5807-2-Larry.Finger@lwfinger.net/ [1]
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Tested-by: Reijer Boekhoff <reijerboekhoff@protonmail.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240617122609.349582-1-arend.vanspriel@broadcom.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id() [+ + +]
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Wed Jul 3 09:24:09 2024 +0200

    wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()
    
    [ Upstream commit c145eea2f75ff7949392aebecf7ef0a81c1f6c14 ]
    
    mwifiex_get_priv_by_id() returns the priv pointer corresponding to
    the bss_num and bss_type, but without checking if the priv is actually
    currently in use.
    Unused priv pointers do not have a wiphy attached to them which can
    lead to NULL pointer dereferences further down the callstack.  Fix
    this by returning only used priv pointers which have priv->bss_mode
    set to something else than NL80211_IFTYPE_UNSPECIFIED.
    
    Said NULL pointer dereference happened when an Accesspoint was started
    with wpa_supplicant -i mlan0 with this config:
    
    network={
            ssid="somessid"
            mode=2
            frequency=2412
            key_mgmt=WPA-PSK WPA-PSK-SHA256
            proto=RSN
            group=CCMP
            pairwise=CCMP
            psk="12345678"
    }
    
    When waiting for the AP to be established, interrupting wpa_supplicant
    with <ctrl-c> and starting it again this happens:
    
    | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140
    | Mem abort info:
    |   ESR = 0x0000000096000004
    |   EC = 0x25: DABT (current EL), IL = 32 bits
    |   SET = 0, FnV = 0
    |   EA = 0, S1PTW = 0
    |   FSC = 0x04: level 0 translation fault
    | Data abort info:
    |   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
    |   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    |   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000
    | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000
    | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
    | Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio
    +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs
    +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6
    | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18
    | Hardware name: somemachine (DT)
    | Workqueue: events sdio_irq_work
    | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]
    | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]
    | sp : ffff8000818b3a70
    | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004
    | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9
    | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000
    | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000
    | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517
    | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1
    | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157
    | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124
    | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000
    | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000
    | Call trace:
    |  mwifiex_get_cfp+0xd8/0x15c [mwifiex]
    |  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]
    |  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]
    |  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]
    |  mwifiex_process_event+0x110/0x238 [mwifiex]
    |  mwifiex_main_process+0x428/0xa44 [mwifiex]
    |  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]
    |  process_sdio_pending_irqs+0x64/0x1b8
    |  sdio_irq_work+0x4c/0x7c
    |  process_one_work+0x148/0x2a0
    |  worker_thread+0x2fc/0x40c
    |  kthread+0x110/0x114
    |  ret_from_fork+0x10/0x20
    | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)
    | ---[ end trace 0000000000000000 ]---
    
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Acked-by: Brian Norris <briannorris@chromium.org>
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240703072409.556618-1-s.hauer@pengutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>