Changelog in Linux kernel 5.15.167

 
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/conexant: Mute speakers at suspend / shutdown [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jul 26 16:26:20 2024 +0200

    ALSA: hda/conexant: Mute speakers at suspend / shutdown
    
    [ Upstream commit 4f61c8fe35202702426cfc0003e15116a01ba885 ]
    
    Use the new helper to mute speakers at suspend / shutdown for avoiding
    click noises.
    
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1228269
    Link: https://patch.msgid.link/20240726142625.2460-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/generic: Add a helper to mute speakers at suspend/shutdown [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jul 26 16:26:19 2024 +0200

    ALSA: hda/generic: Add a helper to mute speakers at suspend/shutdown
    
    [ Upstream commit 6cd23b26b348fa52c88e1adf9c0e48d68e13f95e ]
    
    Some devices indicate click noises at suspend or shutdown when the
    speakers are unmuted.  This patch adds a helper,
    snd_hda_gen_shutup_speakers(), to work around it.  The new function is
    supposed to be called at suspend or shutdown by the codec driver, and
    it mutes the speakers.
    
    The mute status isn't cached, hence the original mute state will be
    restored at resume again.
    
    Link: https://patch.msgid.link/20240726142625.2460-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: add patch for internal mic in Lenovo V145 [+ + +]
Author: Terry Cheong <htcheong@chromium.org>
Date:   Fri Aug 30 04:11:53 2024 +0800

    ALSA: hda/realtek: add patch for internal mic in Lenovo V145
    
    commit ef27e89e7f3015be2b3c124833fbd6d2e4686561 upstream.
    
    Lenovo V145 is having phase inverted dmic but simply applying inverted
    dmic fixups does not work. Chaining up verb fixes for ALC283 enables
    inverting dmic fixup to work properly.
    
    Signed-off-by: Terry Cheong <htcheong@chromium.org>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240830-lenovo-v145-fixes-v3-1-f7b7265068fa@chromium.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Support mute LED on HP Laptop 14-dq2xxx [+ + +]
Author: Maximilien Perreault <maximilienperreault@gmail.com>
Date:   Tue Sep 3 20:10:13 2024 -0700

    ALSA: hda/realtek: Support mute LED on HP Laptop 14-dq2xxx
    
    commit 47a9e8dbb8d4713a9aac7cc6ce3c82dcc94217d8 upstream.
    
    The mute LED on this HP laptop uses ALC236 and requires a quirk to function. This patch enables the existing quirk for the device.
    
    Signed-off-by: Maximilien Perreault <maximilienperreault@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240904031013.21220-1-maximilienperreault@gmail.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>

 
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>

 
arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Wed May 29 14:34:39 2024 +0100

    arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
    
    [ Upstream commit 2488444274c70038eb6b686cba5f1ce48ebb9cdd ]
    
    In a review discussion of the changes to support vCPU hotplug where
    a check was added on the GICC being enabled if was online, it was
    noted that there is need to map back to the cpu and use that to index
    into a cpumask. As such, a valid ID is needed.
    
    If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible
    for the entry in cpu_madt_gicc[cpu] == NULL.  This function would
    then cause a NULL pointer dereference.   Whilst a path to trigger
    this has not been established, harden this caller against the
    possibility.
    
    Reviewed-by: Gavin Shan <gshan@redhat.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20240529133446.28446-13-Jonathan.Cameron@huawei.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: acpi: Move get_cpu_for_acpi_id() to a header [+ + +]
Author: James Morse <james.morse@arm.com>
Date:   Wed May 29 14:34:38 2024 +0100

    arm64: acpi: Move get_cpu_for_acpi_id() to a header
    
    [ Upstream commit 8d34b6f17b9ac93faa2791eb037dcb08bdf755de ]
    
    ACPI identifies CPUs by UID. get_cpu_for_acpi_id() maps the ACPI UID
    to the Linux CPU number.
    
    The helper to retrieve this mapping is only available in arm64's NUMA
    code.
    
    Move it to live next to get_acpi_id_for_cpu().
    
    Signed-off-by: James Morse <james.morse@arm.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Gavin Shan <gshan@redhat.com>
    Tested-by: Miguel Luis <miguel.luis@oracle.com>
    Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
    Tested-by: Jianyong Wu <jianyong.wu@arm.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Acked-by: Hanjun Guo <guohanjun@huawei.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
    Link: https://lore.kernel.org/r/20240529133446.28446-12-Jonathan.Cameron@huawei.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: dapm: Fix UAF for snd_soc_pcm_runtime object [+ + +]
Author: robelin <robelin@nvidia.com>
Date:   Fri Aug 23 14:43:41 2024 +0000

    ASoC: dapm: Fix UAF for snd_soc_pcm_runtime object
    
    commit b4a90b543d9f62d3ac34ec1ab97fc5334b048565 upstream.
    
    When using kernel with the following extra config,
    
      - CONFIG_KASAN=y
      - CONFIG_KASAN_GENERIC=y
      - CONFIG_KASAN_INLINE=y
      - CONFIG_KASAN_VMALLOC=y
      - CONFIG_FRAME_WARN=4096
    
    kernel detects that snd_pcm_suspend_all() access a freed
    'snd_soc_pcm_runtime' object when the system is suspended, which
    leads to a use-after-free bug:
    
    [   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270
    [   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330
    
    [   52.047785] Call trace:
    [   52.047787]  dump_backtrace+0x0/0x3c0
    [   52.047794]  show_stack+0x34/0x50
    [   52.047797]  dump_stack_lvl+0x68/0x8c
    [   52.047802]  print_address_description.constprop.0+0x74/0x2c0
    [   52.047809]  kasan_report+0x210/0x230
    [   52.047815]  __asan_report_load1_noabort+0x3c/0x50
    [   52.047820]  snd_pcm_suspend_all+0x1a8/0x270
    [   52.047824]  snd_soc_suspend+0x19c/0x4e0
    
    The snd_pcm_sync_stop() has a NULL check on 'substream->runtime' before
    making any access. So we need to always set 'substream->runtime' to NULL
    everytime we kfree() it.
    
    Fixes: a72706ed8208 ("ASoC: codec2codec: remove ephemeral variables")
    Signed-off-by: robelin <robelin@nvidia.com>
    Signed-off-by: Sameer Pujar <spujar@nvidia.com>
    Link: https://patch.msgid.link/20240823144342.4123814-2-spujar@nvidia.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: sunxi: sun4i-i2s: fix LRCLK polarity in i2s mode [+ + +]
Author: Matteo Martelli <matteomartelli3@gmail.com>
Date:   Thu Aug 1 14:07:19 2024 +0200

    ASoC: sunxi: sun4i-i2s: fix LRCLK polarity in i2s mode
    
    [ Upstream commit 3e83957e8dd7433a69116780d9bad217b00913ea ]
    
    This fixes the LRCLK polarity for sun8i-h3 and sun50i-h6 in i2s mode
    which was wrongly inverted.
    
    The LRCLK was being set in reversed logic compared to the DAI format:
    inverted LRCLK for SND_SOC_DAIFMT_IB_NF and SND_SOC_DAIFMT_NB_NF; normal
    LRCLK for SND_SOC_DAIFMT_IB_IF and SND_SOC_DAIFMT_NB_IF. Such reversed
    logic applies properly for DSP_A, DSP_B, LEFT_J and RIGHT_J modes but
    not for I2S mode, for which the LRCLK signal results reversed to what
    expected on the bus. The issue is due to a misinterpretation of the
    LRCLK polarity bit of the H3 and H6 i2s controllers. Such bit in this
    case does not mean "0 => normal" or "1 => inverted" according to the
    expected bus operation, but it means "0 => frame starts on low edge" and
    "1 => frame starts on high edge" (from the User Manuals).
    
    This commit fixes the LRCLK polarity by setting the LRCLK polarity bit
    according to the selected bus mode and renames the LRCLK polarity bit
    definition to avoid further confusion.
    
    Fixes: dd657eae8164 ("ASoC: sun4i-i2s: Fix the LRCK polarity")
    Fixes: 73adf87b7a58 ("ASoC: sun4i-i2s: Add support for H6 I2S")
    Signed-off-by: Matteo Martelli <matteomartelli3@gmail.com>
    Link: https://patch.msgid.link/20240801-asoc-fix-sun4i-i2s-v2-1-a8e4e9daa363@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: topology: Properly initialize soc_enum values [+ + +]
Author: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Date:   Thu Jun 27 12:18:40 2024 +0200

    ASoC: topology: Properly initialize soc_enum values
    
    [ Upstream commit 8ec2a2643544ce352f012ad3d248163199d05dfc ]
    
    soc_tplg_denum_create_values() should properly set its values field.
    
    Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Link: https://patch.msgid.link/20240627101850.2191513-4-amadeuszx.slawinski@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    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>

 
bareudp: Fix device stats updates. [+ + +]
Author: Guillaume Nault <gnault@redhat.com>
Date:   Fri Aug 30 17:31:07 2024 +0200

    bareudp: Fix device stats updates.
    
    [ Upstream commit 4963d2343af81f493519f9c3ea9f2169eaa7353a ]
    
    Bareudp devices update their stats concurrently.
    Therefore they need proper atomic increments.
    
    Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
    Signed-off-by: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://patch.msgid.link/04b7b9d0b480158eb3ab4366ec80aa2ab7e41fcb.1725031794.git.gnault@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
binder: fix UAF caused by offsets overwrite [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Thu Aug 22 18:23:52 2024 +0000

    binder: fix UAF caused by offsets overwrite
    
    commit 4df153652cc46545722879415937582028c18af5 upstream.
    
    Binder objects are processed and copied individually into the target
    buffer during transactions. Any raw data in-between these objects is
    copied as well. However, this raw data copy lacks an out-of-bounds
    check. If the raw data exceeds the data section size then the copy
    overwrites the offsets section. This eventually triggers an error that
    attempts to unwind the processed objects. However, at this point the
    offsets used to index these objects are now corrupted.
    
    Unwinding with corrupted offsets can result in decrements of arbitrary
    nodes and lead to their premature release. Other users of such nodes are
    left with a dangling pointer triggering a use-after-free. This issue is
    made evident by the following KASAN report (trimmed):
    
      ==================================================================
      BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c
      Write of size 4 at addr ffff47fc91598f04 by task binder-util/743
    
      CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1
      Hardware name: linux,dummy-virt (DT)
      Call trace:
       _raw_spin_lock+0xe4/0x19c
       binder_free_buf+0x128/0x434
       binder_thread_write+0x8a4/0x3260
       binder_ioctl+0x18f0/0x258c
      [...]
    
      Allocated by task 743:
       __kmalloc_cache_noprof+0x110/0x270
       binder_new_node+0x50/0x700
       binder_transaction+0x413c/0x6da8
       binder_thread_write+0x978/0x3260
       binder_ioctl+0x18f0/0x258c
      [...]
    
      Freed by task 745:
       kfree+0xbc/0x208
       binder_thread_read+0x1c5c/0x37d4
       binder_ioctl+0x16d8/0x258c
      [...]
      ==================================================================
    
    To avoid this issue, let's check that the raw data copy is within the
    boundaries of the data section.
    
    Fixes: 6d98eb95b450 ("binder: avoid potential data leakage when copying txn")
    Cc: Todd Kjos <tkjos@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20240822182353.2129600-1-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
block: remove the blk_flush_integrity call in blk_integrity_unregister [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Jun 13 10:48:16 2024 +0200

    block: remove the blk_flush_integrity call in blk_integrity_unregister
    
    [ Upstream commit e8bc14d116aeac8f0f133ec8d249acf4e0658da7 ]
    
    Now that there are no indirect calls for PI processing there is no
    way to dereference a NULL pointer here.  Additionally drivers now always
    freeze the queue (or in case of stacking drivers use their internal
    equivalent) around changing the integrity profile.
    
    This is effectively a revert of commit 3df49967f6f1 ("block: flush the
    integrity workqueue in blk_integrity_unregister").
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Link: https://lore.kernel.org/r/20240613084839.1044015-7-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: MGMT: Ignore keys being loaded with invalid type [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Aug 27 15:01:34 2024 -0400

    Bluetooth: MGMT: Ignore keys being loaded with invalid type
    
    commit 1e9683c9b6ca88cc9340cdca85edd6134c8cffe3 upstream.
    
    Due to 59b047bc98084f8af2c41483e4d68a5adf2fa7f7 there could be keys stored
    with the wrong address type so this attempt to detect it and ignore them
    instead of just failing to load all keys.
    
    Cc: stable@vger.kernel.org
    Link: https://github.com/bluez/bluez/issues/875
    Fixes: 59b047bc9808 ("Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: fix race between direct IO write and fsync when using same fd [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Aug 29 18:25:49 2024 +0100

    btrfs: fix race between direct IO write and fsync when using same fd
    
    commit cd9253c23aedd61eb5ff11f37a36247cd46faf86 upstream.
    
    If we have 2 threads that are using the same file descriptor and one of
    them is doing direct IO writes while the other is doing fsync, we have a
    race where we can end up either:
    
    1) Attempt a fsync without holding the inode's lock, triggering an
       assertion failures when assertions are enabled;
    
    2) Do an invalid memory access from the fsync task because the file private
       points to memory allocated on stack by the direct IO task and it may be
       used by the fsync task after the stack was destroyed.
    
    The race happens like this:
    
    1) A user space program opens a file descriptor with O_DIRECT;
    
    2) The program spawns 2 threads using libpthread for example;
    
    3) One of the threads uses the file descriptor to do direct IO writes,
       while the other calls fsync using the same file descriptor.
    
    4) Call task A the thread doing direct IO writes and task B the thread
       doing fsyncs;
    
    5) Task A does a direct IO write, and at btrfs_direct_write() sets the
       file's private to an on stack allocated private with the member
       'fsync_skip_inode_lock' set to true;
    
    6) Task B enters btrfs_sync_file() and sees that there's a private
       structure associated to the file which has 'fsync_skip_inode_lock' set
       to true, so it skips locking the inode's VFS lock;
    
    7) Task A completes the direct IO write, and resets the file's private to
       NULL since it had no prior private and our private was stack allocated.
       Then it unlocks the inode's VFS lock;
    
    8) Task B enters btrfs_get_ordered_extents_for_logging(), then the
       assertion that checks the inode's VFS lock is held fails, since task B
       never locked it and task A has already unlocked it.
    
    The stack trace produced is the following:
    
       assertion failed: inode_is_locked(&inode->vfs_inode), in fs/btrfs/ordered-data.c:983
       ------------[ cut here ]------------
       kernel BUG at fs/btrfs/ordered-data.c:983!
       Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI
       CPU: 9 PID: 5072 Comm: worker Tainted: G     U     OE      6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8
       Hardware name: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 07/28/2020
       RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs]
       Code: 50 d6 86 c0 e8 (...)
       RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246
       RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800
       RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38
       R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800
       R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000
       FS:  00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0
       Call Trace:
        <TASK>
        ? __die_body.cold+0x14/0x24
        ? die+0x2e/0x50
        ? do_trap+0xca/0x110
        ? do_error_trap+0x6a/0x90
        ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]
        ? exc_invalid_op+0x50/0x70
        ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]
        ? asm_exc_invalid_op+0x1a/0x20
        ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]
        ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]
        btrfs_sync_file+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]
        ? __seccomp_filter+0x31d/0x4f0
        __x64_sys_fdatasync+0x4f/0x90
        do_syscall_64+0x82/0x160
        ? do_futex+0xcb/0x190
        ? __x64_sys_futex+0x10e/0x1d0
        ? switch_fpu_return+0x4f/0xd0
        ? syscall_exit_to_user_mode+0x72/0x220
        ? do_syscall_64+0x8e/0x160
        ? syscall_exit_to_user_mode+0x72/0x220
        ? do_syscall_64+0x8e/0x160
        ? syscall_exit_to_user_mode+0x72/0x220
        ? do_syscall_64+0x8e/0x160
        ? syscall_exit_to_user_mode+0x72/0x220
        ? do_syscall_64+0x8e/0x160
        entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Another problem here is if task B grabs the private pointer and then uses
    it after task A has finished, since the private was allocated in the stack
    of task A, it results in some invalid memory access with a hard to predict
    result.
    
    This issue, triggering the assertion, was observed with QEMU workloads by
    two users in the Link tags below.
    
    Fix this by not relying on a file's private to pass information to fsync
    that it should skip locking the inode and instead pass this information
    through a special value stored in current->journal_info. This is safe
    because in the relevant section of the direct IO write path we are not
    holding a transaction handle, so current->journal_info is NULL.
    
    The following C program triggers the issue:
    
       $ cat repro.c
       /* Get the O_DIRECT definition. */
       #ifndef _GNU_SOURCE
       #define _GNU_SOURCE
       #endif
    
       #include <stdio.h>
       #include <stdlib.h>
       #include <unistd.h>
       #include <stdint.h>
       #include <fcntl.h>
       #include <errno.h>
       #include <string.h>
       #include <pthread.h>
    
       static int fd;
    
       static ssize_t do_write(int fd, const void *buf, size_t count, off_t offset)
       {
           while (count > 0) {
               ssize_t ret;
    
               ret = pwrite(fd, buf, count, offset);
               if (ret < 0) {
                   if (errno == EINTR)
                       continue;
                   return ret;
               }
               count -= ret;
               buf += ret;
           }
           return 0;
       }
    
       static void *fsync_loop(void *arg)
       {
           while (1) {
               int ret;
    
               ret = fsync(fd);
               if (ret != 0) {
                   perror("Fsync failed");
                   exit(6);
               }
           }
       }
    
       int main(int argc, char *argv[])
       {
           long pagesize;
           void *write_buf;
           pthread_t fsyncer;
           int ret;
    
           if (argc != 2) {
               fprintf(stderr, "Use: %s <file path>\n", argv[0]);
               return 1;
           }
    
           fd = open(argv[1], O_WRONLY | O_CREAT | O_TRUNC | O_DIRECT, 0666);
           if (fd == -1) {
               perror("Failed to open/create file");
               return 1;
           }
    
           pagesize = sysconf(_SC_PAGE_SIZE);
           if (pagesize == -1) {
               perror("Failed to get page size");
               return 2;
           }
    
           ret = posix_memalign(&write_buf, pagesize, pagesize);
           if (ret) {
               perror("Failed to allocate buffer");
               return 3;
           }
    
           ret = pthread_create(&fsyncer, NULL, fsync_loop, NULL);
           if (ret != 0) {
               fprintf(stderr, "Failed to create writer thread: %d\n", ret);
               return 4;
           }
    
           while (1) {
               ret = do_write(fd, write_buf, pagesize, 0);
               if (ret != 0) {
                   perror("Write failed");
                   exit(5);
               }
           }
    
           return 0;
       }
    
       $ mkfs.btrfs -f /dev/sdi
       $ mount /dev/sdi /mnt/sdi
       $ timeout 10 ./repro /mnt/sdi/foo
    
    Usually the race is triggered within less than 1 second. A test case for
    fstests will follow soon.
    
    Reported-by: Paulo Dias <paulo.miguel.dias@gmail.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219187
    Reported-by: Andreas Jahn <jahn-andi@web.de>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219199
    Reported-by: syzbot+4704b3cc972bd76024f1@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/linux-btrfs/00000000000044ff540620d7dee2@google.com/
    Fixes: 939b656bc8ab ("btrfs: fix corruption after buffer fault in during direct IO append write")
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

btrfs: replace BUG_ON() with error handling at update_ref_for_cow() [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Jun 18 15:55:16 2024 +0100

    btrfs: replace BUG_ON() with error handling at update_ref_for_cow()
    
    [ Upstream commit b56329a782314fde5b61058e2a25097af7ccb675 ]
    
    Instead of a BUG_ON() just return an error, log an error message and
    abort the transaction in case we find an extent buffer belonging to the
    relocation tree that doesn't have the full backref flag set. This is
    unexpected and should never happen (save for bugs or a potential bad
    memory).
    
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
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>

can: m_can: Release irq on error in m_can_open [+ + +]
Author: Simon Horman <horms@kernel.org>
Date:   Mon Aug 5 15:01:58 2024 +0100

    can: m_can: Release irq on error in m_can_open
    
    [ Upstream commit 06d4ef3056a7ac31be331281bb7a6302ef5a7f8a ]
    
    It appears that the irq requested in m_can_open() may be leaked
    if an error subsequently occurs: if m_can_start() fails.
    
    Address this by calling free_irq in the unwind path for
    such cases.
    
    Flagged by Smatch.
    Compile tested only.
    
    Fixes: eaacfeaca7ad ("can: m_can: Call the RAM init directly from m_can_chip_config")
    Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/all/20240805-mcan-irq-v2-1-7154c0484819@kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open [+ + +]
Author: Simon Arlott <simon@octiron.net>
Date:   Thu Aug 22 08:25:07 2024 +0100

    can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open
    
    commit 7dd9c26bd6cf679bcfdef01a8659791aa6487a29 upstream.
    
    The mcp251x_hw_wake() function is called with the mpc_lock mutex held and
    disables the interrupt handler so that no interrupts can be processed while
    waking the device. If an interrupt has already occurred then waiting for
    the interrupt handler to complete will deadlock because it will be trying
    to acquire the same mutex.
    
    CPU0                           CPU1
    ----                           ----
    mcp251x_open()
     mutex_lock(&priv->mcp_lock)
      request_threaded_irq()
                                   <interrupt>
                                   mcp251x_can_ist()
                                    mutex_lock(&priv->mcp_lock)
      mcp251x_hw_wake()
       disable_irq() <-- deadlock
    
    Use disable_irq_nosync() instead because the interrupt handler does
    everything while holding the mutex so it doesn't matter if it's still
    running.
    
    Fixes: 8ce8c0abcba3 ("can: mcp251x: only reset hardware as required")
    Signed-off-by: Simon Arlott <simon@octiron.net>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/4fc08687-1d80-43fe-9f0d-8ef8475e75f6@0882a8b5-c6c3-11e9-b005-00805fc181fe.uuid.home.arpa
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
cifs: Check the lease context if we actually got a lease [+ + +]
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date:   Fri Feb 17 13:35:00 2023 +1000

    cifs: Check the lease context if we actually got a lease
    
    commit 66d45ca1350a3bb8d5f4db8879ccad3ed492337a upstream.
    
    Some servers may return that we got a lease in rsp->OplockLevel
    but then in the lease context contradict this and say we got no lease
    at all.  Thus we need to check the context if we have a lease.
    Additionally, If we do not get a lease we need to make sure we close
    the handle before we return an error to the caller.
    
    Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Bharath SM <bharathsm@microsoft.com>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Meetakshi Setiya <msetiya@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

clk: qcom: clk-alpha-pll: Fix the trion pll postdiv set rate API [+ + +]
Author: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
Date:   Wed Jul 31 11:59:10 2024 +0530

    clk: qcom: clk-alpha-pll: Fix the trion pll postdiv set rate API
    
    commit 4ad1ed6ef27cab94888bb3c740c14042d5c0dff2 upstream.
    
    Correct the pll postdiv shift used in clk_trion_pll_postdiv_set_rate
    API. The shift value is not same for different types of plls and
    should be taken from the pll's .post_div_shift member.
    
    Fixes: 548a909597d5 ("clk: qcom: clk-alpha-pll: Add support for Trion PLLs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240731062916.2680823-3-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>

 
clocksource/drivers/timer-of: Remove percpu irq related code [+ + +]
Author: Daniel Lezcano <daniel.lezcano@linaro.org>
Date:   Mon Aug 19 12:03:35 2024 +0200

    clocksource/drivers/timer-of: Remove percpu irq related code
    
    commit 471ef0b5a8aaca4296108e756b970acfc499ede4 upstream.
    
    GCC's named address space checks errors out with:
    
    drivers/clocksource/timer-of.c: In function ‘timer_of_irq_exit’:
    drivers/clocksource/timer-of.c:29:46: error: passing argument 2 of
    ‘free_percpu_irq’ from pointer to non-enclosed address space
      29 |                 free_percpu_irq(of_irq->irq, clkevt);
         |                                              ^~~~~~
    In file included from drivers/clocksource/timer-of.c:8:
    ./include/linux/interrupt.h:201:43: note: expected ‘__seg_gs void *’
    but argument is of type ‘struct clock_event_device *’
     201 | extern void free_percpu_irq(unsigned int, void __percpu *);
         |                                           ^~~~~~~~~~~~~~~
    drivers/clocksource/timer-of.c: In function ‘timer_of_irq_init’:
    drivers/clocksource/timer-of.c:74:51: error: passing argument 4 of
    ‘request_percpu_irq’ from pointer to non-enclosed address space
      74 |                                    np->full_name, clkevt) :
         |                                                   ^~~~~~
    ./include/linux/interrupt.h:190:56: note: expected ‘__seg_gs void *’
    but argument is of type ‘struct clock_event_device *’
     190 |                    const char *devname, void __percpu *percpu_dev_id)
    
    Sparse warns about:
    
    timer-of.c:29:46: warning: incorrect type in argument 2 (different address spaces)
    timer-of.c:29:46:    expected void [noderef] __percpu *
    timer-of.c:29:46:    got struct clock_event_device *clkevt
    timer-of.c:74:51: warning: incorrect type in argument 4 (different address spaces)
    timer-of.c:74:51:    expected void [noderef] __percpu *percpu_dev_id
    timer-of.c:74:51:    got struct clock_event_device *clkevt
    
    It appears the code is incorrect as reported by Uros Bizjak:
    
    "The referred code is questionable as it tries to reuse
    the clkevent pointer once as percpu pointer and once as generic
    pointer, which should be avoided."
    
    This change removes the percpu related code as no drivers is using it.
    
    [Daniel: Fixed the description]
    
    Fixes: dc11bae785295 ("clocksource/drivers: Add timer-of common init routine")
    Reported-by: Uros Bizjak <ubizjak@gmail.com>
    Tested-by: Uros Bizjak <ubizjak@gmail.com>
    Link: https://lore.kernel.org/r/20240819100335.2394751-1-daniel.lezcano@linaro.org
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpufreq: scmi: Avoid overflow of target_freq in fast switch [+ + +]
Author: Jagadeesh Kona <quic_jkona@quicinc.com>
Date:   Mon May 20 12:07:32 2024 +0530

    cpufreq: scmi: Avoid overflow of target_freq in fast switch
    
    [ Upstream commit 074cffb5020ddcaa5fafcc55655e5da6ebe8c831 ]
    
    Conversion of target_freq to HZ in scmi_cpufreq_fast_switch()
    can lead to overflow if the multiplied result is greater than
    UINT_MAX, since type of target_freq is unsigned int. Avoid this
    overflow by assigning target_freq to unsigned long variable for
    converting it to HZ.
    
    Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    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>

 
dm init: Handle minors larger than 255 [+ + +]
Author: Benjamin Marzinski <bmarzins@redhat.com>
Date:   Tue Jul 2 12:13:24 2024 +0200

    dm init: Handle minors larger than 255
    
    [ Upstream commit 140ce37fd78a629105377e17842465258a5459ef ]
    
    dm_parse_device_entry() simply copies the minor number into dmi.dev, but
    the dev_t format splits the minor number between the lowest 8 bytes and
    highest 12 bytes. If the minor number is larger than 255, part of it
    will end up getting treated as the major number
    
    Fix this by checking that the minor number is valid and then encoding it
    as a dev_t.
    
    Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dma-debug: avoid deadlock between dma debug vs printk and netconsole [+ + +]
Author: Rik van Riel <riel@surriel.com>
Date:   Tue Aug 6 11:56:45 2024 -0400

    dma-debug: avoid deadlock between dma debug vs printk and netconsole
    
    [ Upstream commit bd44ca3de49cc1badcff7a96010fa2c64f04868c ]
    
    Currently the dma debugging code can end up indirectly calling printk
    under the radix_lock. This happens when a radix tree node allocation
    fails.
    
    This is a problem because the printk code, when used together with
    netconsole, can end up inside the dma debugging code while trying to
    transmit a message over netcons.
    
    This creates the possibility of either a circular deadlock on the same
    CPU, with that CPU trying to grab the radix_lock twice, or an ABBA
    deadlock between different CPUs, where one CPU grabs the console lock
    first and then waits for the radix_lock, while the other CPU is holding
    the radix_lock and is waiting for the console lock.
    
    The trace captured by lockdep is of the ABBA variant.
    
    -> #2 (&dma_entry_hash[i].lock){-.-.}-{2:2}:
                      _raw_spin_lock_irqsave+0x5a/0x90
                      debug_dma_map_page+0x79/0x180
                      dma_map_page_attrs+0x1d2/0x2f0
                      bnxt_start_xmit+0x8c6/0x1540
                      netpoll_start_xmit+0x13f/0x180
                      netpoll_send_skb+0x20d/0x320
                      netpoll_send_udp+0x453/0x4a0
                      write_ext_msg+0x1b9/0x460
                      console_flush_all+0x2ff/0x5a0
                      console_unlock+0x55/0x180
                      vprintk_emit+0x2e3/0x3c0
                      devkmsg_emit+0x5a/0x80
                      devkmsg_write+0xfd/0x180
                      do_iter_readv_writev+0x164/0x1b0
                      vfs_writev+0xf9/0x2b0
                      do_writev+0x6d/0x110
                      do_syscall_64+0x80/0x150
                      entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    -> #0 (console_owner){-.-.}-{0:0}:
                      __lock_acquire+0x15d1/0x31a0
                      lock_acquire+0xe8/0x290
                      console_flush_all+0x2ea/0x5a0
                      console_unlock+0x55/0x180
                      vprintk_emit+0x2e3/0x3c0
                      _printk+0x59/0x80
                      warn_alloc+0x122/0x1b0
                      __alloc_pages_slowpath+0x1101/0x1120
                      __alloc_pages+0x1eb/0x2c0
                      alloc_slab_page+0x5f/0x150
                      new_slab+0x2dc/0x4e0
                      ___slab_alloc+0xdcb/0x1390
                      kmem_cache_alloc+0x23d/0x360
                      radix_tree_node_alloc+0x3c/0xf0
                      radix_tree_insert+0xf5/0x230
                      add_dma_entry+0xe9/0x360
                      dma_map_page_attrs+0x1d2/0x2f0
                      __bnxt_alloc_rx_frag+0x147/0x180
                      bnxt_alloc_rx_data+0x79/0x160
                      bnxt_rx_skb+0x29/0xc0
                      bnxt_rx_pkt+0xe22/0x1570
                      __bnxt_poll_work+0x101/0x390
                      bnxt_poll+0x7e/0x320
                      __napi_poll+0x29/0x160
                      net_rx_action+0x1e0/0x3e0
                      handle_softirqs+0x190/0x510
                      run_ksoftirqd+0x4e/0x90
                      smpboot_thread_fn+0x1a8/0x270
                      kthread+0x102/0x120
                      ret_from_fork+0x2f/0x40
                      ret_from_fork_asm+0x11/0x20
    
    This bug is more likely than it seems, because when one CPU has run out
    of memory, chances are the other has too.
    
    The good news is, this bug is hidden behind the CONFIG_DMA_API_DEBUG, so
    not many users are likely to trigger it.
    
    Signed-off-by: Rik van Riel <riel@surriel.com>
    Reported-by: Konstantin Ovsepian <ovs@meta.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dma-mapping: benchmark: Don't starve others when doing the test [+ + +]
Author: Yicong Yang <yangyicong@hisilicon.com>
Date:   Thu Jun 20 17:28:55 2024 +0800

    dma-mapping: benchmark: Don't starve others when doing the test
    
    [ Upstream commit 54624acf8843375a6de3717ac18df3b5104c39c5 ]
    
    The test thread will start N benchmark kthreads and then schedule out
    until the test time finished and notify the benchmark kthreads to stop.
    The benchmark kthreads will keep running until notified to stop.
    There's a problem with current implementation when the benchmark
    kthreads number is equal to the CPUs on a non-preemptible kernel:
    since the scheduler will balance the kthreads across the CPUs and
    when the test time's out the test thread won't get a chance to be
    scheduled on any CPU then cannot notify the benchmark kthreads to stop.
    
    This can be easily reproduced on a VM (simulated with 16 CPUs) with
    PREEMPT_VOLUNTARY:
    estuary:/mnt$ ./dma_map_benchmark -t 16 -s 1
     rcu: INFO: rcu_sched self-detected stall on CPU
     rcu:     10-...!: (5221 ticks this GP) idle=ed24/1/0x4000000000000000 softirq=142/142 fqs=0
     rcu:     (t=5254 jiffies g=-559 q=45 ncpus=16)
     rcu: rcu_sched kthread starved for 5255 jiffies! g-559 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=12
     rcu:     Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
     rcu: RCU grace-period kthread stack dump:
     task:rcu_sched       state:R  running task     stack:0     pid:16    tgid:16    ppid:2      flags:0x00000008
     Call trace
      __switch_to+0xec/0x138
      __schedule+0x2f8/0x1080
      schedule+0x30/0x130
      schedule_timeout+0xa0/0x188
      rcu_gp_fqs_loop+0x128/0x528
      rcu_gp_kthread+0x1c8/0x208
      kthread+0xec/0xf8
      ret_from_fork+0x10/0x20
     Sending NMI from CPU 10 to CPUs 0:
     NMI backtrace for cpu 0
     CPU: 0 PID: 332 Comm: dma-map-benchma Not tainted 6.10.0-rc1-vanilla-LSE #8
     Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
     pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : arm_smmu_cmdq_issue_cmdlist+0x218/0x730
     lr : arm_smmu_cmdq_issue_cmdlist+0x488/0x730
     sp : ffff80008748b630
     x29: ffff80008748b630 x28: 0000000000000000 x27: ffff80008748b780
     x26: 0000000000000000 x25: 000000000000bc70 x24: 000000000001bc70
     x23: ffff0000c12af080 x22: 0000000000010000 x21: 000000000000ffff
     x20: ffff80008748b700 x19: ffff0000c12af0c0 x18: 0000000000010000
     x17: 0000000000000001 x16: 0000000000000040 x15: ffffffffffffffff
     x14: 0001ffffffffffff x13: 000000000000ffff x12: 00000000000002f1
     x11: 000000000001ffff x10: 0000000000000031 x9 : ffff800080b6b0b8
     x8 : ffff0000c2a48000 x7 : 000000000001bc71 x6 : 0001800000000000
     x5 : 00000000000002f1 x4 : 01ffffffffffffff x3 : 000000000009aaf1
     x2 : 0000000000000018 x1 : 000000000000000f x0 : ffff0000c12af18c
     Call trace:
      arm_smmu_cmdq_issue_cmdlist+0x218/0x730
      __arm_smmu_tlb_inv_range+0xe0/0x1a8
      arm_smmu_iotlb_sync+0xc0/0x128
      __iommu_dma_unmap+0x248/0x320
      iommu_dma_unmap_page+0x5c/0xe8
      dma_unmap_page_attrs+0x38/0x1d0
      map_benchmark_thread+0x118/0x2c0
      kthread+0xec/0xf8
      ret_from_fork+0x10/0x20
    
    Solve this by adding scheduling point in the kthread loop,
    so if there're other threads in the system they may have
    a chance to run, especially the thread to notify the test
    end. However this may degrade the test concurrency so it's
    recommended to run this on an idle system.
    
    Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
    Acked-by: Barry Song <baohua@kernel.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    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/amd/amdgpu: Check tbo resource pointer [+ + +]
Author: Asad Kamal <asad.kamal@amd.com>
Date:   Fri Apr 26 02:26:55 2024 +0800

    drm/amd/amdgpu: Check tbo resource pointer
    
    [ Upstream commit 6cd2b872643bb29bba01a8ac739138db7bd79007 ]
    
    Validate tbo resource pointer, skip if NULL
    
    Signed-off-by: Asad Kamal <asad.kamal@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Add array index check for hdcp ddc access [+ + +]
Author: Hersen Wu <hersenxs.wu@amd.com>
Date:   Wed Apr 24 10:09:31 2024 -0400

    drm/amd/display: Add array index check for hdcp ddc access
    
    [ Upstream commit 4e70c0f5251c25885c31ee84a31f99a01f7cf50e ]
    
    [Why]
    Coverity reports OVERRUN warning. Do not check if array
    index valid.
    
    [How]
    Check msg_id valid and valid array index.
    
    Reviewed-by: Alex Hung <alex.hung@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Assign linear_pitch_alignment even for VM [+ + +]
Author: Alvin Lee <alvin.lee2@amd.com>
Date:   Tue Apr 16 14:42:18 2024 -0400

    drm/amd/display: Assign linear_pitch_alignment even for VM
    
    [ Upstream commit 984debc133efa05e62f5aa1a7a1dd8ca0ef041f4 ]
    
    [Description]
    Assign linear_pitch_alignment so we don't cause a divide by 0
    error in VM environments
    
    Reviewed-by: Sohaib Nadeem <sohaib.nadeem@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Alvin Lee <alvin.lee2@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Check gpio_id before used as array index [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Apr 16 16:40:00 2024 -0600

    drm/amd/display: Check gpio_id before used as array index
    
    [ Upstream commit 2a5626eeb3b5eec7a36886f9556113dd93ec8ed6 ]
    
    [WHY & HOW]
    GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore
    should be checked in advance.
    
    This fixes 5 OVERRUN issues reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Check HDCP returned status [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Jun 11 10:36:49 2024 -0600

    drm/amd/display: Check HDCP returned status
    
    [ Upstream commit 5d93060d430b359e16e7c555c8f151ead1ac614b ]
    
    [WHAT & HOW]
    Check mod_hdcp_execute_and_set() return values in authenticated_dp.
    
    This fixes 3 CHECKED_RETURN issues reported by Coverity.
    
    Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Check msg_id before processing transcation [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Apr 16 16:47:42 2024 -0600

    drm/amd/display: Check msg_id before processing transcation
    
    [ Upstream commit fa71face755e27dc44bc296416ebdf2c67163316 ]
    
    [WHY & HOW]
    HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid
    array index, and it needs checking before used.
    
    This fixes 4 OVERRUN issues reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[] [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Apr 16 16:22:35 2024 -0600

    drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]
    
    [ Upstream commit b38a4815f79b87efb196cd5121579fc51e29a7fb ]
    
    [WHY & HOW]
    num_valid_sets needs to be checked to avoid a negative index when
    accessing reader_wm_sets[num_valid_sets - 1].
    
    This fixes an OVERRUN issue reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix Coverity INTEGER_OVERFLOW within dal_gpio_service_create [+ + +]
Author: Hersen Wu <hersenxs.wu@amd.com>
Date:   Fri Apr 26 11:58:11 2024 -0400

    drm/amd/display: Fix Coverity INTEGER_OVERFLOW within dal_gpio_service_create
    
    [ Upstream commit c6077aa66fa230d12f37fef01161ef080d13b726 ]
    
    [Why]
    For subtraction, coverity reports integer overflow
    warning message when variable type is uint32_t.
    
    [How]
    Change variable type to int32_t.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Skip wbscl_set_scaler_filter if filter is null [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Mon Jun 3 10:47:37 2024 -0600

    drm/amd/display: Skip wbscl_set_scaler_filter if filter is null
    
    [ Upstream commit c4d31653c03b90e51515b1380115d1aedad925dd ]
    
    Callers can pass null in filter (i.e. from returned from the function
    wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is
    not the case.
    
    This fixes 4 NULL_RETURNS issues reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6 [+ + +]
Author: Hersen Wu <hersenxs.wu@amd.com>
Date:   Wed Apr 24 16:00:19 2024 -0400

    drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6
    
    [ Upstream commit 84723eb6068c50610c5c0893980d230d7afa2105 ]
    
    [Why]
    Coverity reports OVERRUN warning. Should abort amdgpu_dm
    initialize.
    
    [How]
    Return failure to amdgpu_dm_init.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/pm: check negtive return for table entries [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Mon May 13 16:01:23 2024 +0800

    drm/amd/pm: check negtive return for table entries
    
    [ Upstream commit f76059fe14395b37ba8d997eb0381b1b9e80a939 ]
    
    Function hwmgr->hwmgr_func->get_num_of_pp_table_entries(hwmgr) returns a negative number
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Suggested-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: check specific index for aldebaran [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Wed May 8 17:13:28 2024 +0800

    drm/amd/pm: check specific index for aldebaran
    
    [ Upstream commit 0ce8ef2639c112ae203c985b758389e378630aac ]
    
    Check for specific indexes that may be invalid values.
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr [+ + +]
Author: Bob Zhou <bob.zhou@amd.com>
Date:   Fri May 31 15:01:22 2024 +0800

    drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr
    
    commit 50151b7f1c79a09117837eb95b76c2de76841dab upstream.
    
    Check return value and conduct null pointer handling to avoid null pointer dereference.
    
    Signed-off-by: Bob Zhou <bob.zhou@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Mukul Sikka <mukul.sikka@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/pm: fix the Out-of-bounds read warning [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Tue Apr 30 10:29:08 2024 +0800

    drm/amd/pm: fix the Out-of-bounds read warning
    
    [ Upstream commit 12c6967428a099bbba9dfd247bb4322a984fcc0b ]
    
    using index i - 1U may beyond element index
    for mc_data[] when i = 0.
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: fix uninitialized variable warning for smu8_hwmgr [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Fri Apr 26 12:52:45 2024 +0800

    drm/amd/pm: fix uninitialized variable warning for smu8_hwmgr
    
    [ Upstream commit 86df36b934640866eb249a4488abb148b985a0d9 ]
    
    Clear warnings that using uninitialized value level when fails
    to get the value from SMU.
    
    Signed-off-by: Tim Huang <Tim.Huang@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/amd/pm: fix uninitialized variable warnings for vega10_hwmgr [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Sun Apr 28 12:41:42 2024 +0800

    drm/amd/pm: fix uninitialized variable warnings for vega10_hwmgr
    
    [ Upstream commit 5fa7d540d95d97ddc021a74583f6b3da4df9c93a ]
    
    Clear warnings that using uninitialized variable when fails
    to get the valid value from SMU.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/pm: fix warning using uninitialized value of max_vid_step [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Mon Apr 29 15:26:25 2024 +0800

    drm/amd/pm: fix warning using uninitialized value of max_vid_step
    
    [ Upstream commit 17e3bea65cdc453695b2fe4ff26d25d17f5339e9 ]
    
    Check the return of pp_atomfwctrl_get_Voltage_table_v4
    as it may fail to initialize max_vid_step
    V2: change the check condition (Tim Huang)
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/pm: Check input value for CUSTOM profile mode setting on legacy SOCs [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Fri May 10 10:05:21 2024 +0800

    drm/amdgpu/pm: Check input value for CUSTOM profile mode setting on legacy SOCs
    
    [ Upstream commit df0a9bd92fbbd3fcafcb2bce6463c9228a3e6868 ]
    
    Check the input value for CUSTOM profile mode setting on legacy
    SOCs. Otherwise we may use uninitalized value of input[]
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu/pm: Check the return value of smum_send_msg_to_smc [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Fri Apr 26 14:38:04 2024 +0800

    drm/amdgpu/pm: Check the return value of smum_send_msg_to_smc
    
    [ Upstream commit 579f0c21baec9e7506b6bb3f60f0a9b6d07693b4 ]
    
    Check the return value of smum_send_msg_to_smc, otherwise
    we might use an uninitialized variable "now"
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu/pm: Fix uninitialized variable agc_btc_response [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Sun Apr 28 14:41:38 2024 +0800

    drm/amdgpu/pm: Fix uninitialized variable agc_btc_response
    
    [ Upstream commit df4409d8a04dd39d7f2aa0c5f528a56b99eaaa13 ]
    
    Assign an default value to agc_btc_response in failed case
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu/pm: Fix uninitialized variable warning for smu10 [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Fri Apr 26 17:46:08 2024 +0800

    drm/amdgpu/pm: Fix uninitialized variable warning for smu10
    
    [ Upstream commit 336c8f558d596699d3d9814a45600139b2f23f27 ]
    
    Check return value of smum_send_msg_to_smc to fix
    uninitialized variable varning
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: avoid reading vf2pf info size from FB [+ + +]
Author: Zhigang Luo <Zhigang.Luo@amd.com>
Date:   Tue Apr 16 16:35:14 2024 -0400

    drm/amdgpu: avoid reading vf2pf info size from FB
    
    [ Upstream commit 3bcc0ee14768d886cedff65da72d83d375a31a56 ]
    
    VF can't access FB when host is doing mode1 reset. Using sizeof to get
    vf2pf info size, instead of reading it from vf2pf header stored in FB.
    
    Signed-off-by: Zhigang Luo <Zhigang.Luo@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: check for LINEAR_ALIGNED correctly in check_tiling_flags_gfx6 [+ + +]
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Sat Jun 1 16:36:27 2024 -0400

    drm/amdgpu: check for LINEAR_ALIGNED correctly in check_tiling_flags_gfx6
    
    [ Upstream commit 11317d2963fa79767cd7c6231a00a9d77f2e0f54 ]
    
    Fix incorrect check.
    
    Signed-off-by: Marek Olšák <marek.olsak@amd.com>
    Acked-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 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 out-of-bounds read of df_v1_7_channel_number [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Tue May 7 09:29:33 2024 +0800

    drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
    
    [ Upstream commit d768394fa99467bcf2703bde74ddc96eeb0b71fa ]
    
    Check the fb_channel_number range to avoid the array out-of-bounds
    read error
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix out-of-bounds write warning [+ + +]
Author: Ma Jun <Jun.Ma2@amd.com>
Date:   Thu Apr 25 14:00:17 2024 +0800

    drm/amdgpu: Fix out-of-bounds write warning
    
    [ Upstream commit be1684930f5262a622d40ce7a6f1423530d87f89 ]
    
    Check the ring type value to fix the out-of-bounds
    write warning
    
    Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
    Suggested-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@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 the waring dereferencing hive [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Wed May 8 16:20:49 2024 +0800

    drm/amdgpu: fix the waring dereferencing hive
    
    [ Upstream commit 1940708ccf5aff76de4e0b399f99267c93a89193 ]
    
    Check the amdgpu_hive_info *hive that maybe is NULL.
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@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 scalar variable warning [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Fri Apr 26 08:43:30 2024 +0800

    drm/amdgpu: fix uninitialized scalar variable warning
    
    [ Upstream commit 9a5f15d2a29d06ce5bd50919da7221cda92afb69 ]
    
    Clear warning that uses uninitialized value fw_size.
    
    Signed-off-by: Tim Huang <Tim.Huang@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 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/amdgpu: Set no_hw_access when VF request full GPU fails [+ + +]
Author: Yifan Zha <Yifan.Zha@amd.com>
Date:   Thu Jun 27 15:06:23 2024 +0800

    drm/amdgpu: Set no_hw_access when VF request full GPU fails
    
    [ Upstream commit 33f23fc3155b13c4a96d94a0a22dc26db767440b ]
    
    [Why]
    If VF request full GPU access and the request failed,
    the VF driver can get stuck accessing registers for an extended period during
    the unload of KMS.
    
    [How]
    Set no_hw_access flag when VF request for full GPU access fails
    This prevents further hardware access attempts, avoiding the prolonged
    stuck state.
    
    Signed-off-by: Yifan Zha <Yifan.Zha@amd.com>
    Acked-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: the warning dereferencing obj for nbio_v7_4 [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Mon May 13 15:22:42 2024 +0800

    drm/amdgpu: the warning dereferencing obj for nbio_v7_4
    
    [ Upstream commit d190b459b2a4304307c3468ed97477b808381011 ]
    
    if ras_manager obj null, don't print NBIO err data
    
    Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
    Suggested-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Tim Huang <Tim.Huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: update type of buf size to u32 for eeprom functions [+ + +]
Author: Tao Zhou <tao.zhou1@amd.com>
Date:   Fri May 17 18:04:26 2024 +0800

    drm/amdgpu: update type of buf size to u32 for eeprom functions
    
    [ Upstream commit 2aadb520bfacec12527effce3566f8df55e5d08e ]
    
    Avoid overflow issue.
    
    Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@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/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Fri May 31 22:33:12 2024 +0200

    drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ
    
    [ Upstream commit 162e48cb1d84c2c966b649b8ac5c9d4f75f6d44f ]
    
    Make sure the connector is fully initialized before signalling any
    HPD events via drm_kms_helper_hotplug_event(), otherwise this may
    lead to NULL pointer dereference.
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240531203333.277476-1-marex@denx.de
    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>

 
drm/meson: plane: Add error handling [+ + +]
Author: Haoran Liu <liuhaoran14@163.com>
Date:   Wed Nov 29 03:34:05 2023 -0800

    drm/meson: plane: Add error handling
    
    [ Upstream commit 3c28b239620e249b68beeca17f429e317fa6b8d4 ]
    
    This patch adds robust error handling to the meson_plane_create
    function in drivers/gpu/drm/meson/meson_plane.c. The function
    previously lacked proper handling for potential failure scenarios
    of the drm_universal_plane_init call.
    
    Signed-off-by: Haoran Liu <liuhaoran14@163.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20231129113405.33057-1-liuhaoran14@163.com
    [narmstrong: fixe the commit subject]
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231129113405.33057-1-liuhaoran14@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: panel-orientation-quirks: Add quirk for OrangePi Neo [+ + +]
Author: Philip Mueller <philm@manjaro.org>
Date:   Mon Jul 15 11:57:49 2024 +0700

    drm: panel-orientation-quirks: Add quirk for OrangePi Neo
    
    [ Upstream commit d60c429610a14560085d98fa6f4cdb43040ca8f0 ]
    
    This adds a DMI orientation quirk for the OrangePi Neo Linux Gaming
    Handheld.
    
    Signed-off-by: Philip Mueller <philm@manjaro.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240715045818.1019979-1-philm@manjaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
ext4: fix possible tid_t sequence overflows [+ + +]
Author: Luis Henriques (SUSE) <luis.henriques@linux.dev>
Date:   Wed May 29 10:20:30 2024 +0100

    ext4: fix possible tid_t sequence overflows
    
    [ Upstream commit 63469662cc45d41705f14b4648481d5d29cf5999 ]
    
    In the fast commit code there are a few places where tid_t variables are
    being compared without taking into account the fact that these sequence
    numbers may wrap.  Fix this issue by using the helper functions tid_gt()
    and tid_geq().
    
    Signed-off-by: Luis Henriques (SUSE) <luis.henriques@linux.dev>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
    Link: https://patch.msgid.link/20240529092030.9557-3-luis.henriques@linux.dev
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: handle redirtying in ext4_bio_write_page() [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 7 12:27:04 2022 +0100

    ext4: handle redirtying in ext4_bio_write_page()
    
    commit 04e568a3b31cfbd545c04c8bfc35c20e5ccfce0f upstream.
    
    Since we want to transition transaction commits to use ext4_writepages()
    for writing back ordered, add handling of page redirtying into
    ext4_bio_write_page(). Also move buffer dirty bit clearing into the same
    place other buffer state handling.
    
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221207112722.22220-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: reject casefold inode flag without casefold feature [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Aug 14 11:29:01 2023 -0700

    ext4: reject casefold inode flag without casefold feature
    
    commit 8216776ccff6fcd40e3fdaa109aa4150ebe760b3 upstream.
    
    It is invalid for the casefold inode flag to be set without the casefold
    superblock feature flag also being set.  e2fsck already considers this
    case to be invalid and handles it by offering to clear the casefold flag
    on the inode.  __ext4_iget() also already considered this to be invalid,
    sort of, but it only got so far as logging an error message; it didn't
    actually reject the inode.  Make it reject the inode so that other code
    doesn't have to handle this case.  This matches what f2fs does.
    
    Note: we could check 's_encoding != NULL' instead of
    ext4_has_feature_casefold().  This would make the check robust against
    the casefold feature being enabled by userspace writing to the page
    cache of the mounted block device.  However, it's unsolvable in general
    for filesystems to be robust against concurrent writes to the page cache
    of the mounted block device.  Though this very particular scenario
    involving the casefold feature is solvable, we should not pretend that
    we can support this model, so let's just check the casefold feature.
    tune2fs already forbids enabling casefold on a mounted filesystem.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20230814182903.37267-2-ebiggers@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fou: Fix null-ptr-deref in GRO. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Mon Sep 2 10:39:27 2024 -0700

    fou: Fix null-ptr-deref in GRO.
    
    [ Upstream commit 7e4196935069947d8b70b09c1660b67b067e75cb ]
    
    We observed a null-ptr-deref in fou_gro_receive() while shutting down
    a host.  [0]
    
    The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol
    in struct fou.
    
    When fou_release() is called due to netns dismantle or explicit tunnel
    teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.
    Then, the tunnel socket is destroyed after a single RCU grace period.
    
    So, in-flight udp4_gro_receive() could find the socket and execute the
    FOU GRO handler, where sk->sk_user_data could be NULL.
    
    Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL
    checks in FOU GRO handlers.
    
    [0]:
    BUG: kernel NULL pointer dereference, address: 0000000000000008
     PF: supervisor read access in kernel mode
     PF: error_code(0x0000) - not-present page
    PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0
    SMP PTI
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1
    Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017
    RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]
    Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42
    RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297
    RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010
    RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08
    RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002
    R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400
    R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0
    FS:  0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <IRQ>
     ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)
     ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)
     ? no_context (arch/x86/mm/fault.c:752)
     ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)
     ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)
     ? fou_gro_receive (net/ipv4/fou.c:233) [fou]
     udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)
     udp4_gro_receive (net/ipv4/udp_offload.c:604)
     inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))
     dev_gro_receive (net/core/dev.c:6035 (discriminator 4))
     napi_gro_receive (net/core/dev.c:6170)
     ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]
     ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]
     napi_poll (net/core/dev.c:6847)
     net_rx_action (net/core/dev.c:6917)
     __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)
     asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)
    </IRQ>
     do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)
     irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)
     common_interrupt (arch/x86/kernel/irq.c:239)
     asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)
    RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)
    Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00
    RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246
    RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900
    RDX: ffff93daee800000 RSI: ffff93daee87dc00 RDI: ffff93daee87dc64
    RBP: 0000000000000001 R08: ffffffffb5e7b6c0 R09: 0000000000000044
    R10: ffff93daee831b04 R11: 00000000000001cd R12: 0000000000000001
    R13: ffffffffb5e7b740 R14: 0000000000000001 R15: 0000000000000000
     ? sched_clock_cpu (kernel/sched/clock.c:371)
     acpi_idle_enter (drivers/acpi/processor_idle.c:712 (discriminator 3))
     cpuidle_enter_state (drivers/cpuidle/cpuidle.c:237)
     cpuidle_enter (drivers/cpuidle/cpuidle.c:353)
     cpuidle_idle_call (kernel/sched/idle.c:158 kernel/sched/idle.c:239)
     do_idle (kernel/sched/idle.c:302)
     cpu_startup_entry (kernel/sched/idle.c:395 (discriminator 1))
     start_kernel (init/main.c:1048)
     secondary_startup_64_no_verify (arch/x86/kernel/head_64.S:310)
    Modules linked in: udp_diag tcp_diag inet_diag nft_nat ipip tunnel4 dummy fou ip_tunnel nft_masq nft_chain_nat nf_nat wireguard nft_ct curve25519_x86_64 libcurve25519_generic nf_conntrack libchacha20poly1305 nf_defrag_ipv6 nf_defrag_ipv4 nft_objref chacha_x86_64 nft_counter nf_tables nfnetlink poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper mousedev psmouse button ena ptp pps_core crc32c_intel
    CR2: 0000000000000008
    
    Fixes: d92283e338f6 ("fou: change to use UDP socket GRO")
    Reported-by: Alphonse Kurian <alkurian@amazon.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://patch.msgid.link/20240902173927.62706-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/ntfs3: Check more cases when directory is corrupted [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Mon Jun 17 14:53:57 2024 +0300

    fs/ntfs3: Check more cases when directory is corrupted
    
    [ Upstream commit 744375343662058cbfda96d871786e5a5cbe1947 ]
    
    Mark ntfs dirty in this case.
    Rename ntfs_filldir to ntfs_dir_emit.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fsnotify: clear PARENT_WATCHED flags lazily [+ + +]
Author: Amir Goldstein <amir73il@gmail.com>
Date:   Sun May 12 13:30:07 2024 +0200

    fsnotify: clear PARENT_WATCHED flags lazily
    
    [ Upstream commit 172e422ffea20a89bfdc672741c1aad6fbb5044e ]
    
    In some setups directories can have many (usually negative) dentries.
    Hence __fsnotify_update_child_dentry_flags() function can take a
    significant amount of time. Since the bulk of this function happens
    under inode->i_lock this causes a significant contention on the lock
    when we remove the watch from the directory as the
    __fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
    races with __fsnotify_update_child_dentry_flags() calls from
    __fsnotify_parent() happening on children. This can lead upto softlockup
    reports reported by users.
    
    Fix the problem by calling fsnotify_update_children_dentry_flags() to
    set PARENT_WATCHED flags only when parent starts watching children.
    
    When parent stops watching children, clear false positive PARENT_WATCHED
    flags lazily in __fsnotify_parent() for each accessed child.
    
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fuse: update stats for pages in dropped aux writeback list [+ + +]
Author: Joanne Koong <joannelkoong@gmail.com>
Date:   Mon Aug 26 14:19:04 2024 -0700

    fuse: update stats for pages in dropped aux writeback list
    
    commit f7790d67785302b3116bbbfda62a5a44524601a3 upstream.
    
    In the case where the aux writeback list is dropped (e.g. the pages
    have been truncated or the connection is broken), the stats for
    its pages and backing device info need to be updated as well.
    
    Fixes: e2653bd53a98 ("fuse: fix leaked aux requests")
    Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Cc: <stable@vger.kernel.org> # v5.1
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
gpio: rockchip: fix OF node leak in probe() [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Aug 26 17:08:32 2024 +0200

    gpio: rockchip: fix OF node leak in probe()
    
    [ Upstream commit adad2e460e505a556f5ea6f0dc16fe95e62d5d76 ]
    
    Driver code is leaking OF node reference from of_get_parent() in
    probe().
    
    Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
    Link: https://lore.kernel.org/r/20240826150832.65657-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gro: remove rcu_read_lock/rcu_read_unlock from gro_complete handlers [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Nov 23 14:56:08 2021 -0800

    gro: remove rcu_read_lock/rcu_read_unlock from gro_complete handlers
    
    [ Upstream commit 627b94f75b82d13d1530b59155a545fd99d807db ]
    
    All gro_complete() handlers are called from napi_gro_complete()
    while rcu_read_lock() has been called.
    
    There is no point stacking more rcu_read_lock()
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 7e4196935069 ("fou: Fix null-ptr-deref in GRO.")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gro: remove rcu_read_lock/rcu_read_unlock from gro_receive handlers [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Nov 23 14:56:07 2021 -0800

    gro: remove rcu_read_lock/rcu_read_unlock from gro_receive handlers
    
    [ Upstream commit fc1ca3348a74a1afaa7ffebc2b2f2cc149e11278 ]
    
    All gro_receive() handlers are called from dev_gro_receive()
    while rcu_read_lock() has been called.
    
    There is no point stacking more rcu_read_lock()
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 7e4196935069 ("fou: Fix null-ptr-deref in GRO.")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gso: fix dodgy bit handling for GSO_UDP_L4 [+ + +]
Author: Yan Zhai <yan@cloudflare.com>
Date:   Mon Sep 9 14:22:47 2024 -0400

    gso: fix dodgy bit handling for GSO_UDP_L4
    
    [ Upstream commit 9840036786d90cea11a90d1f30b6dc003b34ee67 ]
    
    Commit 1fd54773c267 ("udp: allow header check for dodgy GSO_UDP_L4
    packets.") checks DODGY bit for UDP, but for packets that can be fed
    directly to the device after gso_segs reset, it actually falls through
    to fragmentation:
    
    https://lore.kernel.org/all/CAJPywTKDdjtwkLVUW6LRA2FU912qcDmQOQGt2WaDo28KzYDg+A@mail.gmail.com/
    
    This change restores the expected behavior of GSO_UDP_L4 packets.
    
    Fixes: 1fd54773c267 ("udp: allow header check for dodgy GSO_UDP_L4 packets.")
    Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
    Signed-off-by: Yan Zhai <yan@cloudflare.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    
    [5.15 stable: clean backport]
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: amd_sfh: free driver_data after destroying hid device [+ + +]
Author: Olivier Sobrie <olivier@sobrie.be>
Date:   Tue Jul 23 10:44:35 2024 +0200

    HID: amd_sfh: free driver_data after destroying hid device
    
    [ Upstream commit 97155021ae17b86985121b33cf8098bcde00d497 ]
    
    HID driver callbacks aren't called anymore once hid_destroy_device() has
    been called. Hence, hid driver_data should be freed only after the
    hid_destroy_device() function returned as driver_data is used in several
    callbacks.
    
    I observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling
    KASAN to debug memory allocation, I got this output:
    
      [   13.050438] ==================================================================
      [   13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh]
      [   13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3
      [   13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479
    
      [   13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0
      [   13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024
      [   13.067860] Call Trace:
      [   13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8
      [   13.071486]  <TASK>
      [   13.071492]  dump_stack_lvl+0x5d/0x80
      [   13.074870] snd_hda_intel 0000:33:00.6: enabling device (0000 -> 0002)
      [   13.078296]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
      [   13.082199]  print_report+0x174/0x505
      [   13.085776]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
      [   13.089367]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.093255]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
      [   13.097464]  kasan_report+0xc8/0x150
      [   13.101461]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
      [   13.105802]  amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
      [   13.110303]  amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
      [   13.114879]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.119450]  sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082]
      [   13.124097]  hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
      [   13.127404]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.131925]  ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
      [   13.136455]  ? _raw_spin_lock_irqsave+0x96/0xf0
      [   13.140197]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
      [   13.143602]  ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b]
      [   13.147234]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.150446]  ? __devm_add_action+0x167/0x1d0
      [   13.155061]  hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
      [   13.158581]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.161814]  platform_probe+0xa2/0x150
      [   13.165029]  really_probe+0x1e3/0x8a0
      [   13.168243]  __driver_probe_device+0x18c/0x370
      [   13.171500]  driver_probe_device+0x4a/0x120
      [   13.175000]  __driver_attach+0x190/0x4a0
      [   13.178521]  ? __pfx___driver_attach+0x10/0x10
      [   13.181771]  bus_for_each_dev+0x106/0x180
      [   13.185033]  ? __pfx__raw_spin_lock+0x10/0x10
      [   13.188229]  ? __pfx_bus_for_each_dev+0x10/0x10
      [   13.191446]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.194382]  bus_add_driver+0x29e/0x4d0
      [   13.197328]  driver_register+0x1a5/0x360
      [   13.200283]  ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
      [   13.203362]  do_one_initcall+0xa7/0x380
      [   13.206432]  ? __pfx_do_one_initcall+0x10/0x10
      [   13.210175]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.213211]  ? kasan_unpoison+0x44/0x70
      [   13.216688]  do_init_module+0x238/0x750
      [   13.219696]  load_module+0x5011/0x6af0
      [   13.223096]  ? kasan_save_stack+0x30/0x50
      [   13.226743]  ? kasan_save_track+0x14/0x30
      [   13.230080]  ? kasan_save_free_info+0x3b/0x60
      [   13.233323]  ? poison_slab_object+0x109/0x180
      [   13.236778]  ? __pfx_load_module+0x10/0x10
      [   13.239703]  ? poison_slab_object+0x109/0x180
      [   13.243070]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.245924]  ? init_module_from_file+0x13d/0x150
      [   13.248745]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.251503]  ? init_module_from_file+0xdf/0x150
      [   13.254198]  init_module_from_file+0xdf/0x150
      [   13.256826]  ? __pfx_init_module_from_file+0x10/0x10
      [   13.259428]  ? kasan_save_track+0x14/0x30
      [   13.261959]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.264471]  ? kasan_save_free_info+0x3b/0x60
      [   13.267026]  ? poison_slab_object+0x109/0x180
      [   13.269494]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.271949]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.274324]  ? _raw_spin_lock+0x85/0xe0
      [   13.276671]  ? __pfx__raw_spin_lock+0x10/0x10
      [   13.278963]  ? __rseq_handle_notify_resume+0x1a6/0xad0
      [   13.281193]  idempotent_init_module+0x23b/0x650
      [   13.283420]  ? __pfx_idempotent_init_module+0x10/0x10
      [   13.285619]  ? __pfx___seccomp_filter+0x10/0x10
      [   13.287714]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.289828]  ? __fget_light+0x57/0x420
      [   13.291870]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.293880]  ? security_capable+0x74/0xb0
      [   13.295820]  __x64_sys_finit_module+0xbe/0x130
      [   13.297874]  do_syscall_64+0x82/0x190
      [   13.299898]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.301905]  ? irqtime_account_irq+0x3d/0x1f0
      [   13.303877]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.305753]  ? __irq_exit_rcu+0x4e/0x130
      [   13.307577]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.309489]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
      [   13.311371] RIP: 0033:0x7a21f96ade9d
      [   13.313234] 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 63 de 0c 00 f7 d8 64 89 01 48
      [   13.317051] RSP: 002b:00007ffeae934e78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      [   13.319024] RAX: ffffffffffffffda RBX: 00005987276bfcf0 RCX: 00007a21f96ade9d
      [   13.321100] RDX: 0000000000000004 RSI: 00007a21f8eda376 RDI: 000000000000001c
      [   13.323314] RBP: 00007a21f8eda376 R08: 0000000000000001 R09: 00007ffeae934ec0
      [   13.325505] R10: 0000000000000050 R11: 0000000000000246 R12: 0000000000020000
      [   13.327637] R13: 00005987276c1250 R14: 0000000000000000 R15: 00005987276c4530
      [   13.329737]  </TASK>
    
      [   13.333945] Allocated by task 139:
      [   13.336111]  kasan_save_stack+0x30/0x50
      [   13.336121]  kasan_save_track+0x14/0x30
      [   13.336125]  __kasan_kmalloc+0xaa/0xb0
      [   13.336129]  amdtp_hid_probe+0xb1/0x440 [amd_sfh]
      [   13.336138]  amd_sfh_hid_client_init+0xb8a/0x10f0 [amd_sfh]
      [   13.336144]  sfh_init_work+0x47/0x120 [amd_sfh]
      [   13.336150]  process_one_work+0x673/0xeb0
      [   13.336155]  worker_thread+0x795/0x1250
      [   13.336160]  kthread+0x290/0x350
      [   13.336164]  ret_from_fork+0x34/0x70
      [   13.336169]  ret_from_fork_asm+0x1a/0x30
    
      [   13.338175] Freed by task 139:
      [   13.340064]  kasan_save_stack+0x30/0x50
      [   13.340072]  kasan_save_track+0x14/0x30
      [   13.340076]  kasan_save_free_info+0x3b/0x60
      [   13.340081]  poison_slab_object+0x109/0x180
      [   13.340085]  __kasan_slab_free+0x32/0x50
      [   13.340089]  kfree+0xe5/0x310
      [   13.340094]  amdtp_hid_remove+0xb2/0x160 [amd_sfh]
      [   13.340102]  amd_sfh_hid_client_deinit+0x324/0x640 [amd_sfh]
      [   13.340107]  amd_sfh_hid_client_init+0x94a/0x10f0 [amd_sfh]
      [   13.340113]  sfh_init_work+0x47/0x120 [amd_sfh]
      [   13.340118]  process_one_work+0x673/0xeb0
      [   13.340123]  worker_thread+0x795/0x1250
      [   13.340127]  kthread+0x290/0x350
      [   13.340132]  ret_from_fork+0x34/0x70
      [   13.340136]  ret_from_fork_asm+0x1a/0x30
    
      [   13.342482] The buggy address belongs to the object at ffff88813152f400
                      which belongs to the cache kmalloc-64 of size 64
      [   13.347357] The buggy address is located 8 bytes inside of
                      freed 64-byte region [ffff88813152f400, ffff88813152f440)
    
      [   13.347367] The buggy address belongs to the physical page:
      [   13.355409] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x13152f
      [   13.355416] anon flags: 0x2ffff8000000000(node=0|zone=2|lastcpupid=0x1ffff)
      [   13.355423] page_type: 0xffffefff(slab)
      [   13.355429] raw: 02ffff8000000000 ffff8881000428c0 ffffea0004c43a00 0000000000000005
      [   13.355435] raw: 0000000000000000 0000000000200020 00000001ffffefff 0000000000000000
      [   13.355439] page dumped because: kasan: bad access detected
    
      [   13.357295] Memory state around the buggy address:
      [   13.357299]  ffff88813152f300: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [   13.357303]  ffff88813152f380: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [   13.357306] >ffff88813152f400: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [   13.357309]                       ^
      [   13.357311]  ffff88813152f480: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
      [   13.357315]  ffff88813152f500: 00 00 00 00 00 00 00 06 fc fc fc fc fc fc fc fc
      [   13.357318] ==================================================================
      [   13.357405] Disabling lock debugging due to kernel taint
      [   13.383534] Oops: general protection fault, probably for non-canonical address 0xe0a1bc4140000013: 0000 [#1] PREEMPT SMP KASAN NOPTI
      [   13.383544] KASAN: maybe wild-memory-access in range [0x050e020a00000098-0x050e020a0000009f]
      [   13.383551] CPU: 3 PID: 479 Comm: (udev-worker) Tainted: G    B              6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0
      [   13.383561] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024
      [   13.383565] RIP: 0010:amd_sfh_get_report+0x81/0x530 [amd_sfh]
      [   13.383580] Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 78 03 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 49 8d 7c 24 10 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 1a 03 00 00 45 8b 74 24 10 45
      [   13.383585] RSP: 0018:ffff8881261f7388 EFLAGS: 00010212
      [   13.383592] RAX: dffffc0000000000 RBX: ffff88813152f400 RCX: 0000000000000002
      [   13.383597] RDX: 00a1c04140000013 RSI: 0000000000000008 RDI: 050e020a0000009b
      [   13.383600] RBP: ffff88814d010000 R08: 0000000000000002 R09: fffffbfff3ddb8c0
      [   13.383604] R10: ffffffff9eedc607 R11: ffff88810ce98000 R12: 050e020a0000008b
      [   13.383607] R13: ffff88814d010000 R14: dffffc0000000000 R15: 0000000000000004
      [   13.383611] FS:  00007a21f94d0880(0000) GS:ffff8887e7d80000(0000) knlGS:0000000000000000
      [   13.383615] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   13.383618] CR2: 00007e0014c438f0 CR3: 000000012614c000 CR4: 0000000000f50ef0
      [   13.383622] PKRU: 55555554
      [   13.383625] Call Trace:
      [   13.383629]  <TASK>
      [   13.383632]  ? __die_body.cold+0x19/0x27
      [   13.383644]  ? die_addr+0x46/0x70
      [   13.383652]  ? exc_general_protection+0x150/0x240
      [   13.383664]  ? asm_exc_general_protection+0x26/0x30
      [   13.383674]  ? amd_sfh_get_report+0x81/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
      [   13.383686]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
      [   13.383697]  amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
      [   13.383706]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.383713]  sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082]
      [   13.383727]  hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
      [   13.383739]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.383745]  ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
      [   13.383753]  ? _raw_spin_lock_irqsave+0x96/0xf0
      [   13.383762]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
      [   13.383768]  ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b]
      [   13.383790]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.383795]  ? __devm_add_action+0x167/0x1d0
      [   13.383806]  hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
      [   13.383818]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.383826]  platform_probe+0xa2/0x150
      [   13.383832]  really_probe+0x1e3/0x8a0
      [   13.383838]  __driver_probe_device+0x18c/0x370
      [   13.383844]  driver_probe_device+0x4a/0x120
      [   13.383851]  __driver_attach+0x190/0x4a0
      [   13.383857]  ? __pfx___driver_attach+0x10/0x10
      [   13.383863]  bus_for_each_dev+0x106/0x180
      [   13.383868]  ? __pfx__raw_spin_lock+0x10/0x10
      [   13.383874]  ? __pfx_bus_for_each_dev+0x10/0x10
      [   13.383880]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.383887]  bus_add_driver+0x29e/0x4d0
      [   13.383895]  driver_register+0x1a5/0x360
      [   13.383902]  ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
      [   13.383910]  do_one_initcall+0xa7/0x380
      [   13.383919]  ? __pfx_do_one_initcall+0x10/0x10
      [   13.383927]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.383933]  ? kasan_unpoison+0x44/0x70
      [   13.383943]  do_init_module+0x238/0x750
      [   13.383955]  load_module+0x5011/0x6af0
      [   13.383962]  ? kasan_save_stack+0x30/0x50
      [   13.383968]  ? kasan_save_track+0x14/0x30
      [   13.383973]  ? kasan_save_free_info+0x3b/0x60
      [   13.383980]  ? poison_slab_object+0x109/0x180
      [   13.383993]  ? __pfx_load_module+0x10/0x10
      [   13.384007]  ? poison_slab_object+0x109/0x180
      [   13.384012]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384018]  ? init_module_from_file+0x13d/0x150
      [   13.384025]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384032]  ? init_module_from_file+0xdf/0x150
      [   13.384037]  init_module_from_file+0xdf/0x150
      [   13.384044]  ? __pfx_init_module_from_file+0x10/0x10
      [   13.384050]  ? kasan_save_track+0x14/0x30
      [   13.384055]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384060]  ? kasan_save_free_info+0x3b/0x60
      [   13.384066]  ? poison_slab_object+0x109/0x180
      [   13.384071]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384080]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384085]  ? _raw_spin_lock+0x85/0xe0
      [   13.384091]  ? __pfx__raw_spin_lock+0x10/0x10
      [   13.384096]  ? __rseq_handle_notify_resume+0x1a6/0xad0
      [   13.384106]  idempotent_init_module+0x23b/0x650
      [   13.384114]  ? __pfx_idempotent_init_module+0x10/0x10
      [   13.384120]  ? __pfx___seccomp_filter+0x10/0x10
      [   13.384129]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384135]  ? __fget_light+0x57/0x420
      [   13.384142]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384147]  ? security_capable+0x74/0xb0
      [   13.384157]  __x64_sys_finit_module+0xbe/0x130
      [   13.384164]  do_syscall_64+0x82/0x190
      [   13.384174]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384179]  ? irqtime_account_irq+0x3d/0x1f0
      [   13.384188]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384193]  ? __irq_exit_rcu+0x4e/0x130
      [   13.384201]  ? srso_alias_return_thunk+0x5/0xfbef5
      [   13.384206]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
      [   13.384212] RIP: 0033:0x7a21f96ade9d
      [   13.384263] 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 63 de 0c 00 f7 d8 64 89 01 48
      [   13.384267] RSP: 002b:00007ffeae934e78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      [   13.384273] RAX: ffffffffffffffda RBX: 00005987276bfcf0 RCX: 00007a21f96ade9d
      [   13.384277] RDX: 0000000000000004 RSI: 00007a21f8eda376 RDI: 000000000000001c
      [   13.384280] RBP: 00007a21f8eda376 R08: 0000000000000001 R09: 00007ffeae934ec0
      [   13.384284] R10: 0000000000000050 R11: 0000000000000246 R12: 0000000000020000
      [   13.384288] R13: 00005987276c1250 R14: 0000000000000000 R15: 00005987276c4530
      [   13.384297]  </TASK>
      [   13.384299] Modules linked in: soundwire_amd(+) hid_sensor_gyro_3d(+) hid_sensor_magn_3d hid_sensor_accel_3d soundwire_generic_allocation amdxcp hid_sensor_trigger drm_exec industrialio_triggered_buffer soundwire_bus gpu_sched kvm_amd kfifo_buf qmi_helpers joydev drm_buddy hid_sensor_iio_common mousedev snd_soc_core industrialio i2c_algo_bit mac80211 snd_compress drm_suballoc_helper kvm snd_hda_intel drm_ttm_helper ac97_bus snd_pcm_dmaengine snd_intel_dspcfg ttm thinkpad_acpi(+) snd_intel_sdw_acpi hid_sensor_hub snd_rpl_pci_acp6x drm_display_helper snd_hda_codec hid_multitouch libarc4 snd_acp_pci platform_profile think_lmi(+) hid_generic firmware_attributes_class wmi_bmof cec snd_acp_legacy_common sparse_keymap rapl snd_hda_core psmouse cfg80211 pcspkr snd_pci_acp6x snd_hwdep video snd_pcm snd_pci_acp5x snd_timer snd_rn_pci_acp3x ucsi_acpi snd_acp_config snd sp5100_tco rfkill snd_soc_acpi typec_ucsi thunderbolt amd_sfh k10temp mhi soundcore i2c_piix4 snd_pci_acp3x typec i2c_hid_acpi roles i2c_hid wmi acpi_tad amd_pmc
      [   13.384454]  mac_hid i2c_dev crypto_user loop nfnetlink zram ip_tables x_tables dm_crypt cbc encrypted_keys trusted asn1_encoder tee dm_mod crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic gf128mul ghash_clmulni_intel serio_raw sha512_ssse3 atkbd sha256_ssse3 libps2 sha1_ssse3 vivaldi_fmap nvme aesni_intel crypto_simd nvme_core cryptd ccp xhci_pci i8042 nvme_auth xhci_pci_renesas serio vfat fat btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq
      [   13.384552] ---[ end trace 0000000000000000 ]---
    
    KASAN reports a use-after-free of hid->driver_data in function
    amd_sfh_get_report(). The backtrace indicates that the function is called
    by amdtp_hid_request() which is one of the callbacks of hid device.
    The current make sure that driver_data is freed only once
    hid_destroy_device() returned.
    
    Note that I observed the crash both on v6.9.9 and v6.10.0. The
    code seems to be as it was from the early days of the driver.
    
    Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
    Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
hwspinlock: Introduce hwspin_lock_bust() [+ + +]
Author: Richard Maina <quic_rmaina@quicinc.com>
Date:   Wed May 29 11:09:55 2024 -0700

    hwspinlock: Introduce hwspin_lock_bust()
    
    [ Upstream commit 7c327d56597d8de1680cf24e956b704270d3d84a ]
    
    When a remoteproc crashes or goes down unexpectedly this can result in
    a state where locks held by the remoteproc will remain locked possibly
    resulting in deadlock. This new API hwspin_lock_bust() allows
    hwspinlock implementers to define a bust operation for freeing previously
    acquired hwspinlocks after verifying ownership of the acquired lock.
    
    Signed-off-by: Richard Maina <quic_rmaina@quicinc.com>
    Reviewed-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Chris Lew <quic_clew@quicinc.com>
    Link: https://lore.kernel.org/r/20240529-hwspinlock-bust-v3-1-c8b924ffa5a2@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: Fix conditional for substituting empty ACPI functions [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Fri Aug 2 16:22:14 2024 +0100

    i2c: Fix conditional for substituting empty ACPI functions
    
    [ Upstream commit f17c06c6608ad4ecd2ccf321753fb511812d821b ]
    
    Add IS_ENABLED(CONFIG_I2C) to the conditional around a bunch of ACPI
    functions.
    
    The conditional around these functions depended only on CONFIG_ACPI.
    But the functions are implemented in I2C core, so are only present if
    CONFIG_I2C is enabled.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: Use IS_REACHABLE() for substituting empty ACPI functions [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Wed Aug 14 13:16:49 2024 +0100

    i2c: Use IS_REACHABLE() for substituting empty ACPI functions
    
    commit 71833e79a42178d8a50b5081c98c78ace9325628 upstream.
    
    Replace IS_ENABLED() with IS_REACHABLE() to substitute empty stubs for:
        i2c_acpi_get_i2c_resource()
        i2c_acpi_client_count()
        i2c_acpi_find_bus_speed()
        i2c_acpi_new_device_by_fwnode()
        i2c_adapter *i2c_acpi_find_adapter_by_handle()
        i2c_acpi_waive_d0_probe()
    
    commit f17c06c6608a ("i2c: Fix conditional for substituting empty ACPI
    functions") partially fixed this conditional to depend on CONFIG_I2C,
    but used IS_ENABLED(), which is wrong since CONFIG_I2C is tristate.
    
    CONFIG_ACPI is boolean but let's also change it to use IS_REACHABLE()
    to future-proof it against becoming tristate.
    
    Somehow despite testing various combinations of CONFIG_I2C and CONFIG_ACPI
    we missed the combination CONFIG_I2C=m, CONFIG_ACPI=y.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: f17c06c6608a ("i2c: Fix conditional for substituting empty ACPI functions")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202408141333.gYnaitcV-lkp@intel.com/
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup [+ + +]
Author: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Date:   Fri Jun 28 16:15:58 2024 +0300

    i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup
    
    [ Upstream commit 8a2be2f1db268ec735419e53ef04ca039fc027dc ]
    
    Definitely condition dma_get_cache_alignment * defined value > 256
    during driver initialization is not reason to BUG_ON(). Turn that to
    graceful error out with -EINVAL.
    
    Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Link: https://lore.kernel.org/r/20240628131559.502822-3-jarkko.nikula@linux.intel.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ice: check ICE_VSI_DOWN under rtnl_lock when preparing for reset [+ + +]
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date:   Fri Aug 23 11:59:29 2024 +0200

    ice: check ICE_VSI_DOWN under rtnl_lock when preparing for reset
    
    [ Upstream commit d8c40b9d3a6cef61eb5a0c58c34a3090ea938d89 ]
    
    Consider the following scenario:
    
    .ndo_bpf()              | ice_prepare_for_reset()               |
    ________________________|_______________________________________|
    rtnl_lock()             |                                       |
    ice_down()              |                                       |
                            | test_bit(ICE_VSI_DOWN) - true         |
                            | ice_dis_vsi() returns                 |
    ice_up()                |                                       |
                            | proceeds to rebuild a running VSI     |
    
    .ndo_bpf() is not the only rtnl-locked callback that toggles the interface
    to apply new configuration. Another example is .set_channels().
    
    To avoid the race condition above, act only after reading ICE_VSI_DOWN
    under rtnl_lock.
    
    Fixes: 0f9d5027a749 ("ice: Refactor VSI allocation, deletion and rebuild flow")
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com>
    Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
    Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    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>

 
igc: Unlock on error in igc_io_resume() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Aug 29 22:22:45 2024 +0300

    igc: Unlock on error in igc_io_resume()
    
    [ Upstream commit ef4a99a0164e3972abb421cbb1b09ea6c61414df ]
    
    Call rtnl_unlock() on this error path, before returning.
    
    Fixes: bc23aa949aeb ("igc: Add pcie error handler support")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Gerhard Engleder <gerhard@engleder-embedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: adc: ad7124: fix chip ID mismatch [+ + +]
Author: Dumitru Ceclan <mitrutzceclan@gmail.com>
Date:   Wed Jul 31 15:37:22 2024 +0300

    iio: adc: ad7124: fix chip ID mismatch
    
    commit 96f9ab0d5933c1c00142dd052f259fce0bc3ced2 upstream.
    
    The ad7124_soft_reset() function has the assumption that the chip will
    assert the "power-on reset" bit in the STATUS register after a software
    reset without any delay. The POR bit =0 is used to check if the chip
    initialization is done.
    
    A chip ID mismatch probe error appears intermittently when the probe
    continues too soon and the ID register does not contain the expected
    value.
    
    Fix by adding a 200us delay after the software reset command is issued.
    
    Fixes: b3af341bbd96 ("iio: adc: Add ad7124 support")
    Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
    Reviewed-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://patch.msgid.link/20240731-ad7124-fix-v1-1-46a76aa4b9be@analog.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adc: ad7124: fix config comparison [+ + +]
Author: Dumitru Ceclan <mitrutzceclan@gmail.com>
Date:   Wed Jul 31 15:37:23 2024 +0300

    iio: adc: ad7124: fix config comparison
    
    commit 2f6b92d0f69f04d9e2ea0db1228ab7f82f3173af upstream.
    
    The ad7124_find_similar_live_cfg() computes the compare size by
    substracting the address of the cfg struct from the address of the live
    field. Because the live field is the first field in the struct, the
    result is 0.
    
    Also, the memcmp() call is made from the start of the cfg struct, which
    includes the live and cfg_slot fields, which are not relevant for the
    comparison.
    
    Fix by grouping the relevant fields with struct_group() and use the
    size of the group to compute the compare size; make the memcmp() call
    from the address of the group.
    
    Fixes: 7b8d045e497a ("iio: adc: ad7124: allow more than 8 channels")
    Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
    Reviewed-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://patch.msgid.link/20240731-ad7124-fix-v1-2-46a76aa4b9be@analog.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

 
iommu: sun50i: clear bypass register [+ + +]
Author: Jernej Skrabec <jernej.skrabec@gmail.com>
Date:   Sun Jun 16 23:40:52 2024 +0100

    iommu: sun50i: clear bypass register
    
    [ Upstream commit 927c70c93d929f4c2dcaf72f51b31bb7d118a51a ]
    
    The Allwinner H6 IOMMU has a bypass register, which allows to circumvent
    the page tables for each possible master. The reset value for this
    register is 0, which disables the bypass.
    The Allwinner H616 IOMMU resets this register to 0x7f, which activates
    the bypass for all masters, which is not what we want.
    
    Always clear this register to 0, to enforce the usage of page tables,
    and make this driver compatible with the H616 in this respect.
    
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Chen-Yu Tsai <wens@csie.org>
    Link: https://lore.kernel.org/r/20240616224056.29159-2-andre.przywara@arm.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ionic: fix potential irq name truncation [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Tue May 28 17:02:53 2024 -0700

    ionic: fix potential irq name truncation
    
    [ Upstream commit 3eb76e71b16e8ba5277bf97617aef51f5e64dbe4 ]
    
    Address a warning about potential string truncation based on the
    string buffer sizes.  We can add some hints to the string format
    specifier to set limits on the resulting possible string to
    squelch the complaints.
    
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Link: https://lore.kernel.org/r/20240529000259.25775-2-shannon.nelson@amd.com
    Signed-off-by: Jakub Kicinski <kuba@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>

 
irqchip/gic-v2m: Fix refcount leak in gicv2m_of_init() [+ + +]
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Tue Aug 20 17:28:43 2024 +0800

    irqchip/gic-v2m: Fix refcount leak in gicv2m_of_init()
    
    commit c5af2c90ba5629f0424a8d315f75fb8d91713c3c upstream.
    
    gicv2m_of_init() fails to perform an of_node_put() when
    of_address_to_resource() fails, leading to a refcount leak.
    
    Address this by moving the error handling path outside of the loop and
    making it common to all failure modes.
    
    Fixes: 4266ab1a8ff5 ("irqchip/gic-v2m: Refactor to prepare for ACPI support")
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240820092843.1219933-1-make24@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kselftests: dmabuf-heaps: Ensure the driver name is null-terminated [+ + +]
Author: Zenghui Yu <yuzenghui@huawei.com>
Date:   Mon Jul 29 10:46:04 2024 +0800

    kselftests: dmabuf-heaps: Ensure the driver name is null-terminated
    
    [ Upstream commit 291e4baf70019f17a81b7b47aeb186b27d222159 ]
    
    Even if a vgem device is configured in, we will skip the import_vgem_fd()
    test almost every time.
    
      TAP version 13
      1..11
      # Testing heap: system
      # =======================================
      # Testing allocation and importing:
      ok 1 # SKIP Could not open vgem -1
    
    The problem is that we use the DRM_IOCTL_VERSION ioctl to query the driver
    version information but leave the name field a non-null-terminated string.
    Terminate it properly to actually test against the vgem device.
    
    While at it, let's check the length of the driver name is exactly 4 bytes
    and return early otherwise (in case there is a name like "vgemfoo" that
    gets converted to "vgem\0" unexpectedly).
    
    Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240729024604.2046-1-yuzenghui@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: Unlock on in ksmbd_tcp_set_interfaces() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Aug 29 22:22:35 2024 +0300

    ksmbd: Unlock on in ksmbd_tcp_set_interfaces()
    
    [ Upstream commit 844436e045ac2ab7895d8b281cb784a24de1d14d ]
    
    Unlock before returning an error code if this allocation fails.
    
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Cc: stable@vger.kernel.org # v5.15+
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: unset the binding mark of a reused connection [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Tue Aug 27 21:44:41 2024 +0900

    ksmbd: unset the binding mark of a reused connection
    
    [ Upstream commit 78c5a6f1f630172b19af4912e755e1da93ef0ab5 ]
    
    Steve French reported null pointer dereference error from sha256 lib.
    cifs.ko can send session setup requests on reused connection.
    If reused connection is used for binding session, conn->binding can
    still remain true and generate_preauth_hash() will not set
    sess->Preauth_HashValue and it will be NULL.
    It is used as a material to create an encryption key in
    ksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer
    dereference error from crypto_shash_update().
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 8 PID: 429254 Comm: kworker/8:39
    Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )
    Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]
    RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]
    <TASK>
    ? show_regs+0x6d/0x80
    ? __die+0x24/0x80
    ? page_fault_oops+0x99/0x1b0
    ? do_user_addr_fault+0x2ee/0x6b0
    ? exc_page_fault+0x83/0x1b0
    ? asm_exc_page_fault+0x27/0x30
    ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]
    ? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]
    ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]
    ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]
    _sha256_update+0x77/0xa0 [sha256_ssse3]
    sha256_avx2_update+0x15/0x30 [sha256_ssse3]
    crypto_shash_update+0x1e/0x40
    hmac_update+0x12/0x20
    crypto_shash_update+0x1e/0x40
    generate_key+0x234/0x380 [ksmbd]
    generate_smb3encryptionkey+0x40/0x1c0 [ksmbd]
    ksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]
    ntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]
    smb2_sess_setup+0x952/0xaa0 [ksmbd]
    __process_request+0xa3/0x1d0 [ksmbd]
    __handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]
    handle_ksmbd_work+0x2d/0xa0 [ksmbd]
    process_one_work+0x16c/0x350
    worker_thread+0x306/0x440
    ? __pfx_worker_thread+0x10/0x10
    kthread+0xef/0x120
    ? __pfx_kthread+0x10/0x10
    ret_from_fork+0x44/0x70
    ? __pfx_kthread+0x10/0x10
    ret_from_fork_asm+0x1b/0x30
    </TASK>
    
    Fixes: f5a544e3bab7 ("ksmbd: add support for SMB3 multichannel")
    Cc: stable@vger.kernel.org # v5.15+
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: SVM: Don't advertise Bus Lock Detect to guest if SVM support is missing [+ + +]
Author: Ravi Bangoria <ravi.bangoria@amd.com>
Date:   Thu Aug 8 06:29:36 2024 +0000

    KVM: SVM: Don't advertise Bus Lock Detect to guest if SVM support is missing
    
    commit 54950bfe2b69cdc06ef753872b5225e54eb73506 upstream.
    
    If host supports Bus Lock Detect, KVM advertises it to guests even if
    SVM support is absent. Additionally, guest wouldn't be able to use it
    despite guest CPUID bit being set. Fix it by unconditionally clearing
    the feature bit in KVM cpu capability.
    
    Reported-by: Jim Mattson <jmattson@google.com>
    Closes: https://lore.kernel.org/r/CALMp9eRet6+v8Y1Q-i6mqPm4hUow_kJNhmVHfOV8tMfuSS=tVg@mail.gmail.com
    Fixes: 76ea438b4afc ("KVM: X86: Expose bus lock debug exception to guest")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
    Link: https://lore.kernel.org/r/20240808062937.1149-4-ravi.bangoria@amd.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: SVM: fix emulation of msr reads/writes of MSR_FS_BASE and MSR_GS_BASE [+ + +]
Author: Maxim Levitsky <mlevitsk@redhat.com>
Date:   Fri Aug 2 18:16:08 2024 +0300

    KVM: SVM: fix emulation of msr reads/writes of MSR_FS_BASE and MSR_GS_BASE
    
    commit dad1613e0533b380318281c1519e1a3477c2d0d2 upstream.
    
    If these msrs are read by the emulator (e.g due to 'force emulation' prefix),
    SVM code currently fails to extract the corresponding segment bases,
    and return them to the emulator.
    
    Fix that.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
    Link: https://lore.kernel.org/r/20240802151608.72896-3-mlevitsk@redhat.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
leds: spi-byte: Call of_node_put() on error path [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Jun 6 20:29:18 2024 +0300

    leds: spi-byte: Call of_node_put() on error path
    
    [ Upstream commit 7f9ab862e05c5bc755f65bf6db7edcffb3b49dfc ]
    
    Add a missing call to of_node_put(np) on error.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20240606173037.3091598-2-andriy.shevchenko@linux.intel.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() [+ + +]
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Sat Aug 10 21:04:35 2024 -0400

    lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()
    
    [ Upstream commit b2f11c6f3e1fc60742673b8675c95b78447f3dae ]
    
    If we need to increase the tree depth, allocate a new node, and then
    race with another thread that increased the tree depth before us, we'll
    still have a preallocated node that might be used later.
    
    If we then use that node for a new non-root node, it'll still have a
    pointer to the old root instead of being zeroed - fix this by zeroing it
    in the cmpxchg failure path.
    
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libbpf: Add NULL checks to bpf_object__{prev_map,next_map} [+ + +]
Author: Andreas Ziegler <ziegler.andreas@siemens.com>
Date:   Wed Jul 3 10:34:36 2024 +0200

    libbpf: Add NULL checks to bpf_object__{prev_map,next_map}
    
    [ Upstream commit cedc12c5b57f7efa6dbebfb2b140e8675f5a2616 ]
    
    In the current state, an erroneous call to
    bpf_object__find_map_by_name(NULL, ...) leads to a segmentation
    fault through the following call chain:
    
      bpf_object__find_map_by_name(obj = NULL, ...)
      -> bpf_object__for_each_map(pos, obj = NULL)
      -> bpf_object__next_map((obj = NULL), NULL)
      -> return (obj = NULL)->maps
    
    While calling bpf_object__find_map_by_name with obj = NULL is
    obviously incorrect, this should not lead to a segmentation
    fault but rather be handled gracefully.
    
    As __bpf_map__iter already handles this situation correctly, we
    can delegate the check for the regular case there and only add
    a check in case the prev or next parameter is NULL.
    
    Signed-off-by: Andreas Ziegler <ziegler.andreas@siemens.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240703083436.505124-1-ziegler.andreas@siemens.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

    Linux 5.15.167
    
    Link: https://lore.kernel.org/r/20240910092558.714365667@linuxfoundation.org
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Link: https://lore.kernel.org/r/20240911130535.165892968@linuxfoundation.org
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    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>

media: vivid: don't set HDMI TX controls if there are no HDMI outputs [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Mon Jun 24 12:52:59 2024 +0300

    media: vivid: don't set HDMI TX controls if there are no HDMI outputs
    
    [ Upstream commit 17763960b1784578e8fe915304b330922f646209 ]
    
    When setting the EDID it would attempt to update two controls
    that are only present if there is an HDMI output configured.
    
    If there isn't any (e.g. when the vivid module is loaded with
    node_types=1), then calling VIDIOC_S_EDID would crash.
    
    Fix this by first checking if outputs are present.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: vivid: fix wrong sizeimage value for mplane [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Wed Jun 26 12:59:13 2024 +0200

    media: vivid: fix wrong sizeimage value for mplane
    
    [ Upstream commit 0fd7c0c2c156270dceb8c15fad3120cdce03e539 ]
    
    In several places a division by fmt->vdownsampling[p] was
    missing in the sizeimage[p] calculation, causing incorrect
    behavior for multiplanar formats were some planes are smaller
    than the first plane.
    
    Found by new v4l2-compliance tests.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
memcg: protect concurrent access to mem_cgroup_idr [+ + +]
Author: Shakeel Butt <shakeel.butt@linux.dev>
Date:   Fri Aug 2 16:58:22 2024 -0700

    memcg: protect concurrent access to mem_cgroup_idr
    
    commit 9972605a238339b85bd16b084eed5f18414d22db upstream.
    
    Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after
    many small jobs") decoupled the memcg IDs from the CSS ID space to fix the
    cgroup creation failures.  It introduced IDR to maintain the memcg ID
    space.  The IDR depends on external synchronization mechanisms for
    modifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()
    happen within css callback and thus are protected through cgroup_mutex
    from concurrent modifications.  However idr_remove() for mem_cgroup_idr
    was not protected against concurrency and can be run concurrently for
    different memcgs when they hit their refcnt to zero.  Fix that.
    
    We have been seeing list_lru based kernel crashes at a low frequency in
    our fleet for a long time.  These crashes were in different part of
    list_lru code including list_lru_add(), list_lru_del() and reparenting
    code.  Upon further inspection, it looked like for a given object (dentry
    and inode), the super_block's list_lru didn't have list_lru_one for the
    memcg of that object.  The initial suspicions were either the object is
    not allocated through kmem_cache_alloc_lru() or somehow
    memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but
    returned success.  No evidence were found for these cases.
    
    Looking more deeply, we started seeing situations where valid memcg's id
    is not present in mem_cgroup_idr and in some cases multiple valid memcgs
    have same id and mem_cgroup_idr is pointing to one of them.  So, the most
    reasonable explanation is that these situations can happen due to race
    between multiple idr_remove() calls or race between
    idr_alloc()/idr_replace() and idr_remove().  These races are causing
    multiple memcgs to acquire the same ID and then offlining of one of them
    would cleanup list_lrus on the system for all of them.  Later access from
    other memcgs to the list_lru cause crashes due to missing list_lru_one.
    
    Link: https://lkml.kernel.org/r/20240802235822.1830976-1-shakeel.butt@linux.dev
    Fixes: 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs")
    Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
    Acked-by: Muchun Song <muchun.song@linux.dev>
    Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    [ Adapted over commit be740503ed03 ("mm: memcontrol: fix cannot alloc the
      maximum memcg ID") and 6f0df8e16eb5 ("memcontrol: ensure memcg acquired by id
      is properly set up") both are not in the tree ]
    Signed-off-by: Tomas Krcka <krckatom@amazon.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed [+ + +]
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Tue Aug 13 10:59:08 2024 +0100

    MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed
    
    [ Upstream commit 50f2b98dc83de7809a5c5bf0ccf9af2e75c37c13 ]
    
    This avoids warning:
    
    [    0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283
    
    Caused by get_c0_compare_int on secondary CPU.
    
    We also skipped saving IRQ number to struct clock_event_device *cd as
    it's never used by clockevent core, as per comments it's only meant
    for "non CPU local devices".
    
    Reported-by: Serge Semin <fancer.lancer@gmail.com>
    Closes: https://lore.kernel.org/linux-mips/6szkkqxpsw26zajwysdrwplpjvhl5abpnmxgu2xuj3dkzjnvsf@4daqrz4mf44k/
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Tested-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mmc: cqhci: Fix checking of CQHCI_HALT state [+ + +]
Author: Seunghwan Baek <sh8267.baek@samsung.com>
Date:   Thu Aug 29 15:18:22 2024 +0900

    mmc: cqhci: Fix checking of CQHCI_HALT state
    
    commit aea62c744a9ae2a8247c54ec42138405216414da upstream.
    
    To check if mmc cqe is in halt state, need to check set/clear of CQHCI_HALT
    bit. At this time, we need to check with &, not &&.
    
    Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
    Cc: stable@vger.kernel.org
    Signed-off-by: Seunghwan Baek <sh8267.baek@samsung.com>
    Reviewed-by: Ritesh Harjani <ritesh.list@gmail.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20240829061823.3718-2-sh8267.baek@samsung.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

mmc: sdhci-of-aspeed: fix module autoloading [+ + +]
Author: Liao Chen <liaochen4@huawei.com>
Date:   Mon Aug 26 12:48:51 2024 +0000

    mmc: sdhci-of-aspeed: fix module autoloading
    
    commit 6e540da4c1db7b840e347c4dfe48359b18b7e376 upstream.
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
    based on the alias from of_device_id table.
    
    Signed-off-by: Liao Chen <liaochen4@huawei.com>
    Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au>
    Fixes: bb7b8ec62dfb ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240826124851.379759-1-liaochen4@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mptcp: avoid duplicated SUB_CLOSED events [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:34:31 2024 +0200

    mptcp: avoid duplicated SUB_CLOSED events
    
    commit d82809b6c5f2676b382f77a5cbeb1a5d91ed2235 upstream.
    
    The initial subflow might have already been closed, but still in the
    connection list. When the worker is instructed to close the subflows
    that have been marked as closed, it might then try to close the initial
    subflow again.
    
     A consequence of that is that the SUB_CLOSED event can be seen twice:
    
      # ip mptcp endpoint
      1.1.1.1 id 1 subflow dev eth0
      2.2.2.2 id 2 subflow dev eth1
    
      # ip mptcp monitor &
      [         CREATED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9
      [     ESTABLISHED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9
      [  SF_ESTABLISHED] remid=0 locid=2 saddr4=2.2.2.2 daddr4=9.9.9.9
    
      # ip mptcp endpoint delete id 1
      [       SF_CLOSED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9
      [       SF_CLOSED] remid=0 locid=0 saddr4=1.1.1.1 daddr4=9.9.9.9
    
    The first one is coming from mptcp_pm_nl_rm_subflow_received(), and the
    second one from __mptcp_close_subflow().
    
    To avoid doing the post-closed processing twice, the subflow is now
    marked as closed the first time.
    
    Note that it is not enough to check if we are dealing with the first
    subflow and check its sk_state: the subflow might have been reset or
    closed before calling mptcp_close_ssk().
    
    Fixes: b911c97c7dc7 ("mptcp: add netlink event support")
    Cc: stable@vger.kernel.org
    Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflict in protocol.h due to commit f1f26512a9bf ("mptcp: use plain
      bool instead of custom binary enum"), commit dfc8d0603033 ("mptcp:
      implement delayed seq generation for passive fastopen") and more that
      are not in this version, because they modify the context and the size
      of __unused. The conflict is easy to resolve, by not only adding the
      new field (close_event_done), and __unused. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: close subflow when receiving TCP+FIN [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:35:21 2024 +0200

    mptcp: close subflow when receiving TCP+FIN
    
    commit f09b0ad55a1196f5891663f8888463c0541059cb upstream.
    
    When a peer decides to close one subflow in the middle of a connection
    having multiple subflows, the receiver of the first FIN should accept
    that, and close the subflow on its side as well. If not, the subflow
    will stay half closed, and would even continue to be used until the end
    of the MPTCP connection or a reset from the network.
    
    The issue has not been seen before, probably because the in-kernel
    path-manager always sends a RM_ADDR before closing the subflow. Upon the
    reception of this RM_ADDR, the other peer will initiate the closure on
    its side as well. On the other hand, if the RM_ADDR is lost, or if the
    path-manager of the other peer only closes the subflow without sending a
    RM_ADDR, the subflow would switch to TCP_CLOSE_WAIT, but that's it,
    leaving the subflow half-closed.
    
    So now, when the subflow switches to the TCP_CLOSE_WAIT state, and if
    the MPTCP connection has not been closed before with a DATA_FIN, the
    kernel owning the subflow schedules its worker to initiate the closure
    on its side as well.
    
    This issue can be easily reproduced with packetdrill, as visible in [1],
    by creating an additional subflow, injecting a FIN+ACK before sending
    the DATA_FIN, and expecting a FIN+ACK in return.
    
    Fixes: 40947e13997a ("mptcp: schedule worker when subflow is closed")
    Cc: stable@vger.kernel.org
    Link: https://github.com/multipath-tcp/packetdrill/pull/154 [1]
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-1-905199fe1172@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ No conflicts but 'sk' is not available in __mptcp_close_subflow in
      this version. It would require b6985b9b8295 ("mptcp: use the workqueue
      to destroy unaccepted sockets") which has not been backported to this
      version. It is easier to get 'sk' by casting 'msk' into a 'struct
      sock'. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: constify a bunch of of helpers [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Fri Sep 6 10:31:52 2024 +0200

    mptcp: constify a bunch of of helpers
    
    commit 90d930882139f166ed2551205d6f6d8c50b656fb upstream.
    
    A few pm-related helpers don't touch arguments which lacking
    the const modifier, let's constify them.
    
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 48e50dcbcbaa ("mptcp: pm: avoid possible UaF when selecting endp")
    [ Conflicts because a few modified helpers from the original patch are
      not present in this version. We don't need to do anything with them. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: ADD_ADDR 0 is not a new address [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:34:55 2024 +0200

    mptcp: pm: ADD_ADDR 0 is not a new address
    
    commit 57f86203b41c98b322119dfdbb1ec54ce5e3369b upstream.
    
    The ADD_ADDR 0 with the address from the initial subflow should not be
    considered as a new address: this is not something new. If the host
    receives it, it simply means that the address is available again.
    
    When receiving an ADD_ADDR for the ID 0, the PM already doesn't consider
    it as new by not incrementing the 'add_addr_accepted' counter. But the
    'accept_addr' might not be set if the limit has already been reached:
    this can be bypassed in this case. But before, it is important to check
    that this ADD_ADDR for the ID 0 is for the same address as the initial
    subflow. If not, it is not something that should happen, and the
    ADD_ADDR can be ignored.
    
    Note that if an ADD_ADDR is received while there is already a subflow
    opened using the same address, this ADD_ADDR is ignored as well. It
    means that if multiple ADD_ADDR for ID 0 are received, there will not be
    any duplicated subflows created by the client.
    
    Fixes: d0876b2284cf ("mptcp: add the incoming RM_ADDR support")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflicts in pm.c, due to commit 4d25247d3ae4 ("mptcp: bypass
      in-kernel PM restrictions for non-kernel PMs"), which is not in this
      version, and changes the context. The same fix can be applied here by
      adding the new check at the same place. Note that addresses_equal()
      has been used instead of mptcp_addresses_equal(), renamed in commit
      4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs"),
      not in this version. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: avoid possible UaF when selecting endp [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:31:53 2024 +0200

    mptcp: pm: avoid possible UaF when selecting endp
    
    commit 48e50dcbcbaaf713d82bf2da5c16aeced94ad07d upstream.
    
    select_local_address() and select_signal_address() both select an
    endpoint entry from the list inside an RCU protected section, but return
    a reference to it, to be read later on. If the entry is dereferenced
    after the RCU unlock, reading info could cause a Use-after-Free.
    
    A simple solution is to copy the required info while inside the RCU
    protected section to avoid any risk of UaF later. The address ID might
    need to be modified later to handle the ID0 case later, so a copy seems
    OK to deal with.
    
    Reported-by: Paolo Abeni <pabeni@redhat.com>
    Closes: https://lore.kernel.org/45cd30d3-7710-491c-ae4d-a1368c00beb1@redhat.com
    Fixes: 01cacb00b35c ("mptcp: add netlink-based PM")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-14-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_netlink.c, because quite a bit of new code has been
      added around since commit 86e39e04482b ("mptcp: keep track of local
      endpoint still available for each msk"). But the issue is still there.
      The conflicts have been resolved using the same way: by adding a new
      parameter to select_local_address() and select_signal_address(), and
      use it instead of the pointer they were previously returning. The code
      is simpler in this version, this conflict resolution looks safe. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: check add_addr_accept_max before accepting new ADD_ADDR [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:30:44 2024 +0200

    mptcp: pm: check add_addr_accept_max before accepting new ADD_ADDR
    
    commit 0137a3c7c2ea3f9df8ebfc65d78b4ba712a187bb upstream.
    
    The limits might have changed in between, it is best to check them
    before accepting new ADD_ADDR.
    
    Fixes: d0876b2284cf ("mptcp: add the incoming RM_ADDR support")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-10-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_netlink.c, because the context is different, but the
      same lines can still be modified to fix the issue. This is due to
      commit 322ea3778965 ("mptcp: pm: only mark 'subflow' endp as
      available") not being backported to this version. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: do not remove already closed subflows [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:34:02 2024 +0200

    mptcp: pm: do not remove already closed subflows
    
    commit 58e1b66b4e4b8a602d3f2843e8eba00a969ecce2 upstream.
    
    It is possible to have in the list already closed subflows, e.g. the
    initial subflow has been already closed, but still in the list. No need
    to try to close it again, and increments the related counters again.
    
    Fixes: 0ee4261a3681 ("mptcp: implement mptcp_pm_remove_subflow")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflicts in pm_netlink.c, due to commit 3ad14f54bd74 ("mptcp: more
      accurate MPC endpoint tracking") which is not in this version, and
      changes the context. The same fix can be applied here by adding the
      new check at the same place. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: fullmesh: select the right ID later [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:31:24 2024 +0200

    mptcp: pm: fullmesh: select the right ID later
    
    commit 09355f7abb9fbfc1a240be029837921ea417bf4f upstream.
    
    When reacting upon the reception of an ADD_ADDR, the in-kernel PM first
    looks for fullmesh endpoints. If there are some, it will pick them,
    using their entry ID.
    
    It should set the ID 0 when using the endpoint corresponding to the
    initial subflow, it is a special case imposed by the MPTCP specs.
    
    Note that msk->mpc_endpoint_id might not be set when receiving the first
    ADD_ADDR from the server. So better to compare the addresses.
    
    Fixes: 1a0d6136c5f0 ("mptcp: local addresses fullmesh")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-12-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_netlink.c, because the new 'mpc_addr' variable is
      added where the 'local' one was, before commit b9d69db87fb7 ("mptcp:
      let the in-kernel PM use mixed IPv4 and IPv6 addresses"), that is not
      a candidate for the backports. This 'local' variable has been moved to
      the new place to reduce the scope, and help with possible future
      backports.
      Note that addresses_equal() has been used instead of
      mptcp_addresses_equal(), renamed in commit 4638de5aefe5 ("mptcp:
      handle local addrs announced by userspace PMs"), not in this version. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: only decrement add_addr_accepted for MPJ req [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:30:01 2024 +0200

    mptcp: pm: only decrement add_addr_accepted for MPJ req
    
    commit 1c1f721375989579e46741f59523e39ec9b2a9bd upstream.
    
    Adding the following warning ...
    
      WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)
    
    ... before decrementing the add_addr_accepted counter helped to find a
    bug when running the "remove single subflow" subtest from the
    mptcp_join.sh selftest.
    
    Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the
    subflow closure. Before this patch, and upon the reception of the
    RM_ADDR, the other peer will then try to decrement this
    add_addr_accepted. That's not correct because the attached subflows have
    not been created upon the reception of an ADD_ADDR.
    
    A way to solve that is to decrement the counter only if the attached
    subflow was an MP_JOIN to a remote id that was not 0, and initiated by
    the host receiving the RM_ADDR.
    
    Fixes: d0876b2284cf ("mptcp: add the incoming RM_ADDR support")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-9-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_netlink.c, because the context is different, but the
      same lines can still be modified. The conflicts are due to commit
      4d25247d3ae4 ("mptcp: bypass in-kernel PM restrictions for non-kernel
      PMs") and commit a88c9e496937 ("mptcp: do not block subflows creation
      on errors"), adding new features and not present in this version.
      Note that because some features to better track subflows are missing
      in this version, it is required to remove the WARN_ON, because the
      counter could be 0 in some cases. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: re-using ID of unused flushed subflows [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:28:54 2024 +0200

    mptcp: pm: re-using ID of unused flushed subflows
    
    commit ef34a6ea0cab1800f4b3c9c3c2cefd5091e03379 upstream.
    
    If no subflows are attached to the 'subflow' endpoints that are being
    flushed, the corresponding addr IDs will not be marked as available
    again.
    
    Mark all ID as being available when flushing all the 'subflow'
    endpoints, and reset local_addr_used counter to cover these cases.
    
    Note that mptcp_pm_remove_addrs_and_subflows() helper is only called for
    flushing operations, not to remove a specific set of addresses and
    subflows.
    
    Fixes: 06faa2271034 ("mptcp: remove multi addresses and subflows in PM")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240819-net-mptcp-pm-reusing-id-v1-5-38035d40de5b@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ No conflicts, but the line modifying msk->pm.id_avail_bitmap has been
      removed, as it is not in this version, introduced later in commit
      86e39e04482b ("mptcp: keep track of local endpoint still available for
      each msk") and depending on other ones. The best we can do in this
      version is to reset local_addr_used counter, better than nothing. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: send ACK on an active subflow [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:33:35 2024 +0200

    mptcp: pm: send ACK on an active subflow
    
    commit c07cc3ed895f9bfe0c53b5ed6be710c133b4271c upstream.
    
    Taking the first one on the list doesn't work in some cases, e.g. if the
    initial subflow is being removed. Pick another one instead of not
    sending anything.
    
    Fixes: 84dfe3677a6f ("mptcp: send out dedicated ADD_ADDR packet")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflicts in pm_netlink.c, because the code has been refactored in
      commit f5360e9b314c ("mptcp: introduce and use mptcp_pm_send_ack()")
      which is difficult to backport in this version. The same adaptations
      have been applied: iterating over all subflows, and send the ACK on
      the first active subflow. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: skip connecting to already established sf [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:33:09 2024 +0200

    mptcp: pm: skip connecting to already established sf
    
    commit bc19ff57637ff563d2bdf2b385b48c41e6509e0d upstream.
    
    The lookup_subflow_by_daddr() helper checks if there is already a
    subflow connected to this address. But there could be a subflow that is
    closing, but taking time due to some reasons: latency, losses, data to
    process, etc.
    
    If an ADD_ADDR is received while the endpoint is being closed, it is
    better to try connecting to it, instead of rejecting it: the peer which
    has sent the ADD_ADDR will not be notified that the ADD_ADDR has been
    rejected for this reason, and the expected subflow will not be created
    at the end.
    
    This helper should then only look for subflows that are established, or
    going to be, but not the ones being closed.
    
    Fixes: d84ad04941c3 ("mptcp: skip connecting the connected address")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    [ Conflicts in pm_netlink.c, due to commit 4638de5aefe5 ("mptcp: handle
      local addrs announced by userspace PMs"), not in this version, and
      changing the context. The same fix can still be applied. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pr_debug: add missing \n at the end [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Sep 6 10:32:43 2024 +0200

    mptcp: pr_debug: add missing \n at the end
    
    commit cb41b195e634d3f1ecfcd845314e64fd4bb3c7aa upstream.
    
    pr_debug() have been added in various places in MPTCP code to help
    developers to debug some situations. With the dynamic debug feature, it
    is easy to enable all or some of them, and asks users to reproduce
    issues with extra debug.
    
    Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
    are used in MPTCP code. So the goal was not to display multiple debug
    messages on one line: they were then not missing the '\n' on purpose.
    Not having the new line at the end causes these messages to be printed
    with a delay, when something else needs to be printed. This issue is not
    visible when many messages need to be printed, but it is annoying and
    confusing when only specific messages are expected, e.g.
    
      # echo "func mptcp_pm_add_addr_echoed +fmp" \
            > /sys/kernel/debug/dynamic_debug/control
      # ./mptcp_join.sh "signal address"; \
            echo "$(awk '{print $1}' /proc/uptime) - end"; \
            sleep 5s; \
            echo "$(awk '{print $1}' /proc/uptime) - restart"; \
            ./mptcp_join.sh "signal address"
      013 signal address
          (...)
      10.75 - end
      15.76 - restart
      013 signal address
      [  10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
          (...)
    
      => a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
         which was printed at the 15.76 ts.
    
    The 'Fixes' tag here below points to the first pr_debug() used without
    '\n' in net/mptcp. This patch could be split in many small ones, with
    different Fixes tag, but it doesn't seem worth it, because it is easy to
    re-generate this patch with this simple 'sed' command:
    
      git grep -l pr_debug -- net/mptcp |
        xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
    
    So in case of conflicts, simply drop the modifications, and launch this
    command.
    
    Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
    Cc: stable@vger.kernel.org
    Reviewed-by: Geliang Tang <geliang@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ As mentioned above, conflicts were expected, and resolved by using the
      'sed' command which is visible above. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.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: 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: change maximum number of UDP segments to 128 [+ + +]
Author: Yuri Benditovich <yuri.benditovich@daynix.com>
Date:   Mon Sep 9 14:22:46 2024 -0400

    net: change maximum number of UDP segments to 128
    
    [ Upstream commit 1382e3b6a3500c245e5278c66d210c02926f804f ]
    
    The commit fc8b2a619469
    ("net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation")
    adds check of potential number of UDP segments vs
    UDP_MAX_SEGMENTS in linux/virtio_net.h.
    After this change certification test of USO guest-to-guest
    transmit on Windows driver for virtio-net device fails,
    for example with packet size of ~64K and mss of 536 bytes.
    In general the USO should not be more restrictive than TSO.
    Indeed, in case of unreasonably small mss a lot of segments
    can cause queue overflow and packet loss on the destination.
    Limit of 128 segments is good for any practical purpose,
    with minimal meaningful mss of 536 the maximal UDP packet will
    be divided to ~120 segments.
    The number of segments for UDP packets is validated vs
    UDP_MAX_SEGMENTS also in udp.c (v4,v6), this does not affect
    quest-to-guest path but does affect packets sent to host, for
    example.
    It is important to mention that UDP_MAX_SEGMENTS is kernel-only
    define and not available to user mode socket applications.
    In order to request MSS smaller than MTU the applications
    just uses setsockopt with SOL_UDP and UDP_SEGMENT and there is
    no limitations on socket API level.
    
    Fixes: fc8b2a619469 ("net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation")
    Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    
    [5.15-stable: fix conflict with neighboring but unrelated code from
                  e2a4392b61f6 ("udp: introduce udp->udp_flags")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: dpaa: avoid on-stack arrays of NR_CPUS elements [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Sun Jul 14 01:53:32 2024 +0300

    net: dpaa: avoid on-stack arrays of NR_CPUS elements
    
    [ Upstream commit 555a05d84ca2c587e2d4777006e2c2fb3dfbd91d ]
    
    The dpaa-eth driver is written for PowerPC and Arm SoCs which have 1-24
    CPUs. It depends on CONFIG_NR_CPUS having a reasonably small value in
    Kconfig. Otherwise, there are 2 functions which allocate on-stack arrays
    of NR_CPUS elements, and these can quickly explode in size, leading to
    warnings such as:
    
      drivers/net/ethernet/freescale/dpaa/dpaa_eth.c:3280:12: warning:
      stack frame size (16664) exceeds limit (2048) in 'dpaa_eth_probe' [-Wframe-larger-than]
    
    The problem is twofold:
    - Reducing the array size to the boot-time num_possible_cpus() (rather
      than the compile-time NR_CPUS) creates a variable-length array,
      which should be avoided in the Linux kernel.
    - Using NR_CPUS as an array size makes the driver blow up in stack
      consumption with generic, as opposed to hand-crafted, .config files.
    
    A simple solution is to use dynamic allocation for num_possible_cpus()
    elements (aka a small number determined at runtime).
    
    Link: https://lore.kernel.org/all/202406261920.l5pzM1rj-lkp@intel.com/
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Breno Leitao <leitao@debian.org>
    Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
    Link: https://patch.msgid.link/20240713225336.1746343-2-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: drop bad gso csum_start and offset in virtio_net_hdr [+ + +]
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Sep 9 14:22:48 2024 -0400

    net: drop bad gso csum_start and offset in virtio_net_hdr
    
    [ Upstream commit 89add40066f9ed9abe5f7f886fe5789ff7e0c50e ]
    
    Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb
    for GSO packets.
    
    The function already checks that a checksum requested with
    VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets
    this might not hold for segs after segmentation.
    
    Syzkaller demonstrated to reach this warning in skb_checksum_help
    
            offset = skb_checksum_start_offset(skb);
            ret = -EINVAL;
            if (WARN_ON_ONCE(offset >= skb_headlen(skb)))
    
    By injecting a TSO packet:
    
    WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0
     ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774
     ip_finish_output_gso net/ipv4/ip_output.c:279 [inline]
     __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301
     iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82
     ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813
     __gre_xmit net/ipv4/ip_gre.c:469 [inline]
     ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661
     __netdev_start_xmit include/linux/netdevice.h:4850 [inline]
     netdev_start_xmit include/linux/netdevice.h:4864 [inline]
     xmit_one net/core/dev.c:3595 [inline]
     dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611
     __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261
     packet_snd net/packet/af_packet.c:3073 [inline]
    
    The geometry of the bad input packet at tcp_gso_segment:
    
    [   52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0
    [   52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244
    [   52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0))
    [   52.003050][ T8403] csum(0x60000c7 start=199 offset=1536
    ip_summed=3 complete_sw=0 valid=0 level=0)
    
    Mitigate with stricter input validation.
    
    csum_offset: for GSO packets, deduce the correct value from gso_type.
    This is already done for USO. Extend it to TSO. Let UFO be:
    udp[46]_ufo_fragment ignores these fields and always computes the
    checksum in software.
    
    csum_start: finding the real offset requires parsing to the transport
    header. Do not add a parser, use existing segmentation parsing. Thanks
    to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded.
    Again test both TSO and USO. Do not test UFO for the above reason, and
    do not test UDP tunnel offload.
    
    GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be
    CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit
    from devices with no checksum offload"), but then still these fields
    are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no
    need to test for ip_summed == CHECKSUM_PARTIAL first.
    
    This revises an existing fix mentioned in the Fixes tag, which broke
    small packets with GSO offload, as detected by kselftests.
    
    Link: https://syzkaller.appspot.com/bug?extid=e1db31216c789f552871
    Link: https://lore.kernel.org/netdev/20240723223109.2196886-1-kuba@kernel.org
    Fixes: e269d79c7d35 ("net: missing check virtio")
    Cc: stable@vger.kernel.org
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Link: https://patch.msgid.link/20240729201108.1615114-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    
    [5.15 stable: clean backport]
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation [+ + +]
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Sep 9 14:22:45 2024 -0400

    net: more strict VIRTIO_NET_HDR_GSO_UDP_L4 validation
    
    [ Upstream commit fc8b2a619469378717e7270d2a4e1ef93c585f7a ]
    
    Syzbot reported two new paths to hit an internal WARNING using the
    new virtio gso type VIRTIO_NET_HDR_GSO_UDP_L4.
    
        RIP: 0010:skb_checksum_help+0x4a2/0x600 net/core/dev.c:3260
        skb len=64521 gso_size=344
    and
    
        RIP: 0010:skb_warn_bad_offload+0x118/0x240 net/core/dev.c:3262
    
    Older virtio types have historically had loose restrictions, leading
    to many entirely impractical fuzzer generated packets causing
    problems deep in the kernel stack. Ideally, we would have had strict
    validation for all types from the start.
    
    New virtio types can have tighter validation. Limit UDP GSO packets
    inserted via virtio to the same limits imposed by the UDP_SEGMENT
    socket interface:
    
    1. must use checksum offload
    2. checksum offload matches UDP header
    3. no more segments than UDP_MAX_SEGMENTS
    4. UDP GSO does not take modifier flags, notably SKB_GSO_TCP_ECN
    
    Fixes: 860b7f27b8f7 ("linux/virtio_net.h: Support USO offload in vnet header.")
    Reported-by: syzbot+01cdbc31e9c0ae9b33ac@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/0000000000005039270605eb0b7f@google.com/
    Reported-by: syzbot+c99d835ff081ca30f986@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/0000000000005426680605eb0b9f@google.com/
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    
    [5.15 stable: clean backport]
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
NFSv4: Add missing rescheduling points in nfs_client_return_marked_delegations [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Aug 21 14:05:00 2024 -0400

    NFSv4: Add missing rescheduling points in nfs_client_return_marked_delegations
    
    [ Upstream commit a017ad1313fc91bdf235097fd0a02f673fc7bb11 ]
    
    We're seeing reports of soft lockups when iterating through the loops,
    so let's add rescheduling points.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
nvme-pci: Add sleep quirk for Samsung 990 Evo [+ + +]
Author: Georg Gottleuber <ggo@tuxedocomputers.com>
Date:   Tue Aug 27 12:41:33 2024 +0200

    nvme-pci: Add sleep quirk for Samsung 990 Evo
    
    commit 61aa894e7a2fda4ee026523b01d07e83ce2abb72 upstream.
    
    On some TUXEDO platforms, a Samsung 990 Evo NVMe leads to a high
    power consumption in s2idle sleep (2-3 watts).
    
    This patch applies 'Force No Simple Suspend' quirk to achieve a
    sleep with a lower power consumption, typically around 0.5 watts.
    
    Signed-off-by: Georg Gottleuber <ggo@tuxedocomputers.com>
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
nvmet-tcp: fix kernel crash if commands allocation fails [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Wed Aug 21 16:28:26 2024 +0200

    nvmet-tcp: fix kernel crash if commands allocation fails
    
    [ Upstream commit 5572a55a6f830ee3f3a994b6b962a5c327d28cb3 ]
    
    If the commands allocation fails in nvmet_tcp_alloc_cmds()
    the kernel crashes in nvmet_tcp_release_queue_work() because of
    a NULL pointer dereference.
    
      nvmet: failed to install queue 0 cntlid 1 ret 6
      Unable to handle kernel NULL pointer dereference at
             virtual address 0000000000000008
    
    Fix the bug by setting queue->nr_cmds to zero in case
    nvmet_tcp_alloc_cmd() fails.
    
    Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

PCI: al: Check IORESOURCE_BUS existence during probe [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Fri May 3 15:57:05 2024 +0300

    PCI: al: Check IORESOURCE_BUS existence during probe
    
    [ Upstream commit a9927c2cac6e9831361e43a14d91277818154e6a ]
    
    If IORESOURCE_BUS is not provided in Device Tree it will be fabricated in
    of_pci_parse_bus_range(), so NULL pointer dereference should not happen
    here.
    
    But that's hard to verify, so check for NULL anyway.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Link: https://lore.kernel.org/linux-pci/20240503125705.46055-1-amishin@t-argos.ru
    Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    [bhelgaas: commit log]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) [+ + +]
Author: Kishon Vijay Abraham I <kishon@kernel.org>
Date:   Fri Jun 28 13:45:29 2024 +0200

    PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)
    
    [ Upstream commit 86f271f22bbb6391410a07e08d6ca3757fda01fa ]
    
    Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0
    (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an
    inbound PCIe TLP spans more than two internal AXI 128-byte bursts,
    the bus may corrupt the packet payload and the corrupt data may
    cause associated applications or the processor to hang.
    
    The workaround for Errata #i2037 is to limit the maximum read
    request size and maximum payload size to 128 bytes. Add workaround
    for Errata #i2037 here.
    
    The errata and workaround is applicable only to AM65x SR 1.0 and
    later versions of the silicon will have this fixed.
    
    [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf
    
    Link: https://lore.kernel.org/linux-pci/16e1fcae-1ea7-46be-b157-096e05661b15@siemens.com
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Achal Verma <a-verma1@ti.com>
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.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>

 
perf/aux: Fix AUX buffer serialization [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Sep 2 10:14:24 2024 +0200

    perf/aux: Fix AUX buffer serialization
    
    commit 2ab9d830262c132ab5db2f571003d80850d56b2a upstream.
    
    Ole reported that event->mmap_mutex is strictly insufficient to
    serialize the AUX buffer, add a per RB mutex to fully serialize it.
    
    Note that in the lock order comment the perf_event::mmap_mutex order
    was already wrong, that is, it nesting under mmap_lock is not new with
    this patch.
    
    Fixes: 45bfb2e50471 ("perf: Add AUX area to ring buffer for raw data streams")
    Reported-by: Ole <ole@binarygecko.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow [+ + +]
Author: Nikita Kiryushin <kiryushin@ancud.ru>
Date:   Wed Mar 27 20:47:47 2024 +0300

    rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
    
    commit cc5645fddb0ce28492b15520306d092730dffa48 upstream.
    
    There is a possibility of buffer overflow in
    show_rcu_tasks_trace_gp_kthread() if counters, passed
    to sprintf() are huge. Counter numbers, needed for this
    are unrealistically high, but buffer overflow is still
    possible.
    
    Use snprintf() with buffer size instead of sprintf().
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: edf3775f0ad6 ("rcu-tasks: Add count for idle tasks on offline CPUs")
    Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
    Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Vamsi Krishna Brahmajosyula <vamsi-krishna.brahmajosyula@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rcu/nocb: Remove buggy bypass lock contention mitigation [+ + +]
Author: Frederic Weisbecker <frederic@kernel.org>
Date:   Thu Apr 25 16:18:35 2024 +0200

    rcu/nocb: Remove buggy bypass lock contention mitigation
    
    [ Upstream commit e4f78057291608f6968a6789c5ebb3bde7d95504 ]
    
    The bypass lock contention mitigation assumes there can be at most
    2 contenders on the bypass lock, following this scheme:
    
    1) One kthread takes the bypass lock
    2) Another one spins on it and increment the contended counter
    3) A third one (a bypass enqueuer) sees the contended counter on and
      busy loops waiting on it to decrement.
    
    However this assumption is wrong. There can be only one CPU to find the
    lock contended because call_rcu() (the bypass enqueuer) is the only
    bypass lock acquire site that may not already hold the NOCB lock
    beforehand, all the other sites must first contend on the NOCB lock.
    Therefore step 2) is impossible.
    
    The other problem is that the mitigation assumes that contenders all
    belong to the same rdp CPU, which is also impossible for a raw spinlock.
    In theory the warning could trigger if the enqueuer holds the bypass
    lock and another CPU flushes the bypass queue concurrently but this is
    prevented from all flush users:
    
    1) NOCB kthreads only flush if they successfully _tried_ to lock the
       bypass lock. So no contention management here.
    
    2) Flush on callbacks migration happen remotely when the CPU is offline.
       No concurrency against bypass enqueue.
    
    3) Flush on deoffloading happen either locally with IRQs disabled or
       remotely when the CPU is not yet online. No concurrency against
       bypass enqueue.
    
    4) Flush on barrier entrain happen either locally with IRQs disabled or
       remotely when the CPU is offline. No concurrency against
       bypass enqueue.
    
    For those reasons, the bypass lock contention mitigation isn't needed
    and is even wrong. Remove it but keep the warning reporting a contended
    bypass lock on a remote CPU, to keep unexpected contention awareness.
    
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/efa: Properly handle unexpected AQ completions [+ + +]
Author: Michael Margolin <mrgolin@amazon.com>
Date:   Mon May 13 06:46:30 2024 +0000

    RDMA/efa: Properly handle unexpected AQ completions
    
    [ Upstream commit 2d0e7ba468eae365f3c4bc9266679e1f8dd405f0 ]
    
    Do not try to handle admin command completion if it has an unexpected
    command id and print a relevant error message.
    
    Reviewed-by: Firas Jahjah <firasj@amazon.com>
    Reviewed-by: Yehuda Yitschak <yehuday@amazon.com>
    Signed-off-by: Michael Margolin <mrgolin@amazon.com>
    Link: https://lore.kernel.org/r/20240513064630.6247-1-mrgolin@amazon.com
    Reviewed-by: Gal Pressman <gal.pressman@linux.dev>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE" [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Aug 27 14:37:22 2024 -0400

    Revert "Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE"
    
    commit 532f8bcd1c2c4e8112f62e1922fd1703bc0ffce0 upstream.
    
    This reverts commit 59b047bc98084f8af2c41483e4d68a5adf2fa7f7 which
    breaks compatibility with commands like:
    
    bluetoothd[46328]: @ MGMT Command: Load.. (0x0013) plen 74  {0x0001} [hci0]
            Keys: 2
            BR/EDR Address: C0:DC:DA:A5:E5:47 (Samsung Electronics Co.,Ltd)
            Key type: Authenticated key from P-256 (0x03)
            Central: 0x00
            Encryption size: 16
            Diversifier[2]: 0000
            Randomizer[8]: 0000000000000000
            Key[16]: 6ed96089bd9765be2f2c971b0b95f624
            LE Address: D7:2A:DE:1E:73:A2 (Static)
            Key type: Unauthenticated key from P-256 (0x02)
            Central: 0x00
            Encryption size: 16
            Diversifier[2]: 0000
            Randomizer[8]: 0000000000000000
            Key[16]: 87dd2546ededda380ffcdc0a8faa4597
    @ MGMT Event: Command Status (0x0002) plen 3                {0x0001} [hci0]
          Load Long Term Keys (0x0013)
            Status: Invalid Parameters (0x0d)
    
    Cc: stable@vger.kernel.org
    Link: https://github.com/bluez/bluez/issues/875
    Fixes: 59b047bc9808 ("Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv: set trap vector earlier [+ + +]
Author: yang.zhang <yang.zhang@hexintek.com>
Date:   Wed May 8 10:24:45 2024 +0800

    riscv: set trap vector earlier
    
    [ Upstream commit 6ad8735994b854b23c824dd6b1dd2126e893a3b4 ]
    
    The exception vector of the booting hart is not set before enabling
    the mmu and then still points to the value of the previous firmware,
    typically _start. That makes it hard to debug setup_vm() when bad
    things happen. So fix that by setting the exception vector earlier.
    
    Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Signed-off-by: yang.zhang <yang.zhang@hexintek.com>
    Link: https://lore.kernel.org/r/20240508022445.6131-1-gaoshanliukou@163.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    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>

 
s390/vmlinux.lds.S: Move ro_after_init section behind rodata section [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Mon Jul 29 13:06:43 2024 +0200

    s390/vmlinux.lds.S: Move ro_after_init section behind rodata section
    
    [ Upstream commit 75c10d5377d8821efafed32e4d72068d9c1f8ec0 ]
    
    The .data.rel.ro and .got section were added between the rodata and
    ro_after_init data section, which adds an RW mapping in between all RO
    mapping of the kernel image:
    
    ---[ Kernel Image Start ]---
    0x000003ffe0000000-0x000003ffe0e00000        14M PMD RO X
    0x000003ffe0e00000-0x000003ffe0ec7000       796K PTE RO X
    0x000003ffe0ec7000-0x000003ffe0f00000       228K PTE RO NX
    0x000003ffe0f00000-0x000003ffe1300000         4M PMD RO NX
    0x000003ffe1300000-0x000003ffe1331000       196K PTE RO NX
    0x000003ffe1331000-0x000003ffe13b3000       520K PTE RW NX <---
    0x000003ffe13b3000-0x000003ffe13d5000       136K PTE RO NX
    0x000003ffe13d5000-0x000003ffe1400000       172K PTE RW NX
    0x000003ffe1400000-0x000003ffe1500000         1M PMD RW NX
    0x000003ffe1500000-0x000003ffe1700000         2M PTE RW NX
    0x000003ffe1700000-0x000003ffe1800000         1M PMD RW NX
    0x000003ffe1800000-0x000003ffe187e000       504K PTE RW NX
    ---[ Kernel Image End ]---
    
    Move the ro_after_init data section again right behind the rodata
    section to prevent interleaving RO and RW mappings:
    
    ---[ Kernel Image Start ]---
    0x000003ffe0000000-0x000003ffe0e00000        14M PMD RO X
    0x000003ffe0e00000-0x000003ffe0ec7000       796K PTE RO X
    0x000003ffe0ec7000-0x000003ffe0f00000       228K PTE RO NX
    0x000003ffe0f00000-0x000003ffe1300000         4M PMD RO NX
    0x000003ffe1300000-0x000003ffe1353000       332K PTE RO NX
    0x000003ffe1353000-0x000003ffe1400000       692K PTE RW NX
    0x000003ffe1400000-0x000003ffe1500000         1M PMD RW NX
    0x000003ffe1500000-0x000003ffe1700000         2M PTE RW NX
    0x000003ffe1700000-0x000003ffe1800000         1M PMD RW NX
    0x000003ffe1800000-0x000003ffe187e000       504K PTE RW NX
    ---[ Kernel Image End ]---
    
    Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
sched: sch_cake: fix bulk flow accounting logic for host fairness [+ + +]
Author: Toke Høiland-Jørgensen <toke@redhat.com>
Date:   Tue Sep 3 18:08:45 2024 +0200

    sched: sch_cake: fix bulk flow accounting logic for host fairness
    
    commit 546ea84d07e3e324644025e2aae2d12ea4c5896e upstream.
    
    In sch_cake, we keep track of the count of active bulk flows per host,
    when running in dst/src host fairness mode, which is used as the
    round-robin weight when iterating through flows. The count of active
    bulk flows is updated whenever a flow changes state.
    
    This has a peculiar interaction with the hash collision handling: when a
    hash collision occurs (after the set-associative hashing), the state of
    the hash bucket is simply updated to match the new packet that collided,
    and if host fairness is enabled, that also means assigning new per-host
    state to the flow. For this reason, the bulk flow counters of the
    host(s) assigned to the flow are decremented, before new state is
    assigned (and the counters, which may not belong to the same host
    anymore, are incremented again).
    
    Back when this code was introduced, the host fairness mode was always
    enabled, so the decrement was unconditional. When the configuration
    flags were introduced the *increment* was made conditional, but
    the *decrement* was not. Which of course can lead to a spurious
    decrement (and associated wrap-around to U16_MAX).
    
    AFAICT, when host fairness is disabled, the decrement and wrap-around
    happens as soon as a hash collision occurs (which is not that common in
    itself, due to the set-associative hashing). However, in most cases this
    is harmless, as the value is only used when host fairness mode is
    enabled. So in order to trigger an array overflow, sch_cake has to first
    be configured with host fairness disabled, and while running in this
    mode, a hash collision has to occur to cause the overflow. Then, the
    qdisc has to be reconfigured to enable host fairness, which leads to the
    array out-of-bounds because the wrapped-around value is retained and
    used as an array index. It seems that syzbot managed to trigger this,
    which is quite impressive in its own right.
    
    This patch fixes the issue by introducing the same conditional check on
    decrement as is used on increment.
    
    The original bug predates the upstreaming of cake, but the commit listed
    in the Fixes tag touched that code, meaning that this patch won't apply
    before that.
    
    Fixes: 712639929912 ("sch_cake: Make the dual modes fairer")
    Reported-by: syzbot+7fe7b81d602cc1e6b94d@syzkaller.appspotmail.com
    Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Link: https://patch.msgid.link/20240903160846.20909-1-toke@redhat.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    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>

 
staging: iio: frequency: ad9834: Validate frequency parameter value [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Wed Jul 3 18:45:06 2024 +0300

    staging: iio: frequency: ad9834: Validate frequency parameter value
    
    commit b48aa991758999d4e8f9296c5bbe388f293ef465 upstream.
    
    In ad9834_write_frequency() clk_get_rate() can return 0. In such case
    ad9834_calc_freqreg() call will lead to division by zero. Checking
    'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0.
    ad9834_write_frequency() is called from ad9834_write(), where fout is
    taken from text buffer, which can contain any value.
    
    Modify parameters checking.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 12b9d5bf76bf ("Staging: IIO: DDS: AD9833 / AD9834 driver")
    Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://patch.msgid.link/20240703154506.25584-1-amishin@t-argos.ru
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tcp_bpf: fix return value of tcp_bpf_sendmsg() [+ + +]
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Tue Aug 20 20:07:44 2024 -0700

    tcp_bpf: fix return value of tcp_bpf_sendmsg()
    
    [ Upstream commit fe1910f9337bd46a9343967b547ccab26b4b2c6e ]
    
    When we cork messages in psock->cork, the last message triggers the
    flushing will result in sending a sk_msg larger than the current
    message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes
    negative at least in the following case:
    
    468         case __SK_DROP:
    469         default:
    470                 sk_msg_free_partial(sk, msg, tosend);
    471                 sk_msg_apply_bytes(psock, tosend);
    472                 *copied -= (tosend + delta); // <==== HERE
    473                 return -EACCES;
    
    Therefore, it could lead to the following BUG with a proper value of
    'copied' (thanks to syzbot). We should not use negative 'copied' as a
    return value here.
    
      ------------[ cut here ]------------
      kernel BUG at net/socket.c:733!
      Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0
      Hardware name: linux,dummy-virt (DT)
      pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
      pc : sock_sendmsg_nosec net/socket.c:733 [inline]
      pc : sock_sendmsg_nosec net/socket.c:728 [inline]
      pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745
      lr : sock_sendmsg_nosec net/socket.c:730 [inline]
      lr : __sock_sendmsg+0x54/0x60 net/socket.c:745
      sp : ffff800088ea3b30
      x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000
      x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000
      x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90
      x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001
      x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf
      x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
      x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0
      x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000
      x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900
      x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef
      Call trace:
       sock_sendmsg_nosec net/socket.c:733 [inline]
       __sock_sendmsg+0x5c/0x60 net/socket.c:745
       ____sys_sendmsg+0x274/0x2ac net/socket.c:2597
       ___sys_sendmsg+0xac/0x100 net/socket.c:2651
       __sys_sendmsg+0x84/0xe0 net/socket.c:2680
       __do_sys_sendmsg net/socket.c:2689 [inline]
       __se_sys_sendmsg net/socket.c:2687 [inline]
       __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687
       __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
       invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49
       el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132
       do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151
       el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712
       el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730
       el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598
      Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000)
      ---[ end trace 0000000000000000 ]---
    
    Fixes: 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data")
    Reported-by: syzbot+58c03971700330ce14d8@syzkaller.appspotmail.com
    Cc: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://patch.msgid.link/20240821030744.320934-1-xiyou.wangcong@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@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()
    
    commit 49aa8a1f4d6800721c7971ed383078257f12e8f9 upstream.
    
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
udp: fix receiving fraglist GSO packets [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Mon Aug 19 17:06:21 2024 +0200

    udp: fix receiving fraglist GSO packets
    
    commit b128ed5ab27330deeeaf51ea8bb69f1442a96f7f upstream.
    
    When assembling fraglist GSO packets, udp4_gro_complete does not set
    skb->csum_start, which makes the extra validation in __udp_gso_segment fail.
    
    Fixes: 89add40066f9 ("net: drop bad gso csum_start and offset in virtio_net_hdr")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://patch.msgid.link/20240819150621.59833-1-nbd@nbd.name
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    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: core: update LC timer as per USB Spec V3.2 [+ + +]
Author: Faisal Hassan <quic_faisalh@quicinc.com>
Date:   Thu Aug 29 15:15:02 2024 +0530

    usb: dwc3: core: update LC timer as per USB Spec V3.2
    
    commit 9149c9b0c7e046273141e41eebd8a517416144ac upstream.
    
    This fix addresses STAR 9001285599, which only affects DWC_usb3 version
    3.20a. The timer value for PM_LC_TIMER in DWC_usb3 3.20a for the Link
    ECN changes is incorrect. If the PM TIMER ECN is enabled via GUCTL2[19],
    the link compliance test (TD7.21) may fail. If the ECN is not enabled
    (GUCTL2[19] = 0), the controller will use the old timer value (5us),
    which is still acceptable for the link compliance test. Therefore, clear
    GUCTL2[19] to pass the USB link compliance test: TD 7.21.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Faisal Hassan <quic_faisalh@quicinc.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240829094502.26502-1-quic_faisalh@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: ucsi: Fix null pointer dereference in trace [+ + +]
Author: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Date:   Fri May 10 20:12:41 2024 +0000

    usb: typec: ucsi: Fix null pointer dereference in trace
    
    [ Upstream commit 99516f76db48e1a9d54cdfed63c1babcee4e71a5 ]
    
    ucsi_register_altmode checks IS_ERR for the alt pointer and treats
    NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,
    ucsi_register_displayport returns NULL which causes a NULL pointer
    dereference in trace. Rather than return NULL, call
    typec_port_register_altmode to register DisplayPort alternate mode
    as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.
    
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
    Signed-off-by: Jameson Thies <jthies@google.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240510201244.2968152-2-jthies@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: uas: set host status byte on data completion error [+ + +]
Author: Shantanu Goel <sgoel01@yahoo.com>
Date:   Thu Jun 6 23:32:57 2024 -0400

    usb: uas: set host status byte on data completion error
    
    [ Upstream commit 9d32685a251a754f1823d287df233716aa23bcb9 ]
    
    Set the host status byte when a data completion error is encountered
    otherwise the upper layer may end up using the invalid zero'ed data.
    The following output was observed from scsi/sd.c prior to this fix.
    
    [   11.872824] sd 0:0:0:1: [sdf] tag#9 data cmplt err -75 uas-tag 1 inflight:
    [   11.872826] sd 0:0:0:1: [sdf] tag#9 CDB: Read capacity(16) 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
    [   11.872830] sd 0:0:0:1: [sdf] Sector size 0 reported, assuming 512.
    
    Signed-off-by: Shantanu Goel <sgoel01@yahoo.com>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/87msnx4ec6.fsf@yahoo.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    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 v6.6.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: cfg80211: make hash table duplicates more survivable [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jun 7 20:17:17 2024 +0200

    wifi: cfg80211: make hash table duplicates more survivable
    
    [ Upstream commit 7f12e26a194d0043441f870708093d9c2c3bad7d ]
    
    Jiazi Li reported that they occasionally see hash table duplicates
    as evidenced by the WARN_ON() in rb_insert_bss() in this code.  It
    isn't clear how that happens, nor have I been able to reproduce it,
    but if it does happen, the kernel crashes later, when it tries to
    unhash the entry that's now not hashed.
    
    Try to make this situation more survivable by removing the BSS from
    the list(s) as well, that way it's fully leaked here (as had been
    the intent in the hash insert error path), and no longer reachable
    through the list(s) so it shouldn't be unhashed again later.
    
    Link: https://lore.kernel.org/r/20231026013528.GA24122@Jiazi.Li
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Link: https://msgid.link/20240607181726.36835-2-johannes@sipsolutions.net
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: remove fw_running op [+ + +]
Author: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Date:   Fri May 10 17:06:40 2024 +0300

    wifi: iwlwifi: remove fw_running op
    
    [ Upstream commit 37733bffda3285d18bd1d72c14b3a1cf39c56a5e ]
    
    fw_running assumes that memory can be retrieved only after alive.
    This assumption is no longer true as we support dump before alive.
    To avoid invalid access to the NIC, check that STATUS_DEVICE_ENABLED
    bit in trans status is set before dumping instead of the prior check.
    
    Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
    Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240510170500.ca07138cedeb.I090e31d3eaeb4ba19f5f84aba997ccd36927e9ac@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.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>

 
workqueue: Improve scalability of workqueue watchdog touch [+ + +]
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue Jun 25 21:42:45 2024 +1000

    workqueue: Improve scalability of workqueue watchdog touch
    
    [ Upstream commit 98f887f820c993e05a12e8aa816c80b8661d4c87 ]
    
    On a ~2000 CPU powerpc system, hard lockups have been observed in the
    workqueue code when stop_machine runs (in this case due to CPU hotplug).
    This is due to lots of CPUs spinning in multi_cpu_stop, calling
    touch_nmi_watchdog() which ends up calling wq_watchdog_touch().
    wq_watchdog_touch() writes to the global variable wq_watchdog_touched,
    and that can find itself in the same cacheline as other important
    workqueue data, which slows down operations to the point of lockups.
    
    In the case of the following abridged trace, worker_pool_idr was in
    the hot line, causing the lockups to always appear at idr_find.
    
      watchdog: CPU 1125 self-detected hard LOCKUP @ idr_find
      Call Trace:
      get_work_pool
      __queue_work
      call_timer_fn
      run_timer_softirq
      __do_softirq
      do_softirq_own_stack
      irq_exit
      timer_interrupt
      decrementer_common_virt
      * interrupt: 900 (timer) at multi_cpu_stop
      multi_cpu_stop
      cpu_stopper_thread
      smpboot_thread_fn
      kthread
    
    Fix this by having wq_watchdog_touch() only write to the line if the
    last time a touch was recorded exceeds 1/4 of the watchdog threshold.
    
    Reported-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

workqueue: wq_watchdog_touch is always called with valid CPU [+ + +]
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Tue Jun 25 21:42:44 2024 +1000

    workqueue: wq_watchdog_touch is always called with valid CPU
    
    [ Upstream commit 18e24deb1cc92f2068ce7434a94233741fbd7771 ]
    
    Warn in the case it is called with cpu == -1. This does not appear
    to happen anywhere.
    
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/mm: Fix PTI for i386 some more [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Aug 6 20:48:43 2024 +0200

    x86/mm: Fix PTI for i386 some more
    
    commit c48b5a4cf3125adb679e28ef093f66ff81368d05 upstream.
    
    So it turns out that we have to do two passes of
    pti_clone_entry_text(), once before initcalls, such that device and
    late initcalls can use user-mode-helper / modprobe and once after
    free_initmem() / mark_readonly().
    
    Now obviously mark_readonly() can cause PMD splits, and
    pti_clone_pgtable() doesn't like that much.
    
    Allow the late clone to split PMDs so that pagetables stay in sync.
    
    [peterz: Changelog and comments]
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lkml.kernel.org/r/20240806184843.GX37996@noisy.programming.kicks-ass.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>