Changelog in Linux kernel 6.6.51

 
accel/habanalabs/gaudi2: unsecure edma max outstanding register [+ + +]
Author: Rakesh Ughreja <rughreja@habana.ai>
Date:   Tue Mar 26 08:01:02 2024 +0200

    accel/habanalabs/gaudi2: unsecure edma max outstanding register
    
    [ Upstream commit 3309887c6ff8ca2ac05a74e1ee5d1c44829f63f2 ]
    
    Netowrk EDMAs uses more outstanding transfers so this needs to be
    programmed by EDMA firmware.
    
    Signed-off-by: Rakesh Ughreja <rughreja@habana.ai>
    Reviewed-by: Ofir Bitton <obitton@habana.ai>
    Signed-off-by: Ofir Bitton <obitton@habana.ai>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ACPI: CPPC: Add helper to get the highest performance value [+ + +]
Author: Meng Li <li.meng@amd.com>
Date:   Fri Jan 19 17:04:57 2024 +0800

    ACPI: CPPC: Add helper to get the highest performance value
    
    commit 12753d71e8c5c3e716cedba23ddeed508da0bdc4 upstream.
    
    Add support for getting the highest performance to the
    generic CPPC driver. This enables downstream drivers
    such as amd-pstate to discover and use these values.
    
    Refer to Chapter 8.4.6.1.1.1. Highest Performance of ACPI
    Specification 6.5 for details on continuous performance control
    of CPPC (linked below).
    
    Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Wyes Karny <wyes.karny@amd.com>
    Reviewed-by: Perry Yuan <perry.yuan@amd.com>
    Acked-by: Huang Rui <ray.huang@amd.com>
    Signed-off-by: Meng Li <li.meng@amd.com>
    Link: https://uefi.org/specs/ACPI/6.5/08_Processor_Configuration_and_Control.html?highlight=cppc#highest-performance
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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: control: Apply sanity check of input values for user elements [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Jun 16 09:34:44 2024 +0200

    ALSA: control: Apply sanity check of input values for user elements
    
    [ Upstream commit 50ed081284fe2bfd1f25e8b92f4f6a4990e73c0a ]
    
    Although we have already a mechanism for sanity checks of input values
    for control writes, it's not applied unless the kconfig
    CONFIG_SND_CTL_INPUT_VALIDATION is set due to the performance reason.
    Nevertheless, it still makes sense to apply the same check for user
    elements despite of its cost, as that's the only way to filter out the
    invalid values; the user controls are handled solely in ALSA core
    code, and there is no corresponding driver, after all.
    
    This patch adds the same input value validation for user control
    elements at its put callback.  The kselftest will be happier with this
    change, as the incorrect values will be bailed out now with errors.
    
    For other normal controls, the check is applied still only when
    CONFIG_SND_CTL_INPUT_VALIDATION is set.
    
    Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Closes: https://lore.kernel.org/r/1d44be36-9bb9-4d82-8953-5ae2a4f09405@molgen.mpg.de
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/20240616073454.16512-4-tiwai@suse.de
    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/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>

 
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: SOF: topology: Clear SOF link platform name upon unload [+ + +]
Author: Chen-Yu Tsai <wenst@chromium.org>
Date:   Wed Aug 21 12:10:04 2024 +0800

    ASoc: SOF: topology: Clear SOF link platform name upon unload
    
    [ Upstream commit e0be875c5bf03a9676a6bfed9e0f1766922a7dbd ]
    
    The SOF topology loading function sets the device name for the platform
    component link. This should be unset when unloading the topology,
    otherwise a machine driver unbind/bind or reprobe would complain about
    an invalid component as having both its component name and of_node set:
    
        mt8186_mt6366 sound: ASoC: Both Component name/of_node are set for AFE_SOF_DL1
        mt8186_mt6366 sound: error -EINVAL: Cannot register card
        mt8186_mt6366 sound: probe with driver mt8186_mt6366 failed with error -22
    
    This happens with machine drivers that set the of_node separately.
    
    Clear the SOF link platform name in the topology unload callback.
    
    Fixes: 311ce4fe7637 ("ASoC: SOF: Add support for loading topologies")
    Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://patch.msgid.link/20240821041006.2618855-1-wenst@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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: TAS2781: replace beXX_to_cpup with get_unaligned_beXX for potentially broken alignment [+ + +]
Author: Shenghao Ding <shenghao-ding@ti.com>
Date:   Sun Jul 7 16:30:07 2024 +0800

    ASoc: TAS2781: replace beXX_to_cpup with get_unaligned_beXX for potentially broken alignment
    
    [ Upstream commit 1cc509edbe23b61e8c245611bd15d88edb635a38 ]
    
    Use get_unaligned_be16 instead of be16_to_cpup and get_unaligned_be32
    instead of be32_to_cpup for potentially broken alignment.
    
    Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
    Link: https://patch.msgid.link/20240707083011.98-1-shenghao-ding@ti.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: tegra: Fix CBB error during probe() [+ + +]
Author: Mohan Kumar <mkumard@nvidia.com>
Date:   Fri Aug 23 14:43:42 2024 +0000

    ASoC: tegra: Fix CBB error during probe()
    
    [ Upstream commit 6781b962d97bc52715a8db8cc17278cc3c23ebe8 ]
    
    When Tegra audio drivers are built as part of the kernel image,
    TIMEOUT_ERR is observed from cbb-fabric. Following is seen on
    Jetson AGX Orin during boot:
    
    [    8.012482] **************************************
    [    8.017423] CPU:0, Error:cbb-fabric, Errmon:2
    [    8.021922]    Error Code            : TIMEOUT_ERR
    [    8.025966]    Overflow              : Multiple TIMEOUT_ERR
    [    8.030644]
    [    8.032175]    Error Code            : TIMEOUT_ERR
    [    8.036217]    MASTER_ID             : CCPLEX
    [    8.039722]    Address               : 0x290a0a8
    [    8.043318]    Cache                 : 0x1 -- Bufferable
    [    8.047630]    Protection            : 0x2 -- Unprivileged, Non-Secure, Data Access
    [    8.054628]    Access_Type           : Write
    
    [    8.106130] WARNING: CPU: 0 PID: 124 at drivers/soc/tegra/cbb/tegra234-cbb.c:604 tegra234_cbb_isr+0x134/0x178
    
    [    8.240602] Call trace:
    [    8.243126]  tegra234_cbb_isr+0x134/0x178
    [    8.247261]  __handle_irq_event_percpu+0x60/0x238
    [    8.252132]  handle_irq_event+0x54/0xb8
    
    These errors happen when MVC device, which is a child of AHUB
    device, tries to access its device registers. This happens as
    part of call tegra210_mvc_reset_vol_settings() in MVC device
    probe().
    
    The root cause of this problem is, the child MVC device gets
    probed before the AHUB clock gets enabled. The AHUB clock is
    enabled in runtime PM resume of parent AHUB device and due to
    the wrong sequence of pm_runtime_enable() in AHUB driver,
    runtime PM resume doesn't happen for AHUB device when MVC makes
    register access.
    
    Fix this by calling pm_runtime_enable() for parent AHUB device
    before of_platform_populate() in AHUB driver. This ensures that
    clock becomes available when MVC makes register access.
    
    Fixes: 16e1bcc2caf4 ("ASoC: tegra: Add Tegra210 based AHUB driver")
    Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
    Signed-off-by: Ritu Chaudhary <rituc@nvidia.com>
    Signed-off-by: Sameer Pujar <spujar@nvidia.com>
    Link: https://patch.msgid.link/20240823144342.4123814-3-spujar@nvidia.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-scsi: Check ATA_QCFLAG_RTF_FILLED before using result_tf [+ + +]
Author: Igor Pylypiv <ipylypiv@google.com>
Date:   Tue Jul 2 02:47:35 2024 +0000

    ata: libata-scsi: Check ATA_QCFLAG_RTF_FILLED before using result_tf
    
    [ Upstream commit 816be86c7993d3c5832c3017c0056297e86f978c ]
    
    qc->result_tf contents are only valid when the ATA_QCFLAG_RTF_FILLED flag
    is set. The ATA_QCFLAG_RTF_FILLED flag should be always set for commands
    that failed or for commands that have the ATA_QCFLAG_RESULT_TF flag set.
    
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
    Link: https://lore.kernel.org/r/20240702024735.1152293-8-ipylypiv@google.com
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ata: libata-scsi: Remove redundant sense_buffer memsets [+ + +]
Author: Igor Pylypiv <ipylypiv@google.com>
Date:   Tue Jul 2 02:47:32 2024 +0000

    ata: libata-scsi: Remove redundant sense_buffer memsets
    
    [ Upstream commit 3f6d903b54a137e9e438d9c3b774b5d0432917bc ]
    
    SCSI layer clears sense_buffer in scsi_queue_rq() so there is no need for
    libata to clear it again.
    
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
    Link: https://lore.kernel.org/r/20240702024735.1152293-5-ipylypiv@google.com
    Signed-off-by: Niklas Cassel <cassel@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>

 
Bluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush() [+ + +]
Author: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Date:   Wed May 15 12:36:55 2024 +0530

    Bluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush()
    
    [ Upstream commit c68bbf5e334b35b36ac5b9f0419f1f93f796bad1 ]
    
    This adds a check before freeing the rx->skb in flush and close
    functions to handle the kernel crash seen while removing driver after FW
    download fails or before FW download completes.
    
    dmesg log:
    [   54.634586] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
    [   54.643398] Mem abort info:
    [   54.646204]   ESR = 0x0000000096000004
    [   54.649964]   EC = 0x25: DABT (current EL), IL = 32 bits
    [   54.655286]   SET = 0, FnV = 0
    [   54.658348]   EA = 0, S1PTW = 0
    [   54.661498]   FSC = 0x04: level 0 translation fault
    [   54.666391] Data abort info:
    [   54.669273]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
    [   54.674768]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    [   54.674771]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    [   54.674775] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048860000
    [   54.674780] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000
    [   54.703880] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
    [   54.710152] Modules linked in: btnxpuart(-) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_micfil snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma gpio_ir_recv rc_core sch_fq_codel fuse
    [   54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 Not tainted 6.6.3-otbr-g128004619037 #2
    [   54.744364] Hardware name: FSL i.MX8MM EVK board (DT)
    [   54.744368] Workqueue: hci0 hci_power_on
    [   54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   54.757249] pc : kfree_skb_reason+0x18/0xb0
    [   54.772299] lr : btnxpuart_flush+0x40/0x58 [btnxpuart]
    [   54.782921] sp : ffff8000805ebca0
    [   54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000
    [   54.782931] x26: ffff377b84852400 x25: ffff377b848523c0 x24: ffff377b845e7230
    [   54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92
    [   54.782945] x20: ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff
    [   54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857
    [   54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642
    [   54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9 : ffffa5c6cf19d688
    [   54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000
    [   54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000
    [   54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac
    [   54.857599] Call trace:
    [   54.857601]  kfree_skb_reason+0x18/0xb0
    [   54.863878]  btnxpuart_flush+0x40/0x58 [btnxpuart]
    [   54.863888]  hci_dev_open_sync+0x3a8/0xa04
    [   54.872773]  hci_power_on+0x54/0x2e4
    [   54.881832]  process_one_work+0x138/0x260
    [   54.881842]  worker_thread+0x32c/0x438
    [   54.881847]  kthread+0x118/0x11c
    [   54.881853]  ret_from_fork+0x10/0x20
    [   54.896406] Code: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400)
    [   54.896410] ---[ end trace 0000000000000000 ]---
    
    Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
    Tested-by: Guillaume Legoupil <guillaume.legoupil@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_conn: Fix UAF Write in __hci_acl_create_connection_sync [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Feb 9 09:08:06 2024 -0500

    Bluetooth: hci_conn: Fix UAF Write in __hci_acl_create_connection_sync
    
    [ Upstream commit 5f641f03abccddd1a37233ff1b8e774b9ff1f4e8 ]
    
    This fixes the UAF on __hci_acl_create_connection_sync caused by
    connection abortion, it uses the same logic as to LE_LINK which uses
    hci_cmd_sync_cancel to prevent the callback to run if the connection is
    abort prematurely.
    
    Reported-by: syzbot+3f0a39be7a2035700868@syzkaller.appspotmail.com
    Fixes: 45340097ce6e ("Bluetooth: hci_conn: Only do ACL connections sequentially")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 227a0cdf4a02 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_conn: Only do ACL connections sequentially [+ + +]
Author: Jonas Dreßler <verdre@v0yd.nl>
Date:   Tue Feb 6 12:08:13 2024 +0100

    Bluetooth: hci_conn: Only do ACL connections sequentially
    
    [ Upstream commit 45340097ce6ea7e875674a5a7d24c95ecbc93ef9 ]
    
    Pretty much all bluetooth chipsets only support paging a single device at
    a time, and if they don't reject a secondary "Create Connection" request
    while another is still ongoing, they'll most likely serialize those
    requests in the firware.
    
    With commit 4c67bc74f016 ("[Bluetooth] Support concurrent connect
    requests") we started adding some serialization of our own in case the
    adapter returns "Command Disallowed" HCI error.
    
    This commit was using the BT_CONNECT2 state for the serialization, this
    state is also used for a few more things (most notably to indicate we're
    waiting for an inquiry to cancel) and therefore a bit unreliable. Also
    not all BT firwares would respond with "Command Disallowed" on too many
    connection requests, some will also respond with "Hardware Failure"
    (BCM4378), and others will error out later and send a "Connect Complete"
    event with error "Rejected Limited Resources" (Marvell 88W8897).
    
    We can clean things up a bit and also make the serialization more reliable
    by using our hci_sync machinery to always do "Create Connection" requests
    in a sequential manner.
    
    This is very similar to what we're already doing for establishing LE
    connections, and it works well there.
    
    Note that this causes a test failure in mgmt-tester (test "Pair Device
    - Power off 1") because the hci_abort_conn_sync() changes the error we
    return on timeout of the "Create Connection". We'll fix this on the
    mgmt-tester side by adjusting the expected error for the test.
    
    Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 227a0cdf4a02 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_event: Use HCI error defines instead of magic values [+ + +]
Author: Jonas Dreßler <verdre@v0yd.nl>
Date:   Mon Jan 8 23:46:07 2024 +0100

    Bluetooth: hci_event: Use HCI error defines instead of magic values
    
    [ Upstream commit 79c0868ad65a8fc7cdfaa5f2b77a4b70d0b0ea16 ]
    
    We have error defines already, so let's use them.
    
    Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 227a0cdf4a02 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: Add helper functions to manipulate cmd_sync queue [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Aug 9 13:43:53 2023 -0700

    Bluetooth: hci_sync: Add helper functions to manipulate cmd_sync queue
    
    [ Upstream commit 505ea2b295929e7be2b4e1bc86ee31cb7862fb01 ]
    
    This adds functions to queue, dequeue and lookup into the cmd_sync
    list.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 227a0cdf4a02 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: Attempt to dequeue connection attempt [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Feb 13 09:59:32 2024 -0500

    Bluetooth: hci_sync: Attempt to dequeue connection attempt
    
    [ Upstream commit 881559af5f5c545f6828e7c74d79813eb886d523 ]
    
    If connection is still queued/pending in the cmd_sync queue it means no
    command has been generated and it should be safe to just dequeue the
    callback when it is being aborted.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 227a0cdf4a02 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: Fix UAF in hci_acl_create_conn_sync [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Mar 8 11:02:48 2024 -0500

    Bluetooth: hci_sync: Fix UAF in hci_acl_create_conn_sync
    
    commit 3d1c16e920c88eb5e583e1b4a10b95a5dc97ec22 upstream.
    
    This fixes the following error caused by hci_conn being freed while
    hcy_acl_create_conn_sync is pending:
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0xa7/0x2e0
    Write of size 2 at addr ffff888002ae0036 by task kworker/u3:0/848
    
    CPU: 0 PID: 848 Comm: kworker/u3:0 Not tainted 6.8.0-rc6-g2ab3e8d67fc1
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38
    04/01/2014
    Workqueue: hci0 hci_cmd_sync_work
    Call Trace:
     <TASK>
     dump_stack_lvl+0x21/0x70
     print_report+0xce/0x620
     ? preempt_count_sub+0x13/0xc0
     ? __virt_addr_valid+0x15f/0x310
     ? hci_acl_create_conn_sync+0xa7/0x2e0
     kasan_report+0xdf/0x110
     ? hci_acl_create_conn_sync+0xa7/0x2e0
     hci_acl_create_conn_sync+0xa7/0x2e0
     ? __pfx_hci_acl_create_conn_sync+0x10/0x10
     ? __pfx_lock_release+0x10/0x10
     ? __pfx_hci_acl_create_conn_sync+0x10/0x10
     hci_cmd_sync_work+0x138/0x1c0
     process_one_work+0x405/0x800
     ? __pfx_lock_acquire+0x10/0x10
     ? __pfx_process_one_work+0x10/0x10
     worker_thread+0x37b/0x670
     ? __pfx_worker_thread+0x10/0x10
     kthread+0x19b/0x1e0
     ? kthread+0xfe/0x1e0
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x2f/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    Allocated by task 847:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     __kasan_kmalloc+0x8f/0xa0
     hci_conn_add+0xc6/0x970
     hci_connect_acl+0x309/0x410
     pair_device+0x4fb/0x710
     hci_sock_sendmsg+0x933/0xef0
     sock_write_iter+0x2c3/0x2d0
     do_iter_readv_writev+0x21a/0x2e0
     vfs_writev+0x21c/0x7b0
     do_writev+0x14a/0x180
     do_syscall_64+0x77/0x150
     entry_SYSCALL_64_after_hwframe+0x6c/0x74
    
    Freed by task 847:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     kasan_save_free_info+0x3b/0x60
     __kasan_slab_free+0xfa/0x150
     kfree+0xcb/0x250
     device_release+0x58/0xf0
     kobject_put+0xbb/0x160
     hci_conn_del+0x281/0x570
     hci_conn_hash_flush+0xfc/0x130
     hci_dev_close_sync+0x336/0x960
     hci_dev_close+0x10e/0x140
     hci_sock_ioctl+0x14a/0x5c0
     sock_ioctl+0x58a/0x5d0
     __x64_sys_ioctl+0x480/0xf60
     do_syscall_64+0x77/0x150
     entry_SYSCALL_64_after_hwframe+0x6c/0x74
    
    Fixes: 45340097ce6e ("Bluetooth: hci_conn: Only do ACL connections sequentially")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_sync: Fix UAF on create_le_conn_complete [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Feb 20 13:10:47 2024 -0500

    Bluetooth: hci_sync: Fix UAF on create_le_conn_complete
    
    commit f7cbce60a38a6589f0dade720d4c2544959ecc0e upstream.
    
    While waiting for hci_dev_lock the hci_conn object may be cleanup
    causing the following trace:
    
    BUG: KASAN: slab-use-after-free in hci_connect_le_scan_cleanup+0x29/0x350
    Read of size 8 at addr ffff888001a50a30 by task kworker/u3:1/111
    
    CPU: 0 PID: 111 Comm: kworker/u3:1 Not tainted
    6.8.0-rc2-00701-g8179b15ab3fd-dirty #6418
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38
    04/01/2014
    Workqueue: hci0 hci_cmd_sync_work
    Call Trace:
     <TASK>
     dump_stack_lvl+0x21/0x70
     print_report+0xce/0x620
     ? preempt_count_sub+0x13/0xc0
     ? __virt_addr_valid+0x15f/0x310
     ? hci_connect_le_scan_cleanup+0x29/0x350
     kasan_report+0xdf/0x110
     ? hci_connect_le_scan_cleanup+0x29/0x350
     hci_connect_le_scan_cleanup+0x29/0x350
     create_le_conn_complete+0x25c/0x2c0
    
    Fixes: 881559af5f5c ("Bluetooth: hci_sync: Attempt to dequeue connection attempt")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Feb 16 15:29:55 2024 -0500

    Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync
    
    commit 7453847fb22c7c45334c43cc6a02ea5df5b9961d upstream.
    
    Fixes the following trace where hci_acl_create_conn_sync attempts to
    call hci_abort_conn_sync after timeout:
    
    BUG: KASAN: slab-use-after-free in hci_abort_conn_sync
    (net/bluetooth/hci_sync.c:5439)
    Read of size 2 at addr ffff88800322c032 by task kworker/u3:2/36
    
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38
    04/01/2014
    Workqueue: hci0 hci_cmd_sync_work
    Call Trace:
    <TASK>
    dump_stack_lvl (./arch/x86/include/asm/irqflags.h:26
    ./arch/x86/include/asm/irqflags.h:67 ./arch/x86/include/asm/irqflags.h:127
    lib/dump_stack.c:107)
    print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
    ? preempt_count_sub (kernel/sched/core.c:5889)
    ? __virt_addr_valid (./arch/x86/include/asm/preempt.h:103 (discriminator 1)
    ./include/linux/rcupdate.h:865 (discriminator 1)
    ./include/linux/mmzone.h:2026 (discriminator 1)
    arch/x86/mm/physaddr.c:65 (discriminator 1))
    ? hci_abort_conn_sync (net/bluetooth/hci_sync.c:5439)
    kasan_report (mm/kasan/report.c:603)
    ? hci_abort_conn_sync (net/bluetooth/hci_sync.c:5439)
    hci_abort_conn_sync (net/bluetooth/hci_sync.c:5439)
    ? __pfx_hci_abort_conn_sync (net/bluetooth/hci_sync.c:5433)
    hci_acl_create_conn_sync (net/bluetooth/hci_sync.c:6681)
    
    Fixes: 45340097ce6e ("Bluetooth: hci_conn: Only do ACL connections sequentially")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_sync: Introduce hci_cmd_sync_run/hci_cmd_sync_run_once [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Aug 26 15:47:30 2024 -0400

    Bluetooth: hci_sync: Introduce hci_cmd_sync_run/hci_cmd_sync_run_once
    
    [ Upstream commit c898f6d7b093bd71e66569cd6797c87d4056f44b ]
    
    This introduces hci_cmd_sync_run/hci_cmd_sync_run_once which acts like
    hci_cmd_sync_queue/hci_cmd_sync_queue_once but runs immediately when
    already on hdev->cmd_sync_work context.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 227a0cdf4a02 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Aug 26 16:14:04 2024 -0400

    Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT
    
    [ Upstream commit 227a0cdf4a028a73dc256d0f5144b4808d718893 ]
    
    MGMT_OP_DISCONNECT can be called while mgmt_device_connected has not
    been called yet, which will cause the connection procedure to be
    aborted, so mgmt_device_disconnected shall still respond with command
    complete to MGMT_OP_DISCONNECT and just not emit
    MGMT_EV_DEVICE_DISCONNECTED since MGMT_EV_DEVICE_CONNECTED was never
    sent.
    
    To fix this MGMT_OP_DISCONNECT is changed to work similarly to other
    command which do use hci_cmd_sync_queue and then use hci_conn_abort to
    disconnect and returns the result, in order for hci_conn_abort to be
    used from hci_cmd_sync context it now uses hci_cmd_sync_run_once.
    
    Link: https://github.com/bluez/bluez/issues/932
    Fixes: 12d4a3b2ccb3 ("Bluetooth: Move check for MGMT_CONNECTED flag into mgmt.c")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    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>

Bluetooth: qca: If memdump doesn't work, re-enable IBS [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Wed Aug 21 15:43:40 2024 -0700

    Bluetooth: qca: If memdump doesn't work, re-enable IBS
    
    [ Upstream commit 8ae22de9d2eae3c432de64bf2b3a5a69cf1d1124 ]
    
    On systems in the field, we are seeing this sometimes in the kernel logs:
      Bluetooth: qca_controller_memdump() hci0: hci_devcd_init Return:-95
    
    This means that _something_ decided that it wanted to get a memdump
    but then hci_devcd_init() returned -EOPNOTSUPP (AKA -95).
    
    The cleanup code in qca_controller_memdump() when we get back an error
    from hci_devcd_init() undoes most things but forgets to clear
    QCA_IBS_DISABLED. One side effect of this is that, during the next
    suspend, qca_suspend() will always get a timeout.
    
    Let's fix it so that we clear the bit.
    
    Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support")
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: Remove pending ACL connection attempts [+ + +]
Author: Jonas Dreßler <verdre@v0yd.nl>
Date:   Tue Feb 6 12:08:14 2024 +0100

    Bluetooth: Remove pending ACL connection attempts
    
    [ Upstream commit 4aa42119d971603dc9e4d8cf4f53d5fcf082ea7d ]
    
    With the last commit we moved to using the hci_sync queue for "Create
    Connection" requests, removing the need for retrying the paging after
    finished/failed "Create Connection" requests and after the end of
    inquiries.
    
    hci_conn_check_pending() was used to trigger this retry, we can remove it
    now.
    
    Note that we can also remove the special handling for COMMAND_DISALLOWED
    errors in the completion handler of "Create Connection", because "Create
    Connection" requests are now always serialized.
    
    This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support
    concurrent connect requests").
    
    With this, the BT_CONNECT2 state of ACL hci_conn objects should now be
    back to meaning only one thing: That we received a "Connection Request"
    from another device (see hci_conn_request_evt), but the response to that
    is going to be deferred.
    
    Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 227a0cdf4a02 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, net: Fix a potential race in do_sock_getsockopt() [+ + +]
Author: Tze-nan Wu <Tze-nan.Wu@mediatek.com>
Date:   Fri Aug 30 16:25:17 2024 +0800

    bpf, net: Fix a potential race in do_sock_getsockopt()
    
    [ Upstream commit 33f339a1ba54e56bba57ee9a77c71e385ab4825c ]
    
    There's a potential race when `cgroup_bpf_enabled(CGROUP_GETSOCKOPT)` is
    false during the execution of `BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN`, but
    becomes true when `BPF_CGROUP_RUN_PROG_GETSOCKOPT` is called.
    This inconsistency can lead to `BPF_CGROUP_RUN_PROG_GETSOCKOPT` receiving
    an "-EFAULT" from `__cgroup_bpf_run_filter_getsockopt(max_optlen=0)`.
    Scenario shown as below:
    
               `process A`                      `process B`
               -----------                      ------------
      BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN
                                                enable CGROUP_GETSOCKOPT
      BPF_CGROUP_RUN_PROG_GETSOCKOPT (-EFAULT)
    
    To resolve this, remove the `BPF_CGROUP_GETSOCKOPT_MAX_OPTLEN` macro and
    directly uses `copy_from_sockptr` to ensure that `max_optlen` is always
    set before `BPF_CGROUP_RUN_PROG_GETSOCKOPT` is invoked.
    
    Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
    Co-developed-by: Yanghui Li <yanghui.li@mediatek.com>
    Signed-off-by: Yanghui Li <yanghui.li@mediatek.com>
    Co-developed-by: Cheng-Jui Wang <cheng-jui.wang@mediatek.com>
    Signed-off-by: Cheng-Jui Wang <cheng-jui.wang@mediatek.com>
    Signed-off-by: Tze-nan Wu <Tze-nan.Wu@mediatek.com>
    Acked-by: Stanislav Fomichev <sdf@fomichev.me>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://patch.msgid.link/20240830082518.23243-1-Tze-nan.Wu@mediatek.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, verifier: Correct tail_call_reachable for bpf prog [+ + +]
Author: Leon Hwang <hffilwlqm@gmail.com>
Date:   Mon Jun 10 20:42:23 2024 +0800

    bpf, verifier: Correct tail_call_reachable for bpf prog
    
    [ Upstream commit 01793ed86b5d7df1e956520b5474940743eb7ed8 ]
    
    It's confusing to inspect 'prog->aux->tail_call_reachable' with drgn[0],
    when bpf prog has tail call but 'tail_call_reachable' is false.
    
    This patch corrects 'tail_call_reachable' when bpf prog has tail call.
    
    Signed-off-by: Leon Hwang <hffilwlqm@gmail.com>
    Link: https://lore.kernel.org/r/20240610124224.34673-2-hffilwlqm@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Add sockptr support for getsockopt [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Mon Oct 16 06:47:39 2023 -0700

    bpf: Add sockptr support for getsockopt
    
    [ Upstream commit a615f67e1a426f35366b8398c11f31c148e7df48 ]
    
    The whole network stack uses sockptr, and while it doesn't move to
    something more modern, let's use sockptr in getsockptr BPF hooks, so, it
    could be used by other callers.
    
    The main motivation for this change is to use it in the io_uring
    {g,s}etsockopt(), which will use a userspace pointer for *optval, but, a
    kernel value for optlen.
    
    Link: https://lore.kernel.org/all/ZSArfLaaGcfd8LH8@gmail.com/
    
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://lore.kernel.org/r/20231016134750.1381153-2-leitao@debian.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: 33f339a1ba54 ("bpf, net: Fix a potential race in do_sock_getsockopt()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Add sockptr support for setsockopt [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Mon Oct 16 06:47:40 2023 -0700

    bpf: Add sockptr support for setsockopt
    
    [ Upstream commit 3f31e0d14d44ad491a81b7c1f83f32fbc300a867 ]
    
    The whole network stack uses sockptr, and while it doesn't move to
    something more modern, let's use sockptr in setsockptr BPF hooks, so, it
    could be used by other callers.
    
    The main motivation for this change is to use it in the io_uring
    {g,s}etsockopt(), which will use a userspace pointer for *optval, but, a
    kernel value for optlen.
    
    Link: https://lore.kernel.org/all/ZSArfLaaGcfd8LH8@gmail.com/
    
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://lore.kernel.org/r/20231016134750.1381153-3-leitao@debian.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: 33f339a1ba54 ("bpf, net: Fix a potential race in do_sock_getsockopt()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

btrfs: 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: kvaser_pciefd: Move reset of DMA RX buffers to the end of the ISR [+ + +]
Author: Martin Jocic <martin.jocic@kvaser.com>
Date:   Thu Jun 20 20:13:19 2024 +0200

    can: kvaser_pciefd: Move reset of DMA RX buffers to the end of the ISR
    
    [ Upstream commit 48f827d4f48f5243e37b9240029ce3f456d1f490 ]
    
    A new interrupt is triggered by resetting the DMA RX buffers.
    Since MSI interrupts are faster than legacy interrupts, the reset
    of the DMA buffers must be moved to the very end of the ISR,
    otherwise a new MSI interrupt will be masked by the current one.
    
    Signed-off-by: Martin Jocic <martin.jocic@kvaser.com>
    Link: https://lore.kernel.org/all/20240620181320.235465-2-martin.jocic@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: dd885d90c047 ("can: kvaser_pciefd: Use a single write when releasing RX buffers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_pciefd: Remove unnecessary comment [+ + +]
Author: Martin Jocic <martin.jocic@kvaser.com>
Date:   Fri Jun 14 17:15:20 2024 +0200

    can: kvaser_pciefd: Remove unnecessary comment
    
    [ Upstream commit 11d186697ceb10b68c6a1fd505635346b1ccd055 ]
    
    The code speaks for itself.
    
    Signed-off-by: Martin Jocic <martin.jocic@kvaser.com>
    Link: https://lore.kernel.org/all/20240614151524.2718287-4-martin.jocic@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: dd885d90c047 ("can: kvaser_pciefd: Use a single write when releasing RX buffers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_pciefd: Rename board_irq to pci_irq [+ + +]
Author: Martin Jocic <martin.jocic@kvaser.com>
Date:   Fri Jun 14 17:15:23 2024 +0200

    can: kvaser_pciefd: Rename board_irq to pci_irq
    
    [ Upstream commit cbf88a6ba7bb6ce0d3131b119298f73bd7b18459 ]
    
    Rename the variable name board_irq in the ISR to pci_irq to
    be more specific and to match the macro by which it is read.
    
    Signed-off-by: Martin Jocic <martin.jocic@kvaser.com>
    Link: https://lore.kernel.org/all/20240614151524.2718287-7-martin.jocic@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: dd885d90c047 ("can: kvaser_pciefd: Use a single write when releasing RX buffers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_pciefd: Skip redundant NULL pointer check in ISR [+ + +]
Author: Martin Jocic <martin.jocic@kvaser.com>
Date:   Fri Jun 14 17:15:19 2024 +0200

    can: kvaser_pciefd: Skip redundant NULL pointer check in ISR
    
    [ Upstream commit ac765219c2c4e44f29063724c8d36435a3e61985 ]
    
    This check is already done at the creation of the net devices in
    kvaser_pciefd_setup_can_ctrls called from kvaser_pciefd_probe.
    
    If it fails, the driver won't load, so there should be no need to
    repeat the check inside the ISR. The number of channels is read
    from the FPGA and should be trusted.
    
    Signed-off-by: Martin Jocic <martin.jocic@kvaser.com>
    Link: https://lore.kernel.org/all/20240614151524.2718287-3-martin.jocic@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: dd885d90c047 ("can: kvaser_pciefd: Use a single write when releasing RX buffers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_pciefd: Use a single write when releasing RX buffers [+ + +]
Author: Martin Jocic <martin.jocic@kvaser.com>
Date:   Fri Aug 30 17:31:13 2024 +0200

    can: kvaser_pciefd: Use a single write when releasing RX buffers
    
    [ Upstream commit dd885d90c047dbdd2773c1d33954cbd8747d81e2 ]
    
    Kvaser's PCIe cards uses the KCAN FPGA IP block which has dual 4K
    buffers for incoming messages shared by all (currently up to eight)
    channels. While the driver processes messages in one buffer, new
    incoming messages are stored in the other and so on.
    
    The design of KCAN is such that a buffer must be fully read and then
    released. Releasing a buffer will make the FPGA switch buffers. If the
    other buffer contains at least one incoming message the FPGA will also
    instantly issue a new interrupt, if not the interrupt will be issued
    after receiving the first new message.
    
    With IRQx interrupts, it takes a little time for the interrupt to
    happen, enough for any previous ISR call to do it's business and
    return, but MSI interrupts are way faster so this time is reduced to
    almost nothing.
    
    So with MSI, releasing the buffer HAS to be the very last action of
    the ISR before returning, otherwise the new interrupt might be
    "masked" by the kernel because the previous ISR call hasn't returned.
    And the interrupts are edge-triggered so we cannot loose one, or the
    ping-pong reading process will stop.
    
    This is why this patch modifies the driver to use a single write to
    the SRB_CMD register before returning.
    
    Signed-off-by: Martin Jocic <martin.jocic@kvaser.com>
    Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Link: https://patch.msgid.link/20240830153113.2081440-1-martin.jocic@kvaser.com
    Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
    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>

can: mcp251xfd: clarify the meaning of timestamp [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Jan 11 11:48:16 2023 +0100

    can: mcp251xfd: clarify the meaning of timestamp
    
    [ Upstream commit e793c724b48ca8cae9693bc3be528e85284c126a ]
    
    The mcp251xfd chip is configured to provide a timestamp with each
    received and transmitted CAN frame. The timestamp is derived from the
    internal free-running timer, which can also be read from the TBC
    register via SPI. The timer is 32 bits wide and is clocked by the
    external oscillator (typically 20 or 40 MHz).
    
    To avoid confusion, we call this timestamp "timestamp_raw" or "ts_raw"
    for short.
    
    Using the timecounter framework, the "ts_raw" is converted to 64 bit
    nanoseconds since the epoch. This is what we call "timestamp".
    
    This is a preparation for the next patches which use the "timestamp"
    to work around a bug where so far only the "ts_raw" is used.
    
    Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com>
    Tested-by: Thomas Kopp <thomas.kopp@microchip.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: mcp251xfd: fix ring configuration when switching from CAN-CC to CAN-FD mode [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Fri Jul 5 17:28:27 2024 +0200

    can: mcp251xfd: fix ring configuration when switching from CAN-CC to CAN-FD mode
    
    [ Upstream commit 50ea5449c56310d2d31c28ba91a59232116d3c1e ]
    
    If the ring (rx, tx) and/or coalescing parameters (rx-frames-irq,
    tx-frames-irq) have been configured while the interface was in CAN-CC
    mode, but the interface is brought up in CAN-FD mode, the ring
    parameters might be too big.
    
    Use the default CAN-FD values in this case.
    
    Fixes: 9263c2e92be9 ("can: mcp251xfd: ring: add support for runtime configurable RX/TX ring parameters")
    Link: https://lore.kernel.org/all/20240805-mcp251xfd-fix-ringconfig-v1-1-72086f0ca5ee@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: mcp251xfd: mcp251xfd_handle_rxif_ring_uinc(): factor out in separate function [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Jan 11 20:25:48 2023 +0100

    can: mcp251xfd: mcp251xfd_handle_rxif_ring_uinc(): factor out in separate function
    
    [ Upstream commit d49184b7b585f9da7ee546b744525f62117019f6 ]
    
    This is a preparation patch.
    
    Sending the UINC messages followed by incrementing the tail pointer
    will be called in more than one place in upcoming patches, so factor
    this out into a separate function.
    
    Also make mcp251xfd_handle_rxif_ring_uinc() safe to be called with a
    "len" of 0.
    
    Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com>
    Tested-by: Thomas Kopp <thomas.kopp@microchip.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: mcp251xfd: rx: add workaround for erratum DS80000789E 6 of mcp2518fd [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Jan 11 11:53:50 2023 +0100

    can: mcp251xfd: rx: add workaround for erratum DS80000789E 6 of mcp2518fd
    
    [ Upstream commit 24436be590c6fbb05f6161b0dfba7d9da60214aa ]
    
    This patch tries to works around erratum DS80000789E 6 of the
    mcp2518fd, the other variants of the chip family (mcp2517fd and
    mcp251863) are probably also affected.
    
    In the bad case, the driver reads a too large head index. In the
    original code, the driver always trusted the read value, which caused
    old, already processed CAN frames or new, incompletely written CAN
    frames to be (re-)processed.
    
    To work around this issue, keep a per FIFO timestamp [1] of the last
    valid received CAN frame and compare against the timestamp of every
    received CAN frame. If an old CAN frame is detected, abort the
    iteration and mark the number of valid CAN frames as processed in the
    chip by incrementing the FIFO's tail index.
    
    Further tests showed that this workaround can recognize old CAN
    frames, but a small time window remains in which partially written CAN
    frames [2] are not recognized but then processed. These CAN frames
    have the correct data and time stamps, but the DLC has not yet been
    updated.
    
    [1] As the raw timestamp overflows every 107 seconds (at the usual
        clock rate of 40 MHz) convert it to nanoseconds with the
        timecounter framework and use this to detect stale CAN frames.
    
    Link: https://lore.kernel.org/all/BL3PR11MB64844C1C95CA3BDADAE4D8CCFBC99@BL3PR11MB6484.namprd11.prod.outlook.com [2]
    Reported-by: Stefan Althöfer <Stefan.Althoefer@janztec.com>
    Closes: https://lore.kernel.org/all/FR0P281MB1966273C216630B120ABB6E197E89@FR0P281MB1966.DEUP281.PROD.OUTLOOK.COM
    Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com>
    Tested-by: Thomas Kopp <thomas.kopp@microchip.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: mcp251xfd: rx: prepare to workaround broken RX FIFO head index erratum [+ + +]
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Wed Jan 11 21:07:03 2023 +0100

    can: mcp251xfd: rx: prepare to workaround broken RX FIFO head index erratum
    
    [ Upstream commit 85505e585637a737e4713c1386c30e37c325b82e ]
    
    This is a preparatory patch to work around erratum DS80000789E 6 of
    the mcp2518fd, the other variants of the chip family (mcp2517fd and
    mcp251863) are probably also affected.
    
    When handling the RX interrupt, the driver iterates over all pending
    FIFOs (which are implemented as ring buffers in hardware) and reads
    the FIFO header index from the RX FIFO STA register of the chip.
    
    In the bad case, the driver reads a too large head index. In the
    original code, the driver always trusted the read value, which caused
    old CAN frames that were already processed, or new, incompletely
    written CAN frames to be (re-)processed.
    
    Instead of reading and trusting the head index, read the head index
    and calculate the number of CAN frames that were supposedly received -
    replace mcp251xfd_rx_ring_update() with mcp251xfd_get_rx_len().
    
    The mcp251xfd_handle_rxif_ring() function reads the received CAN
    frames from the chip, iterates over them and pushes them into the
    network stack. Prepare that the iteration can be stopped if an old CAN
    frame is detected. The actual code to detect old or incomplete frames
    and abort will be added in the next patch.
    
    Link: https://lore.kernel.org/all/BL3PR11MB64844C1C95CA3BDADAE4D8CCFBC99@BL3PR11MB6484.namprd11.prod.outlook.com
    Reported-by: Stefan Althöfer <Stefan.Althoefer@janztec.com>
    Closes: https://lore.kernel.org/all/FR0P281MB1966273C216630B120ABB6E197E89@FR0P281MB1966.DEUP281.PROD.OUTLOOK.COM
    Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com>
    Tested-by: Thomas Kopp <thomas.kopp@microchip.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
cifs: Fix FALLOC_FL_ZERO_RANGE to preflush buffered part of target region [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Wed Aug 28 21:08:25 2024 +0100

    cifs: Fix FALLOC_FL_ZERO_RANGE to preflush buffered part of target region
    
    [ Upstream commit 91d1dfae464987aaf6c79ff51d8674880fb3be77 ]
    
    Under certain conditions, the range to be cleared by FALLOC_FL_ZERO_RANGE
    may only be buffered locally and not yet have been flushed to the server.
    For example:
    
            xfs_io -f -t -c "pwrite -S 0x41 0 4k" \
                         -c "pwrite -S 0x42 4k 4k" \
                         -c "fzero 0 4k" \
                         -c "pread -v 0 8k" /xfstest.test/foo
    
    will write two 4KiB blocks of data, which get buffered in the pagecache,
    and then fallocate() is used to clear the first 4KiB block on the server -
    but we don't flush the data first, which means the EOF position on the
    server is wrong, and so the FSCTL_SET_ZERO_DATA RPC fails (and xfs_io
    ignores the error), but then when we try to read it, we see the old data.
    
    Fix this by preflushing any part of the target region that above the
    server's idea of the EOF position to force the server to update its EOF
    position.
    
    Note, however, that we don't want to simply expand the file by moving the
    EOF before doing the FSCTL_SET_ZERO_DATA[*] because someone else might see
    the zeroed region or if the RPC fails we then have to try to clean it up or
    risk getting corruption.
    
    [*] And we have to move the EOF first otherwise FSCTL_SET_ZERO_DATA won't
    do what we want.
    
    This fixes the generic/008 xfstest.
    
    [!] Note: A better way to do this might be to split the operation into two
    parts: we only do FSCTL_SET_ZERO_DATA for the part of the range below the
    server's EOF and then, if that worked, invalidate the buffered pages for the
    part above the range.
    
    Fixes: 6b69040247e1 ("cifs/smb3: Fix data inconsistent when zero file range")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Steve French <stfrench@microsoft.com>
    cc: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    cc: Pavel Shilovsky <pshilov@microsoft.com>
    cc: Paulo Alcantara <pc@manguebit.com>
    cc: Shyam Prasad N <nspmangalore@gmail.com>
    cc: Rohith Surabattula <rohiths.msft@gmail.com>
    cc: Jeff Layton <jlayton@kernel.org>
    cc: linux-cifs@vger.kernel.org
    cc: linux-mm@kvack.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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>

clk: qcom: gcc-sm8550: Don't park the USB RCG at registration time [+ + +]
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Mon Aug 19 16:36:27 2024 -0700

    clk: qcom: gcc-sm8550: Don't park the USB RCG at registration time
    
    [ Upstream commit 7b6dfa1bbe7f727315d2e05a2fc8e4cfeb779156 ]
    
    Amit Pundir reports that audio and USB-C host mode stops working if the
    gcc_usb30_prim_master_clk_src clk is registered and
    clk_rcg2_shared_init() parks it on XO. Skip parking this clk at
    registration time to fix those issues.
    
    Partially revert commit 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon
    registration") by skipping the parking bit for this clk, but keep the
    part where we cache the config register. That's still necessary to
    figure out the true parent of the clk at registration time.
    
    Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration")
    Fixes: 929c75d57566 ("clk: qcom: gcc-sm8550: Mark RCGs shared where applicable")
    Cc: Konrad Dybcio <konradybcio@kernel.org>
    Cc: Bjorn Andersson <andersson@kernel.org>
    Cc: Taniya Das <quic_tdas@quicinc.com>
    Reported-by: Amit Pundir <amit.pundir@linaro.org>
    Closes: https://lore.kernel.org/CAMi1Hd1KQBE4kKUdAn8E5FV+BiKzuv+8FoyWQrrTHPDoYTuhgA@mail.gmail.com
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20240819233628.2074654-3-swboyd@chromium.org
    Tested-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sm8550: Don't use parking clk_ops for QUPs [+ + +]
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Mon Aug 19 16:36:26 2024 -0700

    clk: qcom: gcc-sm8550: Don't use parking clk_ops for QUPs
    
    [ Upstream commit d10eeb75168b84ed9559c58efe2756c2e0bc052a ]
    
    The QUPs aren't shared in a way that requires parking the RCG at an
    always on parent in case some other entity turns on the clk. The
    hardware is capable of setting a new frequency itself with the DFS mode,
    so parking is unnecessary. Furthermore, there aren't any GDSCs for these
    devices, so there isn't a possibility of the GDSC turning on the clks
    for housekeeping purposes.
    
    This wasn't a problem to mark these clks shared until we started parking
    shared RCGs at clk registration time in commit 01a0a6cc8cfd ("clk: qcom:
    Park shared RCGs upon registration"). Parking at init is actually
    harmful to the UART when earlycon is used. If the device is pumping out
    data while the frequency changes you'll see garbage on the serial
    console until the driver can probe and actually set a proper frequency.
    
    Revert the QUP part of commit 929c75d57566 ("clk: qcom: gcc-sm8550: Mark
    RCGs shared where applicable") so that the QUPs don't get parked during
    clk registration and break UART operations.
    
    Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration")
    Fixes: 929c75d57566 ("clk: qcom: gcc-sm8550: Mark RCGs shared where applicable")
    Cc: Konrad Dybcio <konradybcio@kernel.org>
    Cc: Bjorn Andersson <andersson@kernel.org>
    Cc: Taniya Das <quic_tdas@quicinc.com>
    Reported-by: Amit Pundir <amit.pundir@linaro.org>
    Closes: https://lore.kernel.org/CAMi1Hd1KQBE4kKUdAn8E5FV+BiKzuv+8FoyWQrrTHPDoYTuhgA@mail.gmail.com
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20240819233628.2074654-2-swboyd@chromium.org
    Tested-by: Amit Pundir <amit.pundir@linaro.org>
    Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: ipq9574: Update the alpha PLL type for GPLLs [+ + +]
Author: devi priya <quic_devipriy@quicinc.com>
Date:   Tue Aug 6 11:41:05 2024 +0530

    clk: qcom: ipq9574: Update the alpha PLL type for GPLLs
    
    [ Upstream commit 6357efe3abead68048729adf11a9363881657939 ]
    
    Update PLL offsets to DEFAULT_EVO to configure MDIO to 800MHz.
    
    The incorrect clock frequency leads to an incorrect MDIO clock. This,
    in turn, affects the MDIO hardware configurations as the divider is
    calculated from the MDIO clock frequency. If the clock frequency is
    not as expected, the MDIO register fails due to the generation of an
    incorrect MDIO frequency.
    
    This issue is critical as it results in incorrect MDIO configurations
    and ultimately leads to the MDIO function not working. This results in
    a complete feature failure affecting all Ethernet PHYs. Specifically,
    Ethernet will not work on IPQ9574 due to this issue.
    
    Currently, the clock frequency is set to CLK_ALPHA_PLL_TYPE_DEFAULT.
    However, this setting does not yield the expected clock frequency.
    To rectify this, we need to change this to CLK_ALPHA_PLL_TYPE_DEFAULT_EVO.
    
    This modification ensures that the clock frequency aligns with our
    expectations, thereby resolving the MDIO register failure and ensuring
    the proper functioning of the Ethernet on IPQ9574.
    
    Fixes: d75b82cff488 ("clk: qcom: Add Global Clock Controller driver for IPQ9574")
    Signed-off-by: devi priya <quic_devipriy@quicinc.com>
    Signed-off-by: Amandeep Singh <quic_amansing@quicinc.com>
    Link: https://lore.kernel.org/r/20240806061105.2849944-1-quic_amansing@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: starfive: jh7110-sys: Add notifier for PLL0 clock [+ + +]
Author: Xingyu Wu <xingyu.wu@starfivetech.com>
Date:   Mon Aug 26 16:04:29 2024 +0800

    clk: starfive: jh7110-sys: Add notifier for PLL0 clock
    
    commit 538d5477b25289ac5d46ca37b9e5b4d685cbe019 upstream.
    
    Add notifier function for PLL0 clock. In the function, the cpu_root clock
    should be operated by saving its current parent and setting a new safe
    parent (osc clock) before setting the PLL0 clock rate. After setting PLL0
    rate, it should be switched back to the original parent clock.
    
    Fixes: e2c510d6d630 ("riscv: dts: starfive: Add cpu scaling for JH7110 SoC")
    Cc: stable@vger.kernel.org
    Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
    Link: https://lore.kernel.org/r/20240826080430.179788-2-xingyu.wu@starfivetech.com
    Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
    Tested-by: Michael Jeanson <mjeanson@efficios.com>
    Signed-off-by: Stephen Boyd <sboyd@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: amd-pstate: Enable amd-pstate preferred core support [+ + +]
Author: Meng Li <li.meng@amd.com>
Date:   Fri Jan 19 17:04:58 2024 +0800

    cpufreq: amd-pstate: Enable amd-pstate preferred core support
    
    commit f3a052391822b772b4e27f2594526cf1eb103cab upstream.
    
    amd-pstate driver utilizes the functions and data structures
    provided by the ITMT architecture to enable the scheduler to
    favor scheduling on cores which can be get a higher frequency
    with lower voltage. We call it amd-pstate preferrred core.
    
    Here sched_set_itmt_core_prio() is called to set priorities and
    sched_set_itmt_support() is called to enable ITMT feature.
    amd-pstate driver uses the highest performance value to indicate
    the priority of CPU. The higher value has a higher priority.
    
    The initial core rankings are set up by amd-pstate when the
    system boots.
    
    Add a variable hw_prefcore in cpudata structure. It will check
    if the processor and power firmware support preferred core
    feature.
    
    Add one new early parameter `disable` to allow user to disable
    the preferred core.
    
    Only when hardware supports preferred core and user set `enabled`
    in early parameter, amd pstate driver supports preferred core featue.
    
    Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
    Reviewed-by: Huang Rui <ray.huang@amd.com>
    Reviewed-by: Wyes Karny <wyes.karny@amd.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Co-developed-by: Perry Yuan <Perry.Yuan@amd.com>
    Signed-off-by: Perry Yuan <Perry.Yuan@amd.com>
    Signed-off-by: Meng Li <li.meng@amd.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cpufreq: amd-pstate: fix the highest frequency issue which limits performance [+ + +]
Author: Perry Yuan <perry.yuan@amd.com>
Date:   Wed May 8 13:47:03 2024 +0800

    cpufreq: amd-pstate: fix the highest frequency issue which limits performance
    
    commit bf202e654bfa57fb8cf9d93d4c6855890b70b9c4 upstream.
    
    To address the performance drop issue, an optimization has been
    implemented. The incorrect highest performance value previously set by the
    low-level power firmware for AMD CPUs with Family ID 0x19 and Model ID
    ranging from 0x70 to 0x7F series has been identified as the cause.
    
    To resolve this, a check has been implemented to accurately determine the
    CPU family and model ID. The correct highest performance value is now set
    and the performance drop caused by the incorrect highest performance value
    are eliminated.
    
    Before the fix, the highest frequency was set to 4200MHz, now it is set
    to 4971MHz which is correct.
    
    CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
      0    0      0    0 0:0:0:0          yes 4971.0000 400.0000  400.0000
      1    0      0    0 0:0:0:0          yes 4971.0000 400.0000  400.0000
      2    0      0    1 1:1:1:0          yes 4971.0000 400.0000 4865.8140
      3    0      0    1 1:1:1:0          yes 4971.0000 400.0000  400.0000
    
    Fixes: f3a052391822 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218759
    Signed-off-by: Perry Yuan <perry.yuan@amd.com>
    Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Tested-by: Gaha Bana <gahabana@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
crypto: qat - fix unintentional re-enabling of error interrupts [+ + +]
Author: Hareshx Sankar Raj <hareshx.sankar.raj@intel.com>
Date:   Tue Jun 25 15:41:19 2024 +0100

    crypto: qat - fix unintentional re-enabling of error interrupts
    
    [ Upstream commit f0622894c59458fceb33c4197462bc2006f3fc6b ]
    
    The logic that detects pending VF2PF interrupts unintentionally clears
    the section of the error mask register(s) not related to VF2PF.
    This might cause interrupts unrelated to VF2PF, reported through
    errsou3 and errsou5, to be reported again after the execution
    of the function disable_pending_vf2pf_interrupts() in dh895xcc
    and GEN2 devices.
    
    Fix by updating only section of errmsk3 and errmsk5 related to VF2PF.
    
    Signed-off-by: Hareshx Sankar Raj <hareshx.sankar.raj@intel.com>
    Reviewed-by: Damian Muszynski <damian.muszynski@intel.com>
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: starfive - Align rsa input data to 32-bit [+ + +]
Author: Jia Jie Ho <jiajie.ho@starfivetech.com>
Date:   Wed Jun 26 09:40:42 2024 +0800

    crypto: starfive - Align rsa input data to 32-bit
    
    [ Upstream commit 6aad7019f697ab0bed98eba737d19bd7f67713de ]
    
    Hardware expects RSA input plain/ciphertext to be 32-bit aligned.
    Set fixed length for preallocated buffer to the maximum supported
    keysize of the hardware and shift input text accordingly.
    
    Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: starfive - Fix nent assignment in rsa dec [+ + +]
Author: Jia Jie Ho <jiajie.ho@starfivetech.com>
Date:   Wed Jun 26 09:40:43 2024 +0800

    crypto: starfive - Fix nent assignment in rsa dec
    
    [ Upstream commit 8323c036789b8b4a61925fce439a89dba17b7f2f ]
    
    Missing src scatterlist nent assignment in rsa decrypt function.
    Removing all unneeded assignment and use nents value from req->src
    instead.
    
    Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/region: Verify target positions using the ordered target list [+ + +]
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Tue Jul 2 22:29:51 2024 -0700

    cxl/region: Verify target positions using the ordered target list
    
    [ Upstream commit 82a3e3a235633aa0575fac9507d648dd80f3437f ]
    
    When a root decoder is configured the interleave target list is read
    from the BIOS populated CFMWS structure. Per the CXL spec 3.1 Table
    9-22 the target list is in interleave order. The CXL driver populates
    its decoder target list in the same order and stores it in 'struct
    cxl_switch_decoder' field "@target: active ordered target list in
    current decoder configuration"
    
    Given the promise of an ordered list, the driver can stop duplicating
    the work of BIOS and simply check target positions against the ordered
    list during region configuration.
    
    The simplified check against the ordered list is presented here.
    A follow-on patch will remove the unused code.
    
    For Modulo arithmetic this is not a fix, only a simplification.
    For XOR arithmetic this is a fix for HB IW of 3,6,12.
    
    Fixes: f9db85bfec0d ("cxl/acpi: Support CXL XOR Interleave Math (CXIMS)")
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://patch.msgid.link/35d08d3aba08fee0f9b86ab1cef0c25116ca8a55.1719980933.git.alison.schofield@intel.com
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    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-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/display: Check denominator pbn_div before used [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Tue Jun 18 16:21:20 2024 -0600

    drm/amd/display: Check denominator pbn_div before used
    
    [ Upstream commit 116a678f3a9abc24f5c9d2525b7393d18d9eb58e ]
    
    [WHAT & HOW]
    A denominator cannot be 0, and is checked before used.
    
    This fixes 1 DIVIDE_BY_ZERO issue reported by Coverity.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Jerry Zuo <jerry.zuo@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: Run DC_LOG_DC after checking link->link_enc [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Fri Jun 7 09:21:30 2024 -0600

    drm/amd/display: Run DC_LOG_DC after checking link->link_enc
    
    [ Upstream commit 3a82f62b0d9d7687eac47603bb6cd14a50fa718b ]
    
    [WHAT]
    The DC_LOG_DC should be run after link->link_enc is checked, not before.
    
    This fixes 1 REVERSE_INULL issue 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: Add gfx12 swizzle mode defs [+ + +]
Author: Aurabindo Pillai <aurabindo.pillai@amd.com>
Date:   Fri Feb 2 14:00:27 2024 -0500

    drm/amd: Add gfx12 swizzle mode defs
    
    [ Upstream commit 7ceb94e87bffff7c12b61eb29749e1d8ac976896 ]
    
    Add GFX12 swizzle mode definitions for use with DCN401
    
    Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Acked-by: Rodrigo Siqueira <rodrigo.siqueira@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: clear RB_OVERFLOW bit when enabling interrupts [+ + +]
Author: Danijel Slivka <danijel.slivka@amd.com>
Date:   Mon Jun 24 07:58:24 2024 +0200

    drm/amdgpu: clear RB_OVERFLOW bit when enabling interrupts
    
    [ Upstream commit afbf7955ff01e952dbdd465fa25a2ba92d00291c ]
    
    Why:
    Setting IH_RB_WPTR register to 0 will not clear the RB_OVERFLOW bit
    if RB_ENABLE is not set.
    
    How to fix:
    Set WPTR_OVERFLOW_CLEAR bit after RB_ENABLE bit is set.
    The RB_ENABLE bit is required to be set, together with
    WPTR_OVERFLOW_ENABLE bit so that setting WPTR_OVERFLOW_CLEAR bit
    would clear the RB_OVERFLOW.
    
    Signed-off-by: Danijel Slivka <danijel.slivka@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 smatch static checker warning [+ + +]
Author: Hawking Zhang <Hawking.Zhang@amd.com>
Date:   Fri Jun 21 17:53:30 2024 +0800

    drm/amdgpu: Fix smatch static checker warning
    
    [ Upstream commit bdbdc7cecd00305dc844a361f9883d3a21022027 ]
    
    adev->gfx.imu.funcs could be NULL
    
    Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Reviewed-by: Likun Gao <Likun.Gao@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: handle gfx12 in amdgpu_display_verify_sizes [+ + +]
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Sat Jun 1 19:53:01 2024 -0400

    drm/amdgpu: handle gfx12 in amdgpu_display_verify_sizes
    
    [ Upstream commit 8dd1426e2c80e32ac1995007330c8f95ffa28ebb ]
    
    It verified GFX9-11 swizzle modes on GFX12, which has undefined behavior.
    
    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: reject gang submit on reserved VMIDs [+ + +]
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Jan 19 14:57:29 2024 +0100

    drm/amdgpu: reject gang submit on reserved VMIDs
    
    [ Upstream commit 320debca1ba3a81c87247eac84eff976ead09ee0 ]
    
    A gang submit won't work if the VMID is reserved and we can't flush out
    VM changes from multiple engines at the same time.
    
    Signed-off-by: Christian König <christian.koenig@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/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/i915: Do not attempt to load the GSC multiple times [+ + +]
Author: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Date:   Tue Aug 20 14:59:52 2024 -0700

    drm/i915: Do not attempt to load the GSC multiple times
    
    commit 59d3cfdd7f9655a0400ac453bf92199204f8b2a1 upstream.
    
    If the GSC FW fails to load the GSC HW hangs permanently; the only ways
    to recover it are FLR or D3cold entry, with the former only being
    supported on driver unload and the latter only on DGFX, for which we
    don't need to load the GSC. Therefore, if GSC fails to load there is no
    need to try again because the HW is stuck in the error state and the
    submission to load the FW would just hang the GSCCS.
    
    Note that, due to wa_14015076503, on MTL the GuC escalates all GSCCS
    hangs to full GT resets, which would trigger a new attempt to load the
    GSC FW in the post-reset HW re-init; this issue is also fixed by not
    attempting to load the GSC FW after an error.
    
    Fixes: 15bd4a67e914 ("drm/i915/gsc: GSC firmware loading")
    Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
    Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
    Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
    Cc: John Harrison <John.C.Harrison@Intel.com>
    Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Cc: <stable@vger.kernel.org> # v6.3+
    Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240820215952.2290807-1-daniele.ceraolospurio@intel.com
    (cherry picked from commit 03ded4d432a1fb7bb6c44c5856d14115f6f6c3b9)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ELF: fix kernel.randomize_va_space double read [+ + +]
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Fri Jun 21 21:54:50 2024 +0300

    ELF: fix kernel.randomize_va_space double read
    
    [ Upstream commit 2a97388a807b6ab5538aa8f8537b2463c6988bd2 ]
    
    ELF loader uses "randomize_va_space" twice. It is sysctl and can change
    at any moment, so 2 loads could see 2 different values in theory with
    unpredictable consequences.
    
    Issue exactly one load for consistent value across one exec.
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Link: https://lore.kernel.org/r/3329905c-7eb8-400a-8f0a-d87cff979b5b@p183
    Signed-off-by: Kees Cook <kees@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
eventfs: Use list_del_rcu() for SRCU protected list variable [+ + +]
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Wed Sep 4 13:16:05 2024 -0400

    eventfs: Use list_del_rcu() for SRCU protected list variable
    
    commit d2603279c7d645bf0d11fa253b23f1ab48fc8d3c upstream.
    
    Chi Zhiling reported:
    
      We found a null pointer accessing in tracefs[1], the reason is that the
      variable 'ei_child' is set to LIST_POISON1, that means the list was
      removed in eventfs_remove_rec. so when access the ei_child->is_freed, the
      panic triggered.
    
      by the way, the following script can reproduce this panic
    
      loop1 (){
          while true
          do
              echo "p:kp submit_bio" > /sys/kernel/debug/tracing/kprobe_events
              echo "" > /sys/kernel/debug/tracing/kprobe_events
          done
      }
      loop2 (){
          while true
          do
              tree /sys/kernel/debug/tracing/events/kprobes/
          done
      }
      loop1 &
      loop2
    
      [1]:
      [ 1147.959632][T17331] Unable to handle kernel paging request at virtual address dead000000000150
      [ 1147.968239][T17331] Mem abort info:
      [ 1147.971739][T17331]   ESR = 0x0000000096000004
      [ 1147.976172][T17331]   EC = 0x25: DABT (current EL), IL = 32 bits
      [ 1147.982171][T17331]   SET = 0, FnV = 0
      [ 1147.985906][T17331]   EA = 0, S1PTW = 0
      [ 1147.989734][T17331]   FSC = 0x04: level 0 translation fault
      [ 1147.995292][T17331] Data abort info:
      [ 1147.998858][T17331]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
      [ 1148.005023][T17331]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      [ 1148.010759][T17331]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
      [ 1148.016752][T17331] [dead000000000150] address between user and kernel address ranges
      [ 1148.024571][T17331] Internal error: Oops: 0000000096000004 [#1] SMP
      [ 1148.030825][T17331] Modules linked in: team_mode_loadbalance team nlmon act_gact cls_flower sch_ingress bonding tls macvlan dummy ib_core bridge stp llc veth amdgpu amdxcp mfd_core gpu_sched drm_exec drm_buddy radeon crct10dif_ce video drm_suballoc_helper ghash_ce drm_ttm_helper sha2_ce ttm sha256_arm64 i2c_algo_bit sha1_ce sbsa_gwdt cp210x drm_display_helper cec sr_mod cdrom drm_kms_helper binfmt_misc sg loop fuse drm dm_mod nfnetlink ip_tables autofs4 [last unloaded: tls]
      [ 1148.072808][T17331] CPU: 3 PID: 17331 Comm: ls Tainted: G        W         ------- ----  6.6.43 #2
      [ 1148.081751][T17331] Source Version: 21b3b386e948bedd29369af66f3e98ab01b1c650
      [ 1148.088783][T17331] Hardware name: Greatwall GW-001M1A-FTF/GW-001M1A-FTF, BIOS KunLun BIOS V4.0 07/16/2020
      [ 1148.098419][T17331] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [ 1148.106060][T17331] pc : eventfs_iterate+0x2c0/0x398
      [ 1148.111017][T17331] lr : eventfs_iterate+0x2fc/0x398
      [ 1148.115969][T17331] sp : ffff80008d56bbd0
      [ 1148.119964][T17331] x29: ffff80008d56bbf0 x28: ffff001ff5be2600 x27: 0000000000000000
      [ 1148.127781][T17331] x26: ffff001ff52ca4e0 x25: 0000000000009977 x24: dead000000000100
      [ 1148.135598][T17331] x23: 0000000000000000 x22: 000000000000000b x21: ffff800082645f10
      [ 1148.143415][T17331] x20: ffff001fddf87c70 x19: ffff80008d56bc90 x18: 0000000000000000
      [ 1148.151231][T17331] x17: 0000000000000000 x16: 0000000000000000 x15: ffff001ff52ca4e0
      [ 1148.159048][T17331] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
      [ 1148.166864][T17331] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000804391d0
      [ 1148.174680][T17331] x8 : 0000000180000000 x7 : 0000000000000018 x6 : 0000aaab04b92862
      [ 1148.182498][T17331] x5 : 0000aaab04b92862 x4 : 0000000080000000 x3 : 0000000000000068
      [ 1148.190314][T17331] x2 : 000000000000000f x1 : 0000000000007ea8 x0 : 0000000000000001
      [ 1148.198131][T17331] Call trace:
      [ 1148.201259][T17331]  eventfs_iterate+0x2c0/0x398
      [ 1148.205864][T17331]  iterate_dir+0x98/0x188
      [ 1148.210036][T17331]  __arm64_sys_getdents64+0x78/0x160
      [ 1148.215161][T17331]  invoke_syscall+0x78/0x108
      [ 1148.219593][T17331]  el0_svc_common.constprop.0+0x48/0xf0
      [ 1148.224977][T17331]  do_el0_svc+0x24/0x38
      [ 1148.228974][T17331]  el0_svc+0x40/0x168
      [ 1148.232798][T17331]  el0t_64_sync_handler+0x120/0x130
      [ 1148.237836][T17331]  el0t_64_sync+0x1a4/0x1a8
      [ 1148.242182][T17331] Code: 54ffff6c f9400676 910006d6 f9000676 (b9405300)
      [ 1148.248955][T17331] ---[ end trace 0000000000000000 ]---
    
    The issue is that list_del() is used on an SRCU protected list variable
    before the synchronization occurs. This can poison the list pointers while
    there is a reader iterating the list.
    
    This is simply fixed by using list_del_rcu() that is specifically made for
    this purpose.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240829085025.3600021-1-chizhiling@163.com/
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Link: https://lore.kernel.org/20240904131605.640d42b1@gandalf.local.home
    Fixes: 43aa6f97c2d03 ("eventfs: Get rid of dentry pointers without refcounts")
    Reported-by: Chi Zhiling <chizhiling@kylinos.cn>
    Tested-by: Chi Zhiling <chizhiling@kylinos.cn>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
firmware: cs_dsp: Don't allow writes to read-only controls [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Tue Jul 2 12:08:09 2024 +0100

    firmware: cs_dsp: Don't allow writes to read-only controls
    
    [ Upstream commit 62412a9357b16a4e39dc582deb2e2a682b92524c ]
    
    Add a check to cs_dsp_coeff_write_ctrl() to abort if the control
    is not writeable.
    
    The cs_dsp code originated as an ASoC driver (wm_adsp) where all
    controls were exported as ALSA controls. It relied on ALSA to
    enforce the read-only permission. Now that the code has been
    separated from ALSA/ASoC it must perform its own permission check.
    
    This isn't currently causing any problems so there shouldn't be any
    need to backport this. If the client of cs_dsp exposes the control as
    an ALSA control, it should set permissions on that ALSA control to
    protect it. The few uses of cs_dsp_coeff_write_ctrl() inside drivers
    are for writable controls.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://patch.msgid.link/20240702110809.16836-1-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

fs/ntfs3: One more reason to mark inode bad [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Thu May 30 10:55:12 2024 +0300

    fs/ntfs3: One more reason to mark inode bad
    
    [ Upstream commit a0dde5d7a58b6bf9184ef3d8c6e62275c3645584 ]
    
    In addition to returning an error, mark the node as bad.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Aug 26 19:20:56 2024 +0800

    fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF
    
    commit 72a6e22c604c95ddb3b10b5d3bb85b6ff4dbc34f upstream.
    
    The fscache_cookie_lru_timer is initialized when the fscache module
    is inserted, but is not deleted when the fscache module is removed.
    If timer_reduce() is called before removing the fscache module,
    the fscache_cookie_lru_timer will be added to the timer list of
    the current cpu. Afterwards, a use-after-free will be triggered
    in the softIRQ after removing the fscache module, as follows:
    
    ==================================================================
    BUG: unable to handle page fault for address: fffffbfff803c9e9
     PF: supervisor read access in kernel mode
     PF: error_code(0x0000) - not-present page
    PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0
    Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
    CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855
    Tainted: [W]=WARN
    RIP: 0010:__run_timer_base.part.0+0x254/0x8a0
    Call Trace:
     <IRQ>
     tmigr_handle_remote_up+0x627/0x810
     __walk_groups.isra.0+0x47/0x140
     tmigr_handle_remote+0x1fa/0x2f0
     handle_softirqs+0x180/0x590
     irq_exit_rcu+0x84/0xb0
     sysvec_apic_timer_interrupt+0x6e/0x90
     </IRQ>
     <TASK>
     asm_sysvec_apic_timer_interrupt+0x1a/0x20
    RIP: 0010:default_idle+0xf/0x20
     default_idle_call+0x38/0x60
     do_idle+0x2b5/0x300
     cpu_startup_entry+0x54/0x60
     start_secondary+0x20d/0x280
     common_startup_64+0x13e/0x148
     </TASK>
    Modules linked in: [last unloaded: netfs]
    ==================================================================
    
    Therefore delete fscache_cookie_lru_timer when removing the fscahe module.
    
    Fixes: 12bb21a29c19 ("fscache: Implement cookie user counting and resource pinning")
    Cc: stable@kernel.org
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Link: https://lore.kernel.org/r/20240826112056.2458299-1-libaokun@huaweicloud.com
    Acked-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fuse: fix memory leak in fuse_create_open [+ + +]
Author: yangyun <yangyun50@huawei.com>
Date:   Fri Aug 23 16:51:46 2024 +0800

    fuse: fix memory leak in fuse_create_open
    
    commit 3002240d16494d798add0575e8ba1f284258ab34 upstream.
    
    The memory of struct fuse_file is allocated but not freed
    when get_create_ext return error.
    
    Fixes: 3e2b6fdbdc9a ("fuse: send security context of inode on file")
    Cc: stable@vger.kernel.org # v5.17
    Signed-off-by: yangyun <yangyun50@huawei.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: modepin: Enable module autoloading [+ + +]
Author: Liao Chen <liaochen4@huawei.com>
Date:   Mon Sep 2 11:58:48 2024 +0000

    gpio: modepin: Enable module autoloading
    
    [ Upstream commit a5135526426df5319d5f4bcd15ae57c45a97714b ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based
    on the alias from of_device_id table.
    
    Fixes: 7687a5b0ee93 ("gpio: modepin: Add driver support for modepin GPIO controller")
    Signed-off-by: Liao Chen <liaochen4@huawei.com>
    Reviewed-by: Michal Simek <michal.simek@amd.com>
    Link: https://lore.kernel.org/r/20240902115848.904227-1-liaochen4@huawei.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
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: (hp-wmi-sensors) Check if WMI event data exists [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Sun Sep 1 05:10:51 2024 +0200

    hwmon: (hp-wmi-sensors) Check if WMI event data exists
    
    [ Upstream commit a54da9df75cd1b4b5028f6c60f9a211532680585 ]
    
    The BIOS can choose to return no event data in response to a
    WMI event, so the ACPI object passed to the WMI notify handler
    can be NULL.
    
    Check for such a situation and ignore the event in such a case.
    
    Fixes: 23902f98f8d4 ("hwmon: add HP WMI Sensors driver")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Message-ID: <20240901031055.3030-2-W_Armin@gmx.de>
    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>

 
i3c: master: svc: resend target address when get NACK [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Jun 3 11:15:27 2024 -0400

    i3c: master: svc: resend target address when get NACK
    
    [ Upstream commit 9bc7501b0b90f4d0c34b97c14ff1f708ce7ad8f3 ]
    
    According to I3C Spec 1.1.1, 11-Jun-2021, section: 5.1.2.2.3:
    
    If the Controller chooses to start an I3C Message with an I3C Dynamic
    Address, then special provisions shall be made because that same I3C Target
    may be initiating an IBI or a Controller Role Request. So, one of three
    things may happen: (skip 1, 2)
    
    3. The Addresses match and the RnW bits also match, and so neither
    Controller nor Target will ACK since both are expecting the other side to
    provide ACK. As a result, each side might think it had "won" arbitration,
    but neither side would continue, as each would subsequently see that the
    other did not provide ACK.
    ...
    For either value of RnW: Due to the NACK, the Controller shall defer the
    Private Write or Private Read, and should typically transmit the Target
                                                        ^^^^^^^^^^^^^^^^^^^
    Address again after a Repeated START (i.e., the next one or any one prior
    ^^^^^^^^^^^^^
    to a STOP in the Frame). Since the Address Header following a Repeated
    START is not arbitrated, the Controller will always win (see Section
    5.1.2.2.4).
    
    Resend target address again if address is not 7E and controller get NACK.
    
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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: Add netif_device_attach/detach into PF reset flow [+ + +]
Author: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
Date:   Wed Aug 21 18:06:40 2024 +0200

    ice: Add netif_device_attach/detach into PF reset flow
    
    [ Upstream commit d11a67634227f9f9da51938af085fb41a733848f ]
    
    Ethtool callbacks can be executed while reset is in progress and try to
    access deleted resources, e.g. getting coalesce settings can result in a
    NULL pointer dereference seen below.
    
    Reproduction steps:
    Once the driver is fully initialized, trigger reset:
            # echo 1 > /sys/class/net/<interface>/device/reset
    when reset is in progress try to get coalesce settings using ethtool:
            # ethtool -c <interface>
    
    BUG: kernel NULL pointer dereference, address: 0000000000000020
    PGD 0 P4D 0
    Oops: Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7
    RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]
    RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206
    RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588
    RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
    R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000
    R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40
    FS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0
    Call Trace:
    <TASK>
    ice_get_coalesce+0x17/0x30 [ice]
    coalesce_prepare_data+0x61/0x80
    ethnl_default_doit+0xde/0x340
    genl_family_rcv_msg_doit+0xf2/0x150
    genl_rcv_msg+0x1b3/0x2c0
    netlink_rcv_skb+0x5b/0x110
    genl_rcv+0x28/0x40
    netlink_unicast+0x19c/0x290
    netlink_sendmsg+0x222/0x490
    __sys_sendto+0x1df/0x1f0
    __x64_sys_sendto+0x24/0x30
    do_syscall_64+0x82/0x160
    entry_SYSCALL_64_after_hwframe+0x76/0x7e
    RIP: 0033:0x7faee60d8e27
    
    Calling netif_device_detach() before reset makes the net core not call
    the driver when ethtool command is issued, the attempt to execute an
    ethtool command during reset will result in the following message:
    
        netlink error: No such device
    
    instead of NULL pointer dereference. Once reset is done and
    ice_rebuild() is executing, the netif_device_attach() is called to allow
    for ethtool operations to occur again in a safe manner.
    
    Fixes: fcea6f3da546 ("ice: Add stats and ethtool support")
    Suggested-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Igor Bagnucki <igor.bagnucki@intel.com>
    Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Reviewed-by: Michal Schmidt <mschmidt@redhat.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: Check all ice_vsi_rebuild() errors in function [+ + +]
Author: Eric Joyner <eric.joyner@intel.com>
Date:   Mon Jun 17 14:46:25 2024 +0200

    ice: Check all ice_vsi_rebuild() errors in function
    
    [ Upstream commit d47bf9a495cf424fad674321d943123dc12b926d ]
    
    Check the return value from ice_vsi_rebuild() and prevent the usage of
    incorrectly configured VSI.
    
    Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Signed-off-by: Eric Joyner <eric.joyner@intel.com>
    Signed-off-by: Karen Ostrowska <karen.ostrowska@intel.com>
    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>

ice: do not bring the VSI up, if it was down before the XDP setup [+ + +]
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date:   Fri Aug 23 11:59:31 2024 +0200

    ice: do not bring the VSI up, if it was down before the XDP setup
    
    [ Upstream commit 04c7e14e5b0b6227e7b00d7a96ca2f2426ab9171 ]
    
    After XDP configuration is completed, we bring the interface up
    unconditionally, regardless of its state before the call to .ndo_bpf().
    
    Preserve the information whether the interface had to be brought down and
    later bring it up only in such case.
    
    Fixes: efc2214b6047 ("ice: Add support for XDP")
    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>
    Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: protect XDP configuration with a mutex [+ + +]
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date:   Fri Aug 23 11:59:27 2024 +0200

    ice: protect XDP configuration with a mutex
    
    [ Upstream commit 2504b8405768a57a71e660dbfd5abd59f679a03f ]
    
    The main threat to data consistency in ice_xdp() is a possible asynchronous
    PF reset. It can be triggered by a user or by TX timeout handler.
    
    XDP setup and PF reset code access the same resources in the following
    sections:
    * ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked
    * ice_vsi_rebuild() for the PF VSI - not protected
    * ice_vsi_open() - already rtnl-locked
    
    With an unfortunate timing, such accesses can result in a crash such as the
    one below:
    
    [ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14
    [ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18
    [Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms
    [ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001
    [ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14
    [ +0.394718] ice 0000:b1:00.0: PTP reset successful
    [ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098
    [ +0.000045] #PF: supervisor read access in kernel mode
    [ +0.000023] #PF: error_code(0x0000) - not-present page
    [ +0.000023] PGD 0 P4D 0
    [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI
    [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1
    [ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021
    [ +0.000036] Workqueue: ice ice_service_task [ice]
    [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]
    [...]
    [ +0.000013] Call Trace:
    [ +0.000016] <TASK>
    [ +0.000014] ? __die+0x1f/0x70
    [ +0.000029] ? page_fault_oops+0x171/0x4f0
    [ +0.000029] ? schedule+0x3b/0xd0
    [ +0.000027] ? exc_page_fault+0x7b/0x180
    [ +0.000022] ? asm_exc_page_fault+0x22/0x30
    [ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]
    [ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]
    [ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]
    [ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]
    [ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]
    [ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]
    [ +0.000145] ice_rebuild+0x18c/0x840 [ice]
    [ +0.000145] ? delay_tsc+0x4a/0xc0
    [ +0.000022] ? delay_tsc+0x92/0xc0
    [ +0.000020] ice_do_reset+0x140/0x180 [ice]
    [ +0.000886] ice_service_task+0x404/0x1030 [ice]
    [ +0.000824] process_one_work+0x171/0x340
    [ +0.000685] worker_thread+0x277/0x3a0
    [ +0.000675] ? preempt_count_add+0x6a/0xa0
    [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50
    [ +0.000679] ? __pfx_worker_thread+0x10/0x10
    [ +0.000653] kthread+0xf0/0x120
    [ +0.000635] ? __pfx_kthread+0x10/0x10
    [ +0.000616] ret_from_fork+0x2d/0x50
    [ +0.000612] ? __pfx_kthread+0x10/0x10
    [ +0.000604] ret_from_fork_asm+0x1b/0x30
    [ +0.000604] </TASK>
    
    The previous way of handling this through returning -EBUSY is not viable,
    particularly when destroying AF_XDP socket, because the kernel proceeds
    with removal anyway.
    
    There is plenty of code between those calls and there is no need to create
    a large critical section that covers all of them, same as there is no need
    to protect ice_vsi_rebuild() with rtnl_lock().
    
    Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().
    
    Leaving unprotected sections in between would result in two states that
    have to be considered:
    1. when the VSI is closed, but not yet rebuild
    2. when VSI is already rebuild, but not yet open
    
    The latter case is actually already handled through !netif_running() case,
    we just need to adjust flag checking a little. The former one is not as
    trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of
    hardware interaction happens, this can make adding/deleting rings exit
    with an error. Luckily, VSI rebuild is pending and can apply new
    configuration for us in a managed fashion.
    
    Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to
    indicate that ice_xdp() can just hot-swap the program.
    
    Also, as ice_vsi_rebuild() flow is touched in this patch, make it more
    consistent by deconfiguring VSI when coalesce allocation fails.
    
    Fixes: 2d4238f55697 ("ice: Add support for AF_XDP")
    Fixes: efc2214b6047 ("ice: Add support for XDP")
    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: adc: ad7606: remove frstdata check for serial mode [+ + +]
Author: Guillaume Stols <gstols@baylibre.com>
Date:   Tue Jul 2 12:52:51 2024 +0000

    iio: adc: ad7606: remove frstdata check for serial mode
    
    commit 90826e08468ba7fb35d8b39645b22d9e80004afe upstream.
    
    The current implementation attempts to recover from an eventual glitch
    in the clock by checking frstdata state after reading the first
    channel's sample: If frstdata is low, it will reset the chip and
    return -EIO.
    
    This will only work in parallel mode, where frstdata pin is set low
    after the 2nd sample read starts.
    
    For the serial mode, according to the datasheet, "The FRSTDATA output
    returns to a logic low following the 16th SCLK falling edge.", thus
    after the Xth pulse, X being the number of bits in a sample, the check
    will always be true, and the driver will not work at all in serial
    mode if frstdata(optional) is defined in the devicetree as it will
    reset the chip, and return -EIO every time read_sample is called.
    
    Hence, this check must be removed for serial mode.
    
    Fixes: b9618c0cacd7 ("staging: IIO: ADC: New driver for AD7606/AD7606-6/AD7606-4")
    Signed-off-by: Guillaume Stols <gstols@baylibre.com>
    Reviewed-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://patch.msgid.link/20240702-cleanup-ad7606-v3-1-18d5ea18770e@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: 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: ili210x - use kvmalloc() to allocate buffer for firmware update [+ + +]
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Sun Jun 9 16:47:53 2024 -0700

    Input: ili210x - use kvmalloc() to allocate buffer for firmware update
    
    [ Upstream commit 17f5eebf6780eee50f887542e1833fda95f53e4d ]
    
    Allocating a contiguous buffer of 64K may fail if memory is sufficiently
    fragmented, and may cause OOM kill of an unrelated process. However we
    do not need to have contiguous memory. We also do not need to zero
    out the buffer since it will be overwritten with firmware data.
    
    Switch to using kvmalloc() instead of kzalloc().
    
    Link: https://lore.kernel.org/r/20240609234757.610273-1-dmitry.torokhov@gmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
intel: legacy: Partial revert of field get conversion [+ + +]
Author: Sasha Neftin <sasha.neftin@intel.com>
Date:   Sun Feb 18 09:42:21 2024 +0200

    intel: legacy: Partial revert of field get conversion
    
    commit ba54b1a276a6b69d80649942fe5334d19851443e upstream.
    
    Refactoring of the field get conversion introduced a regression in the
    legacy Wake On Lan from a magic packet with i219 devices. Rx address
    copied not correctly from MAC to PHY with FIELD_GET macro.
    
    Fixes: b9a452545075 ("intel: legacy: field get conversion")
    Suggested-by: Vitaly Lifshits <vitaly.lifshits@intel.com>
    Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
    Tested-by: Naama Meir <naamax.meir@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Cc: Florian Larysch <fl@n621.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
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>

 
jbd2: avoid mount failed when commit block is partial submitted [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Jun 20 15:24:05 2024 +0800

    jbd2: avoid mount failed when commit block is partial submitted
    
    [ Upstream commit 0bab8db4152c4a2185a1367db09cc402bdc62d5e ]
    
    We encountered a problem that the file system could not be mounted in
    the power-off scenario. The analysis of the file system mirror shows that
    only part of the data is written to the last commit block.
    The valid data of the commit block is concentrated in the first sector.
    However, the data of the entire block is involved in the checksum calculation.
    For different hardware, the minimum atomic unit may be different.
    If the checksum of a committed block is incorrect, clear the data except the
    'commit_header' and then calculate the checksum. If the checkusm is correct,
    it is considered that the block is partially committed, Then continue to replay
    journal.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://patch.msgid.link/20240620072405.3533701-1-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kexec_file: fix elfcorehdr digest exclusion when CONFIG_CRASH_HOTPLUG=y [+ + +]
Author: Petr Tesarik <ptesarik@suse.com>
Date:   Mon Aug 5 17:07:50 2024 +0200

    kexec_file: fix elfcorehdr digest exclusion when CONFIG_CRASH_HOTPLUG=y
    
    commit 6dacd79d28842ff01f18b4900d897741aac5999e upstream.
    
    Fix the condition to exclude the elfcorehdr segment from the SHA digest
    calculation.
    
    The j iterator is an index into the output sha_regions[] array, not into
    the input image->segment[] array.  Once it reaches
    image->elfcorehdr_index, all subsequent segments are excluded.  Besides,
    if the purgatory segment precedes the elfcorehdr segment, the elfcorehdr
    may be wrongly included in the calculation.
    
    Link: https://lkml.kernel.org/r/20240805150750.170739-1-petr.tesarik@suse.com
    Fixes: f7cc804a9fd4 ("kexec: exclude elfcorehdr from the segment digest")
    Signed-off-by: Petr Tesarik <ptesarik@suse.com>
    Acked-by: Baoquan He <bhe@redhat.com>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: Hari Bathini <hbathini@linux.ibm.com>
    Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
    Cc: Eric DeVolder <eric_devolder@yahoo.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    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()
    
    commit 844436e045ac2ab7895d8b281cb784a24de1d14d upstream.
    
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.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
    
    commit 78c5a6f1f630172b19af4912e755e1da93ef0ab5 upstream.
    
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jul 23 16:20:55 2024 -0700

    KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS
    
    commit 4bcdd831d9d01e0fb64faea50732b59b2ee88da1 upstream.
    
    Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly
    leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX
    reads guest memory.
    
    Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN
    via sync_regs(), which already holds SRCU.  I.e. trying to precisely use
    kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause
    problems.  Acquiring SRCU isn't all that expensive, so for simplicity,
    grab it unconditionally for KVM_SET_VCPU_EVENTS.
    
     =============================
     WARNING: suspicious RCU usage
     6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
     -----------------------------
     include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!
    
     other info that might help us debug this:
    
     rcu_scheduler_active = 2, debug_locks = 1
     1 lock held by repro/1071:
      #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]
    
     stack backtrace:
     CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
     Call Trace:
      <TASK>
      dump_stack_lvl+0x7f/0x90
      lockdep_rcu_suspicious+0x13f/0x1a0
      kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]
      kvm_vcpu_read_guest+0x3e/0x90 [kvm]
      nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]
      load_vmcs12_host_state+0x432/0xb40 [kvm_intel]
      vmx_leave_nested+0x30/0x40 [kvm_intel]
      kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]
      kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]
      ? mark_held_locks+0x49/0x70
      ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]
      ? kvm_vcpu_ioctl+0x497/0x970 [kvm]
      kvm_vcpu_ioctl+0x497/0x970 [kvm]
      ? lock_acquire+0xba/0x2d0
      ? find_held_lock+0x2b/0x80
      ? do_user_addr_fault+0x40c/0x6f0
      ? lock_release+0xb7/0x270
      __x64_sys_ioctl+0x82/0xb0
      do_syscall_64+0x6c/0x170
      entry_SYSCALL_64_after_hwframe+0x4b/0x53
     RIP: 0033:0x7ff11eb1b539
      </TASK>
    
    Fixes: f7e570780efc ("KVM: x86: Forcibly leave nested virt when SMM state is toggled")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240723232055.3643811-1-seanjc@google.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 6.6.51 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 12 11:11:45 2024 +0200

    Linux 6.6.51
    
    Link: https://lore.kernel.org/r/20240910092608.225137854@linuxfoundation.org
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Kexy Biscuit <kexybiscuit@aosc.io>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
LoongArch: Use correct API to map cmdline in relocate_kernel() [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Sat Jul 20 22:41:07 2024 +0800

    LoongArch: Use correct API to map cmdline in relocate_kernel()
    
    [ Upstream commit 0124fbb4c6dba23dbdf80c829be68adbccde2722 ]
    
    fw_arg1 is in memory space rather than I/O space, so we should use
    early_memremap_ro() instead of early_ioremap() to map the cmdline.
    Moreover, we should unmap it after using.
    
    Suggested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.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: 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>

 
membarrier: riscv: Add full memory barrier in switch_mm() [+ + +]
Author: Andrea Parri <parri.andrea@gmail.com>
Date:   Wed Jan 31 15:49:33 2024 +0100

    membarrier: riscv: Add full memory barrier in switch_mm()
    
    commit d6cfd1770f20392d7009ae1fdb04733794514fa9 upstream.
    
    The membarrier system call requires a full memory barrier after storing
    to rq->curr, before going back to user-space.  The barrier is only
    needed when switching between processes: the barrier is implied by
    mmdrop() when switching from kernel to userspace, and it's not needed
    when switching from userspace to kernel.
    
    Rely on the feature/mechanism ARCH_HAS_MEMBARRIER_CALLBACKS and on the
    primitive membarrier_arch_switch_mm(), already adopted by the PowerPC
    architecture, to insert the required barrier.
    
    Fixes: fab957c11efe2f ("RISC-V: Atomic and Locking Code")
    Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
    Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Link: https://lore.kernel.org/r/20240131144936.29190-2-parri.andrea@gmail.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    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>

 
misc: fastrpc: Fix double free of 'buf' in error path [+ + +]
Author: Sukrut Bellary <sukrut.bellary@linux.com>
Date:   Mon Sep 2 15:14:09 2024 +0100

    misc: fastrpc: Fix double free of 'buf' in error path
    
    commit e8c276d4dc0e19ee48385f74426aebc855b49aaf upstream.
    
    smatch warning:
    drivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of 'buf'
    
    In fastrpc_req_mmap() error path, the fastrpc buffer is freed in
    fastrpc_req_munmap_impl() if unmap is successful.
    
    But in the end, there is an unconditional call to fastrpc_buf_free().
    So the above case triggers the double free of fastrpc buf.
    
    Fixes: 72fa6f7820c4 ("misc: fastrpc: Rework fastrpc_req_munmap")
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Sukrut Bellary <sukrut.bellary@linux.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240902141409.70371-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/vmscan: use folio_migratetype() instead of get_pageblock_migratetype() [+ + +]
Author: Vern Hao <vernhao@tencent.com>
Date:   Fri Aug 25 15:57:34 2023 +0800

    mm/vmscan: use folio_migratetype() instead of get_pageblock_migratetype()
    
    [ Upstream commit 97144ce008f918249fa7275ee1d29f6f27665c34 ]
    
    In skip_cma(), we can use folio_migratetype() to replace
    get_pageblock_migratetype().
    
    Link: https://lkml.kernel.org/r/20230825075735.52436-1-user@VERNHAO-MC1
    Signed-off-by: Vern Hao <vernhao@tencent.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Cc: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: bfe0857c20c6 ("Revert "mm: skip CMA pages when they are not available"")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm: Introduce pudp/p4dp/pgdp_get() functions [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Wed Dec 13 21:29:59 2023 +0100

    mm: Introduce pudp/p4dp/pgdp_get() functions
    
    commit eba2591d99d1f14a04c8a8a845ab0795b93f5646 upstream.
    
    Instead of directly dereferencing page tables entries, which can cause
    issues (see commit 20a004e7b017 ("arm64: mm: Use READ_ONCE/WRITE_ONCE when
    accessing page tables"), let's introduce new functions to get the
    pud/p4d/pgd entries (the pte and pmd versions already exist).
    
    Note that arm pgd_t is actually an array so pgdp_get() is defined as a
    macro to avoid a build error.
    
    Those new functions will be used in subsequent commits by the riscv
    architecture.
    
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20231213203001.179237-3-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm: vmalloc: ensure vmap_block is initialised before adding to queue [+ + +]
Author: Will Deacon <will@kernel.org>
Date:   Mon Aug 12 18:16:06 2024 +0100

    mm: vmalloc: ensure vmap_block is initialised before adding to queue
    
    commit 3e3de7947c751509027d26b679ecd243bc9db255 upstream.
    
    Commit 8c61291fd850 ("mm: fix incorrect vbq reference in
    purge_fragmented_block") extended the 'vmap_block' structure to contain a
    'cpu' field which is set at allocation time to the id of the initialising
    CPU.
    
    When a new 'vmap_block' is being instantiated by new_vmap_block(), the
    partially initialised structure is added to the local 'vmap_block_queue'
    xarray before the 'cpu' field has been initialised.  If another CPU is
    concurrently walking the xarray (e.g.  via vm_unmap_aliases()), then it
    may perform an out-of-bounds access to the remote queue thanks to an
    uninitialised index.
    
    This has been observed as UBSAN errors in Android:
    
     | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP
     |
     | Call trace:
     |  purge_fragmented_block+0x204/0x21c
     |  _vm_unmap_aliases+0x170/0x378
     |  vm_unmap_aliases+0x1c/0x28
     |  change_memory_common+0x1dc/0x26c
     |  set_memory_ro+0x18/0x24
     |  module_enable_ro+0x98/0x238
     |  do_init_module+0x1b0/0x310
    
    Move the initialisation of 'vb->cpu' in new_vmap_block() ahead of the
    addition to the xarray.
    
    Link: https://lkml.kernel.org/r/20240812171606.17486-1-will@kernel.org
    Fixes: 8c61291fd850 ("mm: fix incorrect vbq reference in purge_fragmented_block")
    Signed-off-by: Will Deacon <will@kernel.org>
    Reviewed-by: Baoquan He <bhe@redhat.com>
    Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Cc: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
    Cc: Hailong.Liu <hailong.liu@oppo.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Lorenzo Stoakes <lstoakes@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: core: apply SD quirks earlier during probe [+ + +]
Author: Jonathan Bell <jonathan@raspberrypi.com>
Date:   Wed Aug 21 08:06:31 2024 +0900

    mmc: core: apply SD quirks earlier during probe
    
    commit 469e5e4713989fdd5e3e502b922e7be0da2464b9 upstream.
    
    Applying MMC_QUIRK_BROKEN_SD_CACHE is broken, as the card's SD quirks are
    referenced in sd_parse_ext_reg_perf() prior to the quirks being initialized
    in mmc_blk_probe().
    
    To fix this problem, let's split out an SD-specific list of quirks and
    apply in mmc_sd_init_card() instead. In this way, sd_read_ext_regs() to has
    the available information for not assigning the SD_EXT_PERF_CACHE as one of
    the (un)supported features, which in turn allows mmc_sd_init_card() to
    properly skip execution of sd_enable_cache().
    
    Fixes: c467c8f08185 ("mmc: Add MMC_QUIRK_BROKEN_SD_CACHE for Kingston Canvas Go Plus from 11/2019")
    Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
    Co-developed-by: Keita Aihara <keita.aihara@sony.com>
    Signed-off-by: Keita Aihara <keita.aihara@sony.com>
    Reviewed-by: Dragan Simic <dsimic@manjaro.org>
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240820230631.GA436523@sony.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
net/socket: Break down __sys_getsockopt [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Mon Oct 16 06:47:42 2023 -0700

    net/socket: Break down __sys_getsockopt
    
    [ Upstream commit 0b05b0cd78c92371fdde6333d006f39eaf9e0860 ]
    
    Split __sys_getsockopt() into two functions by removing the core
    logic into a sub-function (do_sock_getsockopt()). This will avoid
    code duplication when doing the same operation in other callers, for
    instance.
    
    do_sock_getsockopt() will be called by io_uring getsockopt() command
    operation in the following patch.
    
    The same was done for the setsockopt pair.
    
    Suggested-by: Martin KaFai Lau <martin.lau@linux.dev>
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Acked-by: Jakub Kicinski <kuba@kernel.org>
    Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://lore.kernel.org/r/20231016134750.1381153-5-leitao@debian.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: 33f339a1ba54 ("bpf, net: Fix a potential race in do_sock_getsockopt()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/socket: Break down __sys_setsockopt [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Mon Oct 16 06:47:41 2023 -0700

    net/socket: Break down __sys_setsockopt
    
    [ Upstream commit 1406245c29454ff84919736be83e14cdaba7fec1 ]
    
    Split __sys_setsockopt() into two functions by removing the core
    logic into a sub-function (do_sock_setsockopt()). This will avoid
    code duplication when doing the same operation in other callers, for
    instance.
    
    do_sock_setsockopt() will be called by io_uring setsockopt() command
    operation in the following patch.
    
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Jakub Kicinski <kuba@kernel.org>
    Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://lore.kernel.org/r/20231016134750.1381153-4-leitao@debian.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: 33f339a1ba54 ("bpf, net: Fix a potential race in do_sock_getsockopt()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

net: 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: 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: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup [+ + +]
Author: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
Date:   Mon Sep 2 05:43:47 2024 -0700

    net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup
    
    commit b6ecc662037694488bfff7c9fd21c405df8411f2 upstream.
    
    Currently napi_disable() gets called during rxq and txq cleanup,
    even before napi is enabled and hrtimer is initialized. It causes
    kernel panic.
    
    ? page_fault_oops+0x136/0x2b0
      ? page_counter_cancel+0x2e/0x80
      ? do_user_addr_fault+0x2f2/0x640
      ? refill_obj_stock+0xc4/0x110
      ? exc_page_fault+0x71/0x160
      ? asm_exc_page_fault+0x27/0x30
      ? __mmdrop+0x10/0x180
      ? __mmdrop+0xec/0x180
      ? hrtimer_active+0xd/0x50
      hrtimer_try_to_cancel+0x2c/0xf0
      hrtimer_cancel+0x15/0x30
      napi_disable+0x65/0x90
      mana_destroy_rxq+0x4c/0x2f0
      mana_create_rxq.isra.0+0x56c/0x6d0
      ? mana_uncfg_vport+0x50/0x50
      mana_alloc_queues+0x21b/0x320
      ? skb_dequeue+0x5f/0x80
    
    Cc: stable@vger.kernel.org
    Fixes: e1b5683ff62e ("net: mana: Move NAPI from EQ to CQ")
    Signed-off-by: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
    Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: mctp-serial: Fix missing escapes on transmit [+ + +]
Author: Matt Johnston <matt@codeconstruct.com.au>
Date:   Thu Aug 29 15:43:46 2024 +0800

    net: mctp-serial: Fix missing escapes on transmit
    
    commit f962e8361adfa84e8252d3fc3e5e6bb879f029b1 upstream.
    
    0x7d and 0x7e bytes are meant to be escaped in the data portion of
    frames, but this didn't occur since next_chunk_len() had an off-by-one
    error. That also resulted in the final byte of a payload being written
    as a separate tty write op.
    
    The chunk prior to an escaped byte would be one byte short, and the
    next call would never test the txpos+1 case, which is where the escaped
    byte was located. That meant it never hit the escaping case in
    mctp_serial_tx_work().
    
    Example Input: 01 00 08 c8 7e 80 02
    
    Previous incorrect chunks from next_chunk_len():
    
    01 00 08
    c8 7e 80
    02
    
    With this fix:
    
    01 00 08 c8
    7e
    80 02
    
    Cc: stable@vger.kernel.org
    Fixes: a0c2ccd9b5ad ("mctp: Add MCTP-over-serial transport binding")
    Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: microchip: vcap: Fix use-after-free error in kunit test [+ + +]
Author: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
Date:   Thu Aug 29 11:52:54 2024 +0200

    net: microchip: vcap: Fix use-after-free error in kunit test
    
    commit a3c1e45156ad39f225cd7ddae0f81230a3b1e657 upstream.
    
    This is a clear use-after-free error. We remove it, and rely on checking
    the return code of vcap_del_rule.
    
    Reported-by: Dan Carpenter <error27@gmail.com>
    Closes: https://lore.kernel.org/kernel-janitors/7bffefc6-219a-4f71-baa0-ad4526e5c198@kili.mountain/
    Fixes: c956b9b318d9 ("net: microchip: sparx5: Adding KUNIT tests of key/action values in VCAP API")
    Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: phy: Fix missing of_node_put() for leds [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Fri Aug 30 10:20:25 2024 +0800

    net: phy: Fix missing of_node_put() for leds
    
    [ Upstream commit 2560db6ede1aaf162a73b2df43e0b6c5ed8819f7 ]
    
    The call of of_get_child_by_name() will cause refcount incremented
    for leds, if it succeeds, it should call of_node_put() to decrease
    it, fix it.
    
    Fixes: 01e5b728e9e4 ("net: phy: Add a binding for PHY LEDs")
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://patch.msgid.link/20240830022025.610844-1-ruanjinjie@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    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
    
    commit 683408258917541bdb294cd717c210a04381931e upstream.
    
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

nvme-pci: allocate tagset on reset if necessary [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Mon Aug 26 11:20:57 2024 -0700

    nvme-pci: allocate tagset on reset if necessary
    
    [ Upstream commit 6f01bdbfef3b62955cf6503a8425d527b3a5cf94 ]
    
    If a drive is unable to create IO queues on the initial probe, a
    subsequent reset will need to allocate the tagset if IO queue creation
    is successful. Without this, blk_mq_update_nr_hw_queues will crash on a
    bad pointer due to the invalid tagset.
    
    Fixes: eac3ef262941f62 ("nvme-pci: split the initial probe from the rest path")
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
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: 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>

 
perf/x86/intel: Limit the period on Haswell [+ + +]
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Mon Aug 19 11:30:04 2024 -0700

    perf/x86/intel: Limit the period on Haswell
    
    commit 25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b upstream.
    
    Running the ltp test cve-2015-3290 concurrently reports the following
    warnings.
    
    perfevents: irq loop stuck!
      WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174
      intel_pmu_handle_irq+0x285/0x370
      Call Trace:
       <NMI>
       ? __warn+0xa4/0x220
       ? intel_pmu_handle_irq+0x285/0x370
       ? __report_bug+0x123/0x130
       ? intel_pmu_handle_irq+0x285/0x370
       ? __report_bug+0x123/0x130
       ? intel_pmu_handle_irq+0x285/0x370
       ? report_bug+0x3e/0xa0
       ? handle_bug+0x3c/0x70
       ? exc_invalid_op+0x18/0x50
       ? asm_exc_invalid_op+0x1a/0x20
       ? irq_work_claim+0x1e/0x40
       ? intel_pmu_handle_irq+0x285/0x370
       perf_event_nmi_handler+0x3d/0x60
       nmi_handle+0x104/0x330
    
    Thanks to Thomas Gleixner's analysis, the issue is caused by the low
    initial period (1) of the frequency estimation algorithm, which triggers
    the defects of the HW, specifically erratum HSW11 and HSW143. (For the
    details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)
    
    The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL
    event, but the initial period in the freq mode is 1. The erratum is the
    same as the BDM11, which has been supported in the kernel. A minimum
    period of 128 is enforced as well on HSW.
    
    HSW143 is regarding that the fixed counter 1 may overcount 32 with the
    Hyper-Threading is enabled. However, based on the test, the hardware
    has more issues than it tells. Besides the fixed counter 1, the message
    'interrupt took too long' can be observed on any counter which was armed
    with a period < 32 and two events expired in the same NMI. A minimum
    period of 32 is enforced for the rest of the events.
    The recommended workaround code of the HSW143 is not implemented.
    Because it only addresses the issue for the fixed counter. It brings
    extra overhead through extra MSR writing. No related overcounting issue
    has been reported so far.
    
    Fixes: 3a632cb229bf ("perf/x86/intel: Add simple Haswell PMU support")
    Reported-by: Li Huafei <lihuafei1@huawei.com>
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240819183004.3132920-1-kan.liang@linux.intel.com
    Closes: https://lore.kernel.org/lkml/20240729223328.327835-1-lihuafei1@huawei.com/
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
phy: zynqmp: Take the phy mutex in xlate [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Fri Jun 28 16:55:39 2024 -0400

    phy: zynqmp: Take the phy mutex in xlate
    
    [ Upstream commit d79c6840917097285e03a49f709321f5fb972750 ]
    
    Take the phy mutex in xlate to protect against concurrent
    modification/access to gtr_phy. This does not typically cause any
    issues, since in most systems the phys are only xlated once and
    thereafter accessed with the phy API (which takes the locks). However,
    we are about to allow userspace to access phys for debugging, so it's
    important to avoid any data races.
    
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Link: https://lore.kernel.org/r/20240628205540.3098010-5-sean.anderson@linux.dev
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
powerpc/64e: Define mmu_pte_psize static [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Aug 20 14:42:38 2024 +0200

    powerpc/64e: Define mmu_pte_psize static
    
    [ Upstream commit d92b5cc29c792f1d3f0aaa3b29dddfe816c03e88 ]
    
    mmu_pte_psize is only used in the tlb_64e.c, define it static.
    
    Fixes: 25d21ad6e799 ("powerpc: Add TLB management code for 64-bit Book3E")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202408011256.1O99IB0s-lkp@intel.com/
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/beb30d280eaa5d857c38a0834b147dffd6b28aa9.1724157750.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/64e: remove unused IBM HTW code [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Jul 2 15:51:13 2024 +0200

    powerpc/64e: remove unused IBM HTW code
    
    [ Upstream commit 88715b6e5d529f4ef3830ad2a893e4624c6af0b8 ]
    
    Patch series "Reimplement huge pages without hugepd on powerpc (8xx, e500,
    book3s/64)", v7.
    
    Unlike most architectures, powerpc 8xx HW requires a two-level pagetable
    topology for all page sizes.  So a leaf PMD-contig approach is not
    feasible as such.
    
    Possible sizes on 8xx are 4k, 16k, 512k and 8M.
    
    First level (PGD/PMD) covers 4M per entry.  For 8M pages, two PMD entries
    must point to a single entry level-2 page table.  Until now that was done
    using hugepd.  This series changes it to use standard page tables where
    the entry is replicated 1024 times on each of the two pagetables refered
    by the two associated PMD entries for that 8M page.
    
    For e500 and book3s/64 there are less constraints because it is not tied
    to the HW assisted tablewalk like on 8xx, so it is easier to use leaf PMDs
    (and PUDs).
    
    On e500 the supported page sizes are 4M, 16M, 64M, 256M and 1G.  All at
    PMD level on e500/32 (mpc85xx) and mix of PMD and PUD for e500/64.  We
    encode page size with 4 available bits in PTE entries.  On e300/32 PGD
    entries size is increases to 64 bits in order to allow leaf-PMD entries
    because PTE are 64 bits on e500.
    
    On book3s/64 only the hash-4k mode is concerned.  It supports 16M pages as
    cont-PMD and 16G pages as cont-PUD.  In other modes (radix-4k, radix-6k
    and hash-64k) the sizes match with PMD and PUD sizes so that's just leaf
    entries.  The hash processing make things a bit more complex.  To ease
    things, __hash_page_huge() is modified to bail out when DIRTY or ACCESSED
    bits are missing, leaving it to mm core to fix it.
    
    This patch (of 23):
    
    The nohash HTW_IBM (Hardware Table Walk) code is unused since support for
    A2 was removed in commit fb5a515704d7 ("powerpc: Remove platforms/ wsp and
    associated pieces") (2014).
    
    The remaining supported CPUs use either no HTW (data_tlb_miss_bolted), or
    the e6500 HTW (data_tlb_miss_e6500).
    
    Link: https://lkml.kernel.org/r/cover.1719928057.git.christophe.leroy@csgroup.eu
    Link: https://lkml.kernel.org/r/820dd1385ecc931f07b0d7a0fa827b1613917ab6.1719928057.git.christophe.leroy@csgroup.eu
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: Jason Gunthorpe <jgg@nvidia.com>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Peter Xu <peterx@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: d92b5cc29c79 ("powerpc/64e: Define mmu_pte_psize static")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/64e: split out nohash Book3E 64-bit code [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Jul 2 15:51:14 2024 +0200

    powerpc/64e: split out nohash Book3E 64-bit code
    
    [ Upstream commit a898530eea3d0ba08c17a60865995a3bb468d1bc ]
    
    A reasonable chunk of nohash/tlb.c is 64-bit only code, split it out into
    a separate file.
    
    Link: https://lkml.kernel.org/r/cb2b118f9d8a86f82d01bfb9ad309d1d304480a1.1719928057.git.christophe.leroy@csgroup.eu
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: Jason Gunthorpe <jgg@nvidia.com>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Peter Xu <peterx@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: d92b5cc29c79 ("powerpc/64e: Define mmu_pte_psize static")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/qspinlock: Fix deadlock in MCS queue [+ + +]
Author: Nysal Jan K.A. <nysal@linux.ibm.com>
Date:   Thu Aug 29 07:58:27 2024 +0530

    powerpc/qspinlock: Fix deadlock in MCS queue
    
    commit 734ad0af3609464f8f93e00b6c0de1e112f44559 upstream.
    
    If an interrupt occurs in queued_spin_lock_slowpath() after we increment
    qnodesp->count and before node->lock is initialized, another CPU might
    see stale lock values in get_tail_qnode(). If the stale lock value happens
    to match the lock on that CPU, then we write to the "next" pointer of
    the wrong qnode. This causes a deadlock as the former CPU, once it becomes
    the head of the MCS queue, will spin indefinitely until it's "next" pointer
    is set by its successor in the queue.
    
    Running stress-ng on a 16 core (16EC/16VP) shared LPAR, results in
    occasional lockups similar to the following:
    
       $ stress-ng --all 128 --vm-bytes 80% --aggressive \
                   --maximize --oomable --verify  --syslog \
                   --metrics  --times  --timeout 5m
    
       watchdog: CPU 15 Hard LOCKUP
       ......
       NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490
       LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90
       Call Trace:
        0xc000002cfffa3bf0 (unreliable)
        _raw_spin_lock+0x6c/0x90
        raw_spin_rq_lock_nested.part.135+0x4c/0xd0
        sched_ttwu_pending+0x60/0x1f0
        __flush_smp_call_function_queue+0x1dc/0x670
        smp_ipi_demux_relaxed+0xa4/0x100
        xive_muxed_ipi_action+0x20/0x40
        __handle_irq_event_percpu+0x80/0x240
        handle_irq_event_percpu+0x2c/0x80
        handle_percpu_irq+0x84/0xd0
        generic_handle_irq+0x54/0x80
        __do_irq+0xac/0x210
        __do_IRQ+0x74/0xd0
        0x0
        do_IRQ+0x8c/0x170
        hardware_interrupt_common_virt+0x29c/0x2a0
       --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490
       ......
       NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490
       LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90
       --- interrupt: 500
        0xc0000029c1a41d00 (unreliable)
        _raw_spin_lock+0x6c/0x90
        futex_wake+0x100/0x260
        do_futex+0x21c/0x2a0
        sys_futex+0x98/0x270
        system_call_exception+0x14c/0x2f0
        system_call_vectored_common+0x15c/0x2ec
    
    The following code flow illustrates how the deadlock occurs.
    For the sake of brevity, assume that both locks (A and B) are
    contended and we call the queued_spin_lock_slowpath() function.
    
            CPU0                                   CPU1
            ----                                   ----
      spin_lock_irqsave(A)                          |
      spin_unlock_irqrestore(A)                     |
        spin_lock(B)                                |
             |                                      |
             ▼                                      |
       id = qnodesp->count++;                       |
      (Note that nodes[0].lock == A)                |
             |                                      |
             ▼                                      |
          Interrupt                                 |
      (happens before "nodes[0].lock = B")          |
             |                                      |
             ▼                                      |
      spin_lock_irqsave(A)                          |
             |                                      |
             ▼                                      |
       id = qnodesp->count++                        |
       nodes[1].lock = A                            |
             |                                      |
             ▼                                      |
      Tail of MCS queue                             |
             |                             spin_lock_irqsave(A)
             ▼                                      |
      Head of MCS queue                             ▼
             |                             CPU0 is previous tail
             ▼                                      |
       Spin indefinitely                            ▼
      (until "nodes[1].next != NULL")      prev = get_tail_qnode(A, CPU0)
                                                    |
                                                    ▼
                                           prev == &qnodes[CPU0].nodes[0]
                                         (as qnodes[CPU0].nodes[0].lock == A)
                                                    |
                                                    ▼
                                           WRITE_ONCE(prev->next, node)
                                                    |
                                                    ▼
                                            Spin indefinitely
                                         (until nodes[0].locked == 1)
    
    Thanks to Saket Kumar Bhaskar for help with recreating the issue
    
    Fixes: 84990b169557 ("powerpc/qspinlock: add mcs queueing for contended waiters")
    Cc: stable@vger.kernel.org # v6.2+
    Reported-by: Geetika Moolchandani <geetika@linux.ibm.com>
    Reported-by: Vaishnavi Bhat <vaish123@in.ibm.com>
    Reported-by: Jijo Varghese <vargjijo@in.ibm.com>
    Signed-off-by: Nysal Jan K.A. <nysal@linux.ibm.com>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240829022830.1164355-1-nysal@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/vdso: Don't discard rela sections [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Aug 20 13:28:07 2024 +0200

    powerpc/vdso: Don't discard rela sections
    
    [ Upstream commit 6114139c3bdde992f4a19264e4f9bfc100d8d776 ]
    
    After building the VDSO, there is a verification that it contains
    no dynamic relocation, see commit aff69273af61 ("vdso: Improve
    cmd_vdso_check to check all dynamic relocations").
    
    This verification uses readelf -r and doesn't work if rela sections
    are discarded.
    
    Fixes: 8ad57add77d3 ("powerpc/build: vdso linker warning for orphan sections")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/45c3e6fc76cad05ad2cac0f5b5dfb4fae86dc9d6.1724153239.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
r8152: fix the firmware doesn't work [+ + +]
Author: Hayes Wang <hayeswang@realtek.com>
Date:   Tue Sep 3 14:33:33 2024 +0800

    r8152: fix the firmware doesn't work
    
    [ Upstream commit 8487b4af59d4d7feda4b119dc2d92c67ca25c27e ]
    
    generic_ocp_write() asks the parameter "size" must be 4 bytes align.
    Therefore, write the bp would fail, if the mac->bp_num is odd. Align the
    size to 4 for fixing it. The way may write an extra bp, but the
    rtl8152_is_fw_mac_ok() makes sure the value must be 0 for the bp whose
    index is more than mac->bp_num. That is, there is no influence for the
    firmware.
    
    Besides, I check the return value of generic_ocp_write() to make sure
    everything is correct.
    
    Fixes: e5c266a61186 ("r8152: set bp in bulk")
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Link: https://patch.msgid.link/20240903063333.4502-1-hayeswang@realtek.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regmap: maple: work around gcc-14.1 false-positive warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jul 19 12:40:24 2024 +0200

    regmap: maple: work around gcc-14.1 false-positive warning
    
    [ Upstream commit 542440fd7b30983cae23e32bd22f69a076ec7ef4 ]
    
    With gcc-14.1, there is a false-postive -Wuninitialized warning in
    regcache_maple_drop:
    
    drivers/base/regmap/regcache-maple.c: In function 'regcache_maple_drop':
    drivers/base/regmap/regcache-maple.c:113:23: error: 'lower_index' is used uninitialized [-Werror=uninitialized]
      113 |         unsigned long lower_index, lower_last;
          |                       ^~~~~~~~~~~
    drivers/base/regmap/regcache-maple.c:113:36: error: 'lower_last' is used uninitialized [-Werror=uninitialized]
      113 |         unsigned long lower_index, lower_last;
          |                                    ^~~~~~~~~~
    
    I've created a reduced test case to see if this needs to be reported
    as a gcc, but it appears that the gcc-14.x branch already has a change
    that turns this into a more sensible -Wmaybe-uninitialized warning, so
    I ended up not reporting it so far.
    
    The reduced test case also produces a warning for gcc-13 and gcc-12
    but I don't see that with the version in the kernel.
    
    Link: https://godbolt.org/z/oKbohKqd3
    Link: https://lore.kernel.org/all/CAMuHMdWj=FLmkazPbYKPevDrcym2_HDb_U7Mb9YE9ovrP0jJfA@mail.gmail.com/
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://patch.msgid.link/20240719104030.1382465-1-arnd@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: core: Stub devm_regulator_bulk_get_const() if !CONFIG_REGULATOR [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Fri Aug 30 07:35:12 2024 -0700

    regulator: core: Stub devm_regulator_bulk_get_const() if !CONFIG_REGULATOR
    
    [ Upstream commit 1a5caec7f80ca2e659c03f45378ee26915f4eda2 ]
    
    When adding devm_regulator_bulk_get_const() I missed adding a stub for
    when CONFIG_REGULATOR is not enabled. Under certain conditions (like
    randconfig testing) this can cause the compiler to reports errors
    like:
    
      error: implicit declaration of function 'devm_regulator_bulk_get_const';
      did you mean 'devm_regulator_bulk_get_enable'?
    
    Add the stub.
    
    Fixes: 1de452a0edda ("regulator: core: Allow drivers to define their init data as const")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202408301813.TesFuSbh-lkp@intel.com/
    Cc: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patch.msgid.link/20240830073511.1.Ib733229a8a19fad8179213c05e1af01b51e42328@changeid
    Signed-off-by: Mark Brown <broonie@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>

 
Revert "drm/amdgpu: align pp_power_profile_mode with kernel docs" [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Sep 5 14:24:38 2024 -0400

    Revert "drm/amdgpu: align pp_power_profile_mode with kernel docs"
    
    commit 1a8d845470941f1b6de1b392227530c097dc5e0c upstream.
    
    This reverts commit 8f614469de248a4bc55fb07e55d5f4c340c75b11.
    
    This breaks some manual setting of the profile mode in
    certain cases.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3600
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 7a199557643e993d4e7357860624b8aa5d8f4340)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "mm: skip CMA pages when they are not available" [+ + +]
Author: Usama Arif <usamaarif642@gmail.com>
Date:   Wed Aug 21 20:26:07 2024 +0100

    Revert "mm: skip CMA pages when they are not available"
    
    [ Upstream commit bfe0857c20c663fcc1592fa4e3a61ca12b07dac9 ]
    
    This reverts commit 5da226dbfce3 ("mm: skip CMA pages when they are not
    available") and b7108d66318a ("Multi-gen LRU: skip CMA pages when they are
    not eligible").
    
    lruvec->lru_lock is highly contended and is held when calling
    isolate_lru_folios.  If the lru has a large number of CMA folios
    consecutively, while the allocation type requested is not MIGRATE_MOVABLE,
    isolate_lru_folios can hold the lock for a very long time while it skips
    those.  For FIO workload, ~150million order=0 folios were skipped to
    isolate a few ZONE_DMA folios [1].  This can cause lockups [1] and high
    memory pressure for extended periods of time [2].
    
    Remove skipping CMA for MGLRU as well, as it was introduced in sort_folio
    for the same resaon as 5da226dbfce3a2f44978c2c7cf88166e69a6788b.
    
    [1] https://lore.kernel.org/all/CAOUHufbkhMZYz20aM_3rHZ3OcK4m2puji2FGpUpn_-DevGk3Kg@mail.gmail.com/
    [2] https://lore.kernel.org/all/ZrssOrcJIDy8hacI@gmail.com/
    
    [usamaarif642@gmail.com: also revert b7108d66318a, per Johannes]
      Link: https://lkml.kernel.org/r/9060a32d-b2d7-48c0-8626-1db535653c54@gmail.com
      Link: https://lkml.kernel.org/r/357ac325-4c61-497a-92a3-bdbd230d5ec9@gmail.com
    Link: https://lkml.kernel.org/r/9060a32d-b2d7-48c0-8626-1db535653c54@gmail.com
    Fixes: 5da226dbfce3 ("mm: skip CMA pages when they are not available")
    Signed-off-by: Usama Arif <usamaarif642@gmail.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Bharata B Rao <bharata@amd.com>
    Cc: Breno Leitao <leitao@debian.org>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Yu Zhao <yuzhao@google.com>
    Cc: Zhaoyang Huang <huangzhaoyang@gmail.com>
    Cc: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
riscv: Do not restrict memory size because of linear mapping on nommu [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Tue Aug 27 08:52:30 2024 +0200

    riscv: Do not restrict memory size because of linear mapping on nommu
    
    [ Upstream commit 5f771088a2b5edd6f2c5c9f34484ca18dc389f3e ]
    
    It makes no sense to restrict physical memory size because of linear
    mapping size constraints when there is no linear mapping, so only do
    that when mmu is enabled.
    
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Closes: https://lore.kernel.org/linux-riscv/CAMuHMdW0bnJt5GMRtOZGkTiM7GK4UaLJCDMF_Ouq++fnDKi3_A@mail.gmail.com/
    Fixes: 3b6564427aea ("riscv: Fix linear mapping checks for non-contiguous memory regions")
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20240827065230.145021-1-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: Fix toolchain vector detection [+ + +]
Author: Anton Blanchard <antonb@tenstorrent.com>
Date:   Mon Aug 19 00:11:31 2024 +0000

    riscv: Fix toolchain vector detection
    
    [ Upstream commit 5ba7a75a53dffbf727e842b5847859bb482ac4aa ]
    
    A recent change to gcc flags rv64iv as no longer valid:
    
       cc1: sorry, unimplemented: Currently the 'V' implementation
       requires the 'M' extension
    
    and as a result vector support is disabled. Fix this by adding m
    to our toolchain vector detection code.
    
    Signed-off-by: Anton Blanchard <antonb@tenstorrent.com>
    Fixes: fa8e7cce55da ("riscv: Enable Vector code to be built")
    Link: https://lore.kernel.org/r/20240819001131.1738806-1-antonb@tenstorrent.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: kprobes: Use patch_text_nosync() for insn slots [+ + +]
Author: Samuel Holland <samuel.holland@sifive.com>
Date:   Wed Mar 27 09:04:42 2024 -0700

    riscv: kprobes: Use patch_text_nosync() for insn slots
    
    [ Upstream commit b1756750a397f36ddc857989d31887c3f5081fb0 ]
    
    These instructions are not yet visible to the rest of the system,
    so there is no need to do the whole stop_machine() dance.
    
    Reviewed-by: Björn Töpel <bjorn@rivosinc.com>
    Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
    Link: https://lore.kernel.org/r/20240327160520.791322-4-samuel.holland@sifive.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: mm: Only compile pgtable.c if MMU [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Wed Dec 13 21:30:00 2023 +0100

    riscv: mm: Only compile pgtable.c if MMU
    
    commit d6508999d1882ddd0db8b3b4bd7967d83e9909fa upstream.
    
    All functions defined in there depend on MMU, so no need to compile it
    for !MMU configs.
    
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20231213203001.179237-4-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.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>

riscv: Use accessors to page table entries instead of direct dereference [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Wed Dec 13 21:30:01 2023 +0100

    riscv: Use accessors to page table entries instead of direct dereference
    
    commit edf955647269422e387732870d04fc15933a25ea upstream.
    
    As very well explained in commit 20a004e7b017 ("arm64: mm: Use
    READ_ONCE/WRITE_ONCE when accessing page tables"), an architecture whose
    page table walker can modify the PTE in parallel must use
    READ_ONCE()/WRITE_ONCE() macro to avoid any compiler transformation.
    
    So apply that to riscv which is such architecture.
    
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Acked-by: Anup Patel <anup@brainfault.org>
    Link: https://lore.kernel.org/r/20231213203001.179237-5-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

riscv: Use WRITE_ONCE() when setting page table entries [+ + +]
Author: Alexandre Ghiti <alexghiti@rivosinc.com>
Date:   Wed Dec 13 21:29:58 2023 +0100

    riscv: Use WRITE_ONCE() when setting page table entries
    
    commit c30fa83b49897e708a52e122dd10616a52a4c82b upstream.
    
    To avoid any compiler "weirdness" when accessing page table entries which
    are concurrently modified by the HW, let's use WRITE_ONCE() macro
    (commit 20a004e7b017 ("arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing
    page tables") gives a great explanation with more details).
    
    Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20231213203001.179237-2-alexghiti@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
rust: kbuild: fix export of bss symbols [+ + +]
Author: Andreas Hindborg <a.hindborg@kernel.org>
Date:   Thu Aug 15 07:49:30 2024 +0000

    rust: kbuild: fix export of bss symbols
    
    [ Upstream commit b8673d56935c32a4e0a1a0b40951fdd313dbf340 ]
    
    Symbols in the bss segment are not currently exported. This is a problem
    for Rust modules that link against statics, that are resident in the kernel
    image. Thus export symbols in the bss segment.
    
    Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support")
    Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Tested-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Gary Guo <gary@garyguo.net>
    Link: https://lore.kernel.org/r/20240815074519.2684107-2-nmi@metaspace.dk
    [ Reworded slightly. - Miguel ]
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rust: macros: provide correct provenance when constructing THIS_MODULE [+ + +]
Author: Boqun Feng <boqun.feng@gmail.com>
Date:   Wed Aug 28 11:01:29 2024 -0700

    rust: macros: provide correct provenance when constructing THIS_MODULE
    
    commit a5a3c952e82c1ada12bf8c55b73af26f1a454bd2 upstream.
    
    Currently while defining `THIS_MODULE` symbol in `module!()`, the
    pointer used to construct `ThisModule` is derived from an immutable
    reference of `__this_module`, which means the pointer doesn't have
    the provenance for writing, and that means any write to that pointer
    is UB regardless of data races or not. However, the usage of
    `THIS_MODULE` includes passing this pointer to functions that may write
    to it (probably in unsafe code), and this will create soundness issues.
    
    One way to fix this is using `addr_of_mut!()` but that requires the
    unstable feature "const_mut_refs". So instead of `addr_of_mut()!`,
    an extern static `Opaque` is used here: since `Opaque<T>` is transparent
    to `T`, an extern static `Opaque` will just wrap the C symbol (defined
    in a C compile unit) in an `Opaque`, which provides a pointer with
    writable provenance via `Opaque::get()`. This fix the potential UBs
    because of pointer provenance unmatched.
    
    Reported-by: Alice Ryhl <aliceryhl@google.com>
    Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Trevor Gross <tmgross@umich.edu>
    Reviewed-by: Benno Lossin <benno.lossin@proton.me>
    Reviewed-by: Gary Guo <gary@garyguo.net>
    Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/465412664
    Fixes: 1fbde52bde73 ("rust: add `macros` crate")
    Cc: stable@vger.kernel.org # 6.6.x: be2ca1e03965: ("rust: types: Make Opaque::get const")
    Link: https://lore.kernel.org/r/20240828180129.4046355-1-boqun.feng@gmail.com
    [ Fixed two typos, reworded title. - Miguel ]
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: types: Make Opaque::get const [+ + +]
Author: Boqun Feng <boqun.feng@gmail.com>
Date:   Mon Apr 1 14:45:36 2024 -0700

    rust: types: Make Opaque::get const
    
    commit be2ca1e03965ffb214b6cbda0ffd84daeeb5f214 upstream.
    
    To support a potential usage:
    
        static foo: Opaque<Foo> = ..; // Or defined in an extern block.
    
        ...
    
        fn bar() {
            let ptr = foo.get();
        }
    
    `Opaque::get` need to be `const`, otherwise compiler will complain
    because calls on statics are limited to const functions.
    
    Also `Opaque::get` should be naturally `const` since it's a composition
    of two `const` functions: `UnsafeCell::get` and `ptr::cast`.
    
    Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Wedson Almeida Filho <walmeida@microsoft.com>
    Reviewed-by: Benno Lossin <benno.lossin@proton.me>
    Link: https://lore.kernel.org/r/20240401214543.1242286-1-boqun.feng@gmail.com
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rust: Use awk instead of recent xargs [+ + +]
Author: Matthew Maurer <mmaurer@google.com>
Date:   Thu Sep 28 20:49:25 2023 +0000

    rust: Use awk instead of recent xargs
    
    [ Upstream commit 45f97e6385cad6d0e48a27ddcd08793bb4d35851 ]
    
    `awk` is already required by the kernel build, and the `xargs` feature
    used in current Rust detection is not present in all `xargs` (notably,
    toybox based xargs, used in the Android kernel build).
    
    Signed-off-by: Matthew Maurer <mmaurer@google.com>
    Reviewed-by: Alice Ryhl <aliceryhl@google.com>
    Tested-by: Alice Ryhl <aliceryhl@google.com>
    Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
    Link: https://lore.kernel.org/r/20230928205045.2375899-1-mmaurer@google.com
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Stable-dep-of: b8673d56935c ("rust: kbuild: fix export of bss symbols")
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
scsi: pm80xx: Set phy->enable_completion only when we wait for it [+ + +]
Author: Igor Pylypiv <ipylypiv@google.com>
Date:   Thu Jun 27 15:59:23 2024 +0000

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

scsi: ufs: core: Remove SCSI host only if added [+ + +]
Author: Kyoungrul Kim <k831.kim@samsung.com>
Date:   Thu Jun 27 17:51:04 2024 +0900

    scsi: ufs: core: Remove SCSI host only if added
    
    [ Upstream commit 7cbff570dbe8907e23bba06f6414899a0fbb2fcc ]
    
    If host tries to remove ufshcd driver from a UFS device it would cause a
    kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before
    adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host
    has been defered after MCQ configuration introduced by commit 0cab4023ec7b
    ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported").
    
    To guarantee that SCSI host is removed only if it has been added, set the
    scsi_host_added flag to true after adding a SCSI host and check whether it
    is set or not before removing it.
    
    Signed-off-by: Kyoungrul Kim <k831.kim@samsung.com>
    Signed-off-by: Minwoo Im <minwoo.im@samsung.com>
    Link: https://lore.kernel.org/r/20240627085104epcms2p5897a3870ea5c6416aa44f94df6c543d7@epcms2p5
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: net: enable bind tests [+ + +]
Author: Jamie Bainbridge <jamie.bainbridge@gmail.com>
Date:   Wed Sep 4 16:12:26 2024 +1000

    selftests: net: enable bind tests
    
    [ Upstream commit e4af74a53b7aa865e7fcc104630ebb7a9129b71f ]
    
    bind_wildcard is compiled but not run, bind_timewait is not compiled.
    
    These two tests complete in a very short time, use the test harness
    properly, and seem reasonable to enable.
    
    The author of the tests confirmed via email that these were
    intended to be run.
    
    Enable these two tests.
    
    Fixes: 13715acf8ab5 ("selftest: Add test for bind() conflicts.")
    Fixes: 2c042e8e54ef ("tcp: Add selftest for bind() and TIME_WAIT.")
    Signed-off-by: Jamie Bainbridge <jamie.bainbridge@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://patch.msgid.link/5a009b26cf5fb1ad1512d89c61b37e2fac702323.1725430322.git.jamie.bainbridge@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    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>

 
smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open() [+ + +]
Author: ChenXiaoSong <chenxiaosong@kylinos.cn>
Date:   Thu Aug 22 08:20:51 2024 +0000

    smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()
    
    [ Upstream commit 4e8771a3666c8f216eefd6bd2fd50121c6c437db ]
    
    null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)
    and parse_lease_state() return NULL.
    
    Fix this by check if 'lease_ctx_info' is NULL.
    
    Additionally, remove the redundant parentheses in
    parse_durable_handle_context().
    
    Signed-off-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
smb: client: fix double put of @cfile in smb2_rename_path() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Tue Sep 3 10:53:23 2024 -0300

    smb: client: fix double put of @cfile in smb2_rename_path()
    
    [ Upstream commit 3523a3df03c6f04f7ea9c2e7050102657e331a4f ]
    
    If smb2_set_path_attr() is called with a valid @cfile and returned
    -EINVAL, we need to call cifs_get_writable_path() again as the
    reference of @cfile was already dropped by previous smb2_compound_op()
    call.
    
    Fixes: 71f15c90e785 ("smb: client: retry compound request without reusing lease")
    Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
    Cc: David Howells <dhowells@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

smb: client: fix double put of @cfile in smb2_set_path_size() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Tue Sep 3 10:53:24 2024 -0300

    smb: client: fix double put of @cfile in smb2_set_path_size()
    
    commit f9c169b51b6ce20394594ef674d6b10efba31220 upstream.
    
    If smb2_compound_op() is called with a valid @cfile and returned
    -EINVAL, we need to call cifs_get_writable_path() before retrying it
    as the reference of @cfile was already dropped by previous call.
    
    This fixes the following KASAN splat when running fstests generic/013
    against Windows Server 2022:
    
      CIFS: Attempting to mount //w22-fs0/scratch
      run fstests generic/013 at 2024-09-02 19:48:59
      ==================================================================
      BUG: KASAN: slab-use-after-free in detach_if_pending+0xab/0x200
      Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176
    
      CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40
      04/01/2014
      Workqueue: cifsoplockd cifs_oplock_break [cifs]
      Call Trace:
       <TASK>
       dump_stack_lvl+0x5d/0x80
       ? detach_if_pending+0xab/0x200
       print_report+0x156/0x4d9
       ? detach_if_pending+0xab/0x200
       ? __virt_addr_valid+0x145/0x300
       ? __phys_addr+0x46/0x90
       ? detach_if_pending+0xab/0x200
       kasan_report+0xda/0x110
       ? detach_if_pending+0xab/0x200
       detach_if_pending+0xab/0x200
       timer_delete+0x96/0xe0
       ? __pfx_timer_delete+0x10/0x10
       ? rcu_is_watching+0x20/0x50
       try_to_grab_pending+0x46/0x3b0
       __cancel_work+0x89/0x1b0
       ? __pfx___cancel_work+0x10/0x10
       ? kasan_save_track+0x14/0x30
       cifs_close_deferred_file+0x110/0x2c0 [cifs]
       ? __pfx_cifs_close_deferred_file+0x10/0x10 [cifs]
       ? __pfx_down_read+0x10/0x10
       cifs_oplock_break+0x4c1/0xa50 [cifs]
       ? __pfx_cifs_oplock_break+0x10/0x10 [cifs]
       ? lock_is_held_type+0x85/0xf0
       ? mark_held_locks+0x1a/0x90
       process_one_work+0x4c6/0x9f0
       ? find_held_lock+0x8a/0xa0
       ? __pfx_process_one_work+0x10/0x10
       ? lock_acquired+0x220/0x550
       ? __list_add_valid_or_report+0x37/0x100
       worker_thread+0x2e4/0x570
       ? __kthread_parkme+0xd1/0xf0
       ? __pfx_worker_thread+0x10/0x10
       kthread+0x17f/0x1c0
       ? kthread+0xda/0x1c0
       ? __pfx_kthread+0x10/0x10
       ret_from_fork+0x31/0x60
       ? __pfx_kthread+0x10/0x10
       ret_from_fork_asm+0x1a/0x30
       </TASK>
    
      Allocated by task 1118:
       kasan_save_stack+0x30/0x50
       kasan_save_track+0x14/0x30
       __kasan_kmalloc+0xaa/0xb0
       cifs_new_fileinfo+0xc8/0x9d0 [cifs]
       cifs_atomic_open+0x467/0x770 [cifs]
       lookup_open.isra.0+0x665/0x8b0
       path_openat+0x4c3/0x1380
       do_filp_open+0x167/0x270
       do_sys_openat2+0x129/0x160
       __x64_sys_creat+0xad/0xe0
       do_syscall_64+0xbb/0x1d0
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
      Freed by task 83:
       kasan_save_stack+0x30/0x50
       kasan_save_track+0x14/0x30
       kasan_save_free_info+0x3b/0x70
       poison_slab_object+0xe9/0x160
       __kasan_slab_free+0x32/0x50
       kfree+0xf2/0x300
       process_one_work+0x4c6/0x9f0
       worker_thread+0x2e4/0x570
       kthread+0x17f/0x1c0
       ret_from_fork+0x31/0x60
       ret_from_fork_asm+0x1a/0x30
    
      Last potentially related work creation:
       kasan_save_stack+0x30/0x50
       __kasan_record_aux_stack+0xad/0xc0
       insert_work+0x29/0xe0
       __queue_work+0x5ea/0x760
       queue_work_on+0x6d/0x90
       _cifsFileInfo_put+0x3f6/0x770 [cifs]
       smb2_compound_op+0x911/0x3940 [cifs]
       smb2_set_path_size+0x228/0x270 [cifs]
       cifs_set_file_size+0x197/0x460 [cifs]
       cifs_setattr+0xd9c/0x14b0 [cifs]
       notify_change+0x4e3/0x740
       do_truncate+0xfa/0x180
       vfs_truncate+0x195/0x200
       __x64_sys_truncate+0x109/0x150
       do_syscall_64+0xbb/0x1d0
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: 71f15c90e785 ("smb: client: retry compound request without reusing lease")
    Cc: stable@vger.kernel.org
    Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
    Cc: David Howells <dhowells@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware [+ + +]
Author: Devyn Liu <liudingyuan@huawei.com>
Date:   Tue Jul 30 11:20:40 2024 +0800

    spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware
    
    [ Upstream commit 5127c42c77de18651aa9e8e0a3ced190103b449c ]
    
    If the value of max_speed_hz is 0, it may cause a division by zero
    error in hisi_calc_effective_speed().
    The value of max_speed_hz is provided by firmware.
    Firmware is generally considered as a trusted domain. However, as
    division by zero errors can cause system failure, for defense measure,
    the value of max_speed is validated here. So 0 is regarded as invalid
    and an error code is returned.
    
    Signed-off-by: Devyn Liu <liudingyuan@huawei.com>
    Reviewed-by: Jay Fang <f.fangjian@huawei.com>
    Link: https://patch.msgid.link/20240730032040.3156393-3-liudingyuan@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: rockchip: Resolve unbalanced runtime PM / system PM handling [+ + +]
Author: Brian Norris <briannorris@chromium.org>
Date:   Tue Aug 27 10:11:16 2024 -0700

    spi: rockchip: Resolve unbalanced runtime PM / system PM handling
    
    commit be721b451affbecc4ba4eaac3b71cdbdcade1b1b upstream.
    
    Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during
    NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and
    simply disabled clocks unconditionally when suspending the system. This
    causes problems when the device is already runtime suspended when we go
    to sleep -- in which case we double-disable clocks and produce a
    WARNing.
    
    Switch back to pm_runtime_force_{suspend,resume}(), because that still
    seems like the right thing to do, and the aforementioned commit makes no
    explanation why it stopped using it.
    
    Also, refactor some of the resume() error handling, because it's not
    actually a good idea to re-disable clocks on failure.
    
    Fixes: e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops")
    Cc: stable@vger.kernel.org
    Reported-by: Ondřej Jirman <megi@xff.cz>
    Closes: https://lore.kernel.org/lkml/20220621154218.sau54jeij4bunf56@core/
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Link: https://patch.msgid.link/20240827171126.1115748-1-briannorris@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: spi-fsl-lpspi: Fix off-by-one in prescale max [+ + +]
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Thu Sep 5 13:15:37 2024 +0200

    spi: spi-fsl-lpspi: Fix off-by-one in prescale max
    
    commit ff949d981c775332be94be70397ee1df20bc68e5 upstream.
    
    The commit 783bf5d09f86 ("spi: spi-fsl-lpspi: limit PRESCALE bit in
    TCR register") doesn't implement the prescaler maximum as intended.
    The maximum allowed value for i.MX93 should be 1 and for i.MX7ULP
    it should be 7. So this needs also a adjustment of the comparison
    in the scldiv calculation.
    
    Fixes: 783bf5d09f86 ("spi: spi-fsl-lpspi: limit PRESCALE bit in TCR register")
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://patch.msgid.link/20240905111537.90389-1-wahrenst@gmx.net
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: spi-fsl-lpspi: limit PRESCALE bit in TCR register [+ + +]
Author: Carlos Song <carlos.song@nxp.com>
Date:   Tue Aug 20 15:06:58 2024 +0800

    spi: spi-fsl-lpspi: limit PRESCALE bit in TCR register
    
    [ Upstream commit 783bf5d09f86b9736605f3e01a3472e55ef98ff8 ]
    
    Referring to the errata ERR051608 of I.MX93, LPSPI TCR[PRESCALE]
    can only be configured to be 0 or 1, other values are not valid
    and will cause LPSPI to not work.
    
    Add the prescale limitation for LPSPI in I.MX93. Other platforms
    are not affected.
    
    Signed-off-by: Carlos Song <carlos.song@nxp.com>
    Link: https://patch.msgid.link/20240820070658.672127-1-carlos.song@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    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: Don't drop SYN+ACK for simultaneous connect(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Wed Jul 10 10:12:45 2024 -0700

    tcp: Don't drop SYN+ACK for simultaneous connect().
    
    [ Upstream commit 23e89e8ee7be73e21200947885a6d3a109a2c58d ]
    
    RFC 9293 states that in the case of simultaneous connect(), the connection
    gets established when SYN+ACK is received. [0]
    
          TCP Peer A                                       TCP Peer B
    
      1.  CLOSED                                           CLOSED
      2.  SYN-SENT     --> <SEQ=100><CTL=SYN>              ...
      3.  SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT
      4.               ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED
      5.  SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
      6.  ESTABLISHED  <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
      7.               ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED
    
    However, since commit 0c24604b68fc ("tcp: implement RFC 5961 4.2"), such a
    SYN+ACK is dropped in tcp_validate_incoming() and responded with Challenge
    ACK.
    
    For example, the write() syscall in the following packetdrill script fails
    with -EAGAIN, and wrong SNMP stats get incremented.
    
       0 socket(..., SOCK_STREAM|SOCK_NONBLOCK, IPPROTO_TCP) = 3
      +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
    
      +0 > S  0:0(0) <mss 1460,sackOK,TS val 1000 ecr 0,nop,wscale 8>
      +0 < S  0:0(0) win 1000 <mss 1000>
      +0 > S. 0:0(0) ack 1 <mss 1460,sackOK,TS val 3308134035 ecr 0,nop,wscale 8>
      +0 < S. 0:0(0) ack 1 win 1000
    
      +0 write(3, ..., 100) = 100
      +0 > P. 1:101(100) ack 1
    
      --
    
      # packetdrill cross-synack.pkt
      cross-synack.pkt:13: runtime error in write call: Expected result 100 but got -1 with errno 11 (Resource temporarily unavailable)
      # nstat
      ...
      TcpExtTCPChallengeACK           1                  0.0
      TcpExtTCPSYNChallenge           1                  0.0
    
    The problem is that bpf_skops_established() is triggered by the Challenge
    ACK instead of SYN+ACK.  This causes the bpf prog to miss the chance to
    check if the peer supports a TCP option that is expected to be exchanged
    in SYN and SYN+ACK.
    
    Let's accept a bare SYN+ACK for active-open TCP_SYN_RECV sockets to avoid
    such a situation.
    
    Note that tcp_ack_snd_check() in tcp_rcv_state_process() is skipped not to
    send an unnecessary ACK, but this could be a bit risky for net.git, so this
    targets for net-next.
    
    Link: https://www.rfc-editor.org/rfc/rfc9293.html#section-3.5-7 [0]
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20240710171246.87533-2-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: process the 3rd ACK with sk_socket for TFO/MPTCP [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Wed Jul 24 12:25:16 2024 +0200

    tcp: process the 3rd ACK with sk_socket for TFO/MPTCP
    
    commit c1668292689ad2ee16c9c1750a8044b0b0aad663 upstream.
    
    The 'Fixes' commit recently changed the behaviour of TCP by skipping the
    processing of the 3rd ACK when a sk->sk_socket is set. The goal was to
    skip tcp_ack_snd_check() in tcp_rcv_state_process() not to send an
    unnecessary ACK in case of simultaneous connect(). Unfortunately, that
    had an impact on TFO and MPTCP.
    
    I started to look at the impact on MPTCP, because the MPTCP CI found
    some issues with the MPTCP Packetdrill tests [1]. Then Paolo Abeni
    suggested me to look at the impact on TFO with "plain" TCP.
    
    For MPTCP, when receiving the 3rd ACK of a request adding a new path
    (MP_JOIN), sk->sk_socket will be set, and point to the MPTCP sock that
    has been created when the MPTCP connection got established before with
    the first path. The newly added 'goto' will then skip the processing of
    the segment text (step 7) and not go through tcp_data_queue() where the
    MPTCP options are validated, and some actions are triggered, e.g.
    sending the MPJ 4th ACK [2] as demonstrated by the new errors when
    running a packetdrill test [3] establishing a second subflow.
    
    This doesn't fully break MPTCP, mainly the 4th MPJ ACK that will be
    delayed. Still, we don't want to have this behaviour as it delays the
    switch to the fully established mode, and invalid MPTCP options in this
    3rd ACK will not be caught any more. This modification also affects the
    MPTCP + TFO feature as well, and being the reason why the selftests
    started to be unstable the last few days [4].
    
    For TFO, the existing 'basic-cookie-not-reqd' test [5] was no longer
    passing: if the 3rd ACK contains data, and the connection is accept()ed
    before receiving them, these data would no longer be processed, and thus
    not ACKed.
    
    One last thing about MPTCP, in case of simultaneous connect(), a
    fallback to TCP will be done, which seems fine:
    
      `../common/defaults.sh`
    
       0 socket(..., SOCK_STREAM|SOCK_NONBLOCK, IPPROTO_MPTCP) = 3
      +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
    
      +0 > S  0:0(0)                 <mss 1460, sackOK, TS val 100 ecr 0,   nop, wscale 8, mpcapable v1 flags[flag_h] nokey>
      +0 < S  0:0(0) win 1000        <mss 1460, sackOK, TS val 407 ecr 0,   nop, wscale 8, mpcapable v1 flags[flag_h] nokey>
      +0 > S. 0:0(0) ack 1           <mss 1460, sackOK, TS val 330 ecr 0,   nop, wscale 8, mpcapable v1 flags[flag_h] nokey>
      +0 < S. 0:0(0) ack 1 win 65535 <mss 1460, sackOK, TS val 700 ecr 100, nop, wscale 8, mpcapable v1 flags[flag_h] key[skey=2]>
      +0 >  . 1:1(0) ack 1           <nop, nop, TS val 845707014 ecr 700, nop, nop, sack 0:1>
    
    Simultaneous SYN-data crossing is also not supported by TFO, see [6].
    
    Kuniyuki Iwashima suggested to restrict the processing to SYN+ACK only:
    that's a more generic solution than the one initially proposed, and
    also enough to fix the issues described above.
    
    Later on, Eric Dumazet mentioned that an ACK should still be sent in
    reaction to the second SYN+ACK that is received: not sending a DUPACK
    here seems wrong and could hurt:
    
       0 socket(..., SOCK_STREAM|SOCK_NONBLOCK, IPPROTO_TCP) = 3
      +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
    
      +0 > S  0:0(0)                <mss 1460, sackOK, TS val 1000 ecr 0,nop,wscale 8>
      +0 < S  0:0(0)       win 1000 <mss 1000, sackOK, nop, nop>
      +0 > S. 0:0(0) ack 1          <mss 1460, sackOK, TS val 3308134035 ecr 0,nop,wscale 8>
      +0 < S. 0:0(0) ack 1 win 1000 <mss 1000, sackOK, nop, nop>
      +0 >  . 1:1(0) ack 1          <nop, nop, sack 0:1>  // <== Here
    
    So in this version, the 'goto consume' is dropped, to always send an ACK
    when switching from TCP_SYN_RECV to TCP_ESTABLISHED. This ACK will be
    seen as a DUPACK -- with DSACK if SACK has been negotiated -- in case of
    simultaneous SYN crossing: that's what is expected here.
    
    Link: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/9936227696 [1]
    Link: https://datatracker.ietf.org/doc/html/rfc8684#fig_tokens [2]
    Link: https://github.com/multipath-tcp/packetdrill/blob/mptcp-net-next/gtests/net/mptcp/syscalls/accept.pkt#L28 [3]
    Link: https://netdev.bots.linux.dev/contest.html?executor=vmksft-mptcp-dbg&test=mptcp-connect-sh [4]
    Link: https://github.com/google/packetdrill/blob/master/gtests/net/tcp/fastopen/server/basic-cookie-not-reqd.pkt#L21 [5]
    Link: https://github.com/google/packetdrill/blob/master/gtests/net/tcp/fastopen/client/simultaneous-fast-open.pkt [6]
    Fixes: 23e89e8ee7be ("tcp: Don't drop SYN+ACK for simultaneous connect().")
    Suggested-by: Paolo Abeni <pabeni@redhat.com>
    Suggested-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20240724-upstream-net-next-20240716-tcp-3rd-ack-consume-sk_socket-v3-1-d48339764ce9@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.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()
    
    commit fe1910f9337bd46a9343967b547ccab26b4b2c6e upstream.
    
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing/osnoise: Use a cpumask to know what threads are kthreads [+ + +]
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Wed Sep 4 10:34:28 2024 -0400

    tracing/osnoise: Use a cpumask to know what threads are kthreads
    
    commit 177e1cc2f41235c145041eed03ef5bab18f32328 upstream.
    
    The start_kthread() and stop_thread() code was not always called with the
    interface_lock held. This means that the kthread variable could be
    unexpectedly changed causing the kthread_stop() to be called on it when it
    should not have been, leading to:
    
     while true; do
       rtla timerlat top -u -q & PID=$!;
       sleep 5;
       kill -INT $PID;
       sleep 0.001;
       kill -TERM $PID;
       wait $PID;
      done
    
    Causing the following OOPS:
    
     Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI
     KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
     CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
     RIP: 0010:hrtimer_active+0x58/0x300
     Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 <0f> b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f
     RSP: 0018:ffff88811d97f940 EFLAGS: 00010202
     RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b
     RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28
     RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60
     R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d
     R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28
     FS:  0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0
     Call Trace:
      <TASK>
      ? die_addr+0x40/0xa0
      ? exc_general_protection+0x154/0x230
      ? asm_exc_general_protection+0x26/0x30
      ? hrtimer_active+0x58/0x300
      ? __pfx_mutex_lock+0x10/0x10
      ? __pfx_locks_remove_file+0x10/0x10
      hrtimer_cancel+0x15/0x40
      timerlat_fd_release+0x8e/0x1f0
      ? security_file_release+0x43/0x80
      __fput+0x372/0xb10
      task_work_run+0x11e/0x1f0
      ? _raw_spin_lock+0x85/0xe0
      ? __pfx_task_work_run+0x10/0x10
      ? poison_slab_object+0x109/0x170
      ? do_exit+0x7a0/0x24b0
      do_exit+0x7bd/0x24b0
      ? __pfx_migrate_enable+0x10/0x10
      ? __pfx_do_exit+0x10/0x10
      ? __pfx_read_tsc+0x10/0x10
      ? ktime_get+0x64/0x140
      ? _raw_spin_lock_irq+0x86/0xe0
      do_group_exit+0xb0/0x220
      get_signal+0x17ba/0x1b50
      ? vfs_read+0x179/0xa40
      ? timerlat_fd_read+0x30b/0x9d0
      ? __pfx_get_signal+0x10/0x10
      ? __pfx_timerlat_fd_read+0x10/0x10
      arch_do_signal_or_restart+0x8c/0x570
      ? __pfx_arch_do_signal_or_restart+0x10/0x10
      ? vfs_read+0x179/0xa40
      ? ksys_read+0xfe/0x1d0
      ? __pfx_ksys_read+0x10/0x10
      syscall_exit_to_user_mode+0xbc/0x130
      do_syscall_64+0x74/0x110
      ? __pfx___rseq_handle_notify_resume+0x10/0x10
      ? __pfx_ksys_read+0x10/0x10
      ? fpregs_restore_userregs+0xdb/0x1e0
      ? fpregs_restore_userregs+0xdb/0x1e0
      ? syscall_exit_to_user_mode+0x116/0x130
      ? do_syscall_64+0x74/0x110
      ? do_syscall_64+0x74/0x110
      ? do_syscall_64+0x74/0x110
      entry_SYSCALL_64_after_hwframe+0x71/0x79
     RIP: 0033:0x7ff0070eca9c
     Code: Unable to access opcode bytes at 0x7ff0070eca72.
     RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
     RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c
     RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003
     RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0
     R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003
     R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008
      </TASK>
     Modules linked in: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core
     ---[ end trace 0000000000000000 ]---
    
    This is because it would mistakenly call kthread_stop() on a user space
    thread making it "exit" before it actually exits.
    
    Since kthreads are created based on global behavior, use a cpumask to know
    when kthreads are running and that they need to be shutdown before
    proceeding to do new work.
    
    Link: https://lore.kernel.org/all/20240820130001.124768-1-tglozar@redhat.com/
    
    This was debugged by using the persistent ring buffer:
    
    Link: https://lore.kernel.org/all/20240823013902.135036960@goodmis.org/
    
    Note, locking was originally used to fix this, but that proved to cause too
    many deadlocks to work around:
    
      https://lore.kernel.org/linux-trace-kernel/20240823102816.5e55753b@gandalf.local.home/
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: "Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
    Link: https://lore.kernel.org/20240904103428.08efdf4c@gandalf.local.home
    Fixes: e88ed227f639e ("tracing/timerlat: Add user-space interface")
    Reported-by: Tomas Glozar <tglozar@redhat.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread() [+ + +]
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Thu Sep 5 11:33:59 2024 -0400

    tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()
    
    commit 5bfbcd1ee57b607fd29e4645c7f350dd385dd9ad upstream.
    
    The timerlat interface will get and put the task that is part of the
    "kthread" field of the osn_var to keep it around until all references are
    released. But here's a race in the "stop_kthread()" code that will call
    put_task_struct() on the kthread if it is not a kernel thread. This can
    race with the releasing of the references to that task struct and the
    put_task_struct() can be called twice when it should have been called just
    once.
    
    Take the interface_lock() in stop_kthread() to synchronize this change.
    But to do so, the function stop_per_cpu_kthreads() needs to change the
    loop from for_each_online_cpu() to for_each_possible_cpu() and remove the
    cpu_read_lock(), as the interface_lock can not be taken while the cpu
    locks are held. The only side effect of this change is that it may do some
    extra work, as the per_cpu variables of the offline CPUs would not be set
    anyway, and would simply be skipped in the loop.
    
    Remove unneeded "return;" in stop_kthread().
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Tomas Glozar <tglozar@redhat.com>
    Cc: John Kacur <jkacur@redhat.com>
    Cc: "Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
    Link: https://lore.kernel.org/20240905113359.2b934242@gandalf.local.home
    Fixes: e88ed227f639e ("tracing/timerlat: Add user-space interface")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing/timerlat: Only clear timer if a kthread exists [+ + +]
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Thu Sep 5 08:53:30 2024 -0400

    tracing/timerlat: Only clear timer if a kthread exists
    
    commit e6a53481da292d970d1edf0d8831121d1c5e2f0d upstream.
    
    The timerlat tracer can use user space threads to check for osnoise and
    timer latency. If the program using this is killed via a SIGTERM, the
    threads are shutdown one at a time and another tracing instance can start
    up resetting the threads before they are fully closed. That causes the
    hrtimer assigned to the kthread to be shutdown and freed twice when the
    dying thread finally closes the file descriptors, causing a use-after-free
    bug.
    
    Only cancel the hrtimer if the associated thread is still around. Also add
    the interface_lock around the resetting of the tlat_var->kthread.
    
    Note, this is just a quick fix that can be backported to stable. A real
    fix is to have a better synchronization between the shutdown of old
    threads and the starting of new ones.
    
    Link: https://lore.kernel.org/all/20240820130001.124768-1-tglozar@redhat.com/
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: "Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
    Link: https://lore.kernel.org/20240905085330.45985730@gandalf.local.home
    Fixes: e88ed227f639e ("tracing/timerlat: Add user-space interface")
    Reported-by: Tomas Glozar <tglozar@redhat.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery() [+ + +]
Author: Li Nan <linan122@huawei.com>
Date:   Wed Sep 4 11:13:48 2024 +0800

    ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery()
    
    [ Upstream commit e58f5142f88320a5b1449f96a146f2f24615c5c7 ]
    
    When two UBLK_CMD_START_USER_RECOVERY commands are submitted, the
    first one sets 'ubq->ubq_daemon' to NULL, and the second one triggers
    WARN in ublk_queue_reinit() and subsequently a NULL pointer dereference
    issue.
    
    Fix it by adding the check in ublk_ctrl_start_recovery() and return
    immediately in case of zero 'ub->nr_queues_ready'.
    
      BUG: kernel NULL pointer dereference, address: 0000000000000028
      RIP: 0010:ublk_ctrl_start_recovery.constprop.0+0x82/0x180
      Call Trace:
       <TASK>
       ? __die+0x20/0x70
       ? page_fault_oops+0x75/0x170
       ? exc_page_fault+0x64/0x140
       ? asm_exc_page_fault+0x22/0x30
       ? ublk_ctrl_start_recovery.constprop.0+0x82/0x180
       ublk_ctrl_uring_cmd+0x4f7/0x6c0
       ? pick_next_task_idle+0x26/0x40
       io_uring_cmd+0x9a/0x1b0
       io_issue_sqe+0x193/0x3f0
       io_wq_submit_work+0x9b/0x390
       io_worker_handle_work+0x165/0x360
       io_wq_worker+0xcb/0x2f0
       ? finish_task_switch.isra.0+0x203/0x290
       ? finish_task_switch.isra.0+0x203/0x290
       ? __pfx_io_wq_worker+0x10/0x10
       ret_from_fork+0x2d/0x50
       ? __pfx_io_wq_worker+0x10/0x10
       ret_from_fork_asm+0x1a/0x30
       </TASK>
    
    Fixes: c732a852b419 ("ublk_drv: add START_USER_RECOVERY and END_USER_RECOVERY support")
    Reported-and-tested-by: Changhui Zhong <czhong@redhat.com>
    Closes: https://lore.kernel.org/all/CAGVVp+UvLiS+bhNXV-h2icwX1dyybbYHeQUuH7RYqUvMQf6N3w@mail.gmail.com
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Li Nan <linan122@huawei.com>
    Link: https://lore.kernel.org/r/20240904031348.4139545-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
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: cdns2: Fix controller reset issue [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Mon Sep 2 11:09:16 2024 +0000

    usb: cdns2: Fix controller reset issue
    
    commit e2940928115e83d707b21bf00b0db7d6c15f8341 upstream.
    
    Patch fixes the procedure of resetting controller.
    The CPUCTRL register is write only and reading returns 0.
    Waiting for reset to complite is incorrect.
    
    Fixes: 3eb1f1efe204 ("usb: cdns2: Add main part of Cadence USBHS driver")
    cc: stable@vger.kernel.org
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Link: https://lore.kernel.org/r/PH7PR07MB9538D56D75F1F399D0BB96F0DD922@PH7PR07MB9538.namprd07.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: Avoid waking up gadget during startxfer [+ + +]
Author: Prashanth K <quic_prashk@quicinc.com>
Date:   Wed Aug 28 12:13:02 2024 +0530

    usb: dwc3: Avoid waking up gadget during startxfer
    
    commit 00dcf2fa449f23a263343d7fe051741bdde65d0b upstream.
    
    When operating in High-Speed, it is observed that DSTS[USBLNKST] doesn't
    update link state immediately after receiving the wakeup interrupt. Since
    wakeup event handler calls the resume callbacks, there is a chance that
    function drivers can perform an ep queue, which in turn tries to perform
    remote wakeup from send_gadget_ep_cmd(STARTXFER). This happens because
    DSTS[[21:18] wasn't updated to U0 yet, it's observed that the latency of
    DSTS can be in order of milli-seconds. Hence avoid calling gadget_wakeup
    during startxfer to prevent unnecessarily issuing remote wakeup to host.
    
    Fixes: c36d8e947a56 ("usb: dwc3: gadget: put link to U0 before Start Transfer")
    Cc: stable@vger.kernel.org
    Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240828064302.3796315-1-quic_prashk@quicinc.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: gadget: aspeed_udc: validate endpoint index for ast udc [+ + +]
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Tue Jun 25 10:23:06 2024 +0800

    usb: gadget: aspeed_udc: validate endpoint index for ast udc
    
    [ Upstream commit ee0d382feb44ec0f445e2ad63786cd7f3f6a8199 ]
    
    We should verify the bound of the array to assure that host
    may not manipulate the index to point past endpoint array.
    
    Found by static analysis.
    
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
    Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au>
    Link: https://lore.kernel.org/r/20240625022306.2568122-1-make24@iscas.ac.cn
    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>

 
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>

 
userfaultfd: don't BUG_ON() if khugepaged yanks our page table [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Tue Aug 13 22:25:22 2024 +0200

    userfaultfd: don't BUG_ON() if khugepaged yanks our page table
    
    commit 4828d207dc5161dc7ddf9a4f6dcfd80c7dd7d20a upstream.
    
    Since khugepaged was changed to allow retracting page tables in file
    mappings without holding the mmap lock, these BUG_ON()s are wrong - get
    rid of them.
    
    We could also remove the preceding "if (unlikely(...))" block, but then we
    could reach pte_offset_map_lock() with transhuge pages not just for file
    mappings but also for anonymous mappings - which would probably be fine
    but I think is not necessarily expected.
    
    Link: https://lkml.kernel.org/r/20240813-uffd-thp-flip-fix-v2-2-5efa61078a41@google.com
    Fixes: 1d65b771bc08 ("mm/khugepaged: retract_page_tables() without mmap or vma lock")
    Signed-off-by: Jann Horn <jannh@google.com>
    Reviewed-by: Qi Zheng <zhengqi.arch@bytedance.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Pavel Emelyanov <xemul@virtuozzo.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

userfaultfd: fix checks for huge PMDs [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Tue Aug 13 22:25:21 2024 +0200

    userfaultfd: fix checks for huge PMDs
    
    commit 71c186efc1b2cf1aeabfeff3b9bd5ac4c5ac14d8 upstream.
    
    Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.
    
    The pmd_trans_huge() code in mfill_atomic() is wrong in three different
    ways depending on kernel version:
    
    1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit
       the right two race windows) - I've tested this in a kernel build with
       some extra mdelay() calls. See the commit message for a description
       of the race scenario.
       On older kernels (before 6.5), I think the same bug can even
       theoretically lead to accessing transhuge page contents as a page table
       if you hit the right 5 narrow race windows (I haven't tested this case).
    2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for
       detecting PMDs that don't point to page tables.
       On older kernels (before 6.5), you'd just have to win a single fairly
       wide race to hit this.
       I've tested this on 6.1 stable by racing migration (with a mdelay()
       patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86
       VM, that causes a kernel oops in ptlock_ptr().
    3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed
       to yank page tables out from under us (though I haven't tested that),
       so I think the BUG_ON() checks in mfill_atomic() are just wrong.
    
    I decided to write two separate fixes for these (one fix for bugs 1+2, one
    fix for bug 3), so that the first fix can be backported to kernels
    affected by bugs 1+2.
    
    
    This patch (of 2):
    
    This fixes two issues.
    
    I discovered that the following race can occur:
    
      mfill_atomic                other thread
      ============                ============
                                  <zap PMD>
      pmdp_get_lockless() [reads none pmd]
      <bail if trans_huge>
      <if none:>
                                  <pagefault creates transhuge zeropage>
        __pte_alloc [no-op]
                                  <zap PMD>
      <bail if pmd_trans_huge(*dst_pmd)>
      BUG_ON(pmd_none(*dst_pmd))
    
    I have experimentally verified this in a kernel with extra mdelay() calls;
    the BUG_ON(pmd_none(*dst_pmd)) triggers.
    
    On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow
    pte_offset_map[_lock]() to fail"), this can't lead to anything worse than
    a BUG_ON(), since the page table access helpers are actually designed to
    deal with page tables concurrently disappearing; but on older kernels
    (<=6.4), I think we could probably theoretically race past the two
    BUG_ON() checks and end up treating a hugepage as a page table.
    
    The second issue is that, as Qi Zheng pointed out, there are other types
    of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs
    (in particular, migration PMDs).
    
    On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a
    PMD that contains a migration entry (which just requires winning a single,
    fairly wide race), it will pass the PMD to pte_offset_map_lock(), which
    assumes that the PMD points to a page table.
    
    Breakage follows: First, the kernel tries to take the PTE lock (which will
    crash or maybe worse if there is no "struct page" for the address bits in
    the migration entry PMD - I think at least on X86 there usually is no
    corresponding "struct page" thanks to the PTE inversion mitigation, amd64
    looks different).
    
    If that didn't crash, the kernel would next try to write a PTE into what
    it wrongly thinks is a page table.
    
    As part of fixing these issues, get rid of the check for pmd_trans_huge()
    before __pte_alloc() - that's redundant, we're going to have to check for
    that after the __pte_alloc() anyway.
    
    Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.
    
    Link: https://lkml.kernel.org/r/20240813-uffd-thp-flip-fix-v2-0-5efa61078a41@google.com
    Link: https://lkml.kernel.org/r/20240813-uffd-thp-flip-fix-v2-1-5efa61078a41@google.com
    Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation")
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Pavel Emelyanov <xemul@virtuozzo.com>
    Cc: Qi Zheng <zhengqi.arch@bytedance.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vfio/spapr: Always clear TCEs before unsetting the window [+ + +]
Author: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Date:   Mon Jun 24 12:38:58 2024 +0000

    vfio/spapr: Always clear TCEs before unsetting the window
    
    [ Upstream commit 4ba2fdff2eb174114786784926d0efb6903c88a6 ]
    
    The PAPR expects the TCE table to have no entries at the time of
    unset window(i.e. remove-pe). The TCE clear right now is done
    before freeing the iommu table. On pSeries, the unset window
    makes those entries inaccessible to the OS and the H_PUT/GET calls
    fail on them with H_CONSTRAINED.
    
    On PowerNV, this has no side effect as the TCE clear can be done
    before the DMA window removal as well.
    
    Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/171923273535.1397.1236742071894414895.stgit@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vfs: Fix potential circular locking through setxattr() and removexattr() [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Tue Jul 23 09:59:54 2024 +0100

    vfs: Fix potential circular locking through setxattr() and removexattr()
    
    [ Upstream commit c3a5e3e872f3688ae0dc57bb78ca633921d96a91 ]
    
    When using cachefiles, lockdep may emit something similar to the circular
    locking dependency notice below.  The problem appears to stem from the
    following:
    
     (1) Cachefiles manipulates xattrs on the files in its cache when called
         from ->writepages().
    
     (2) The setxattr() and removexattr() system call handlers get the name
         (and value) from userspace after taking the sb_writers lock, putting
         accesses of the vma->vm_lock and mm->mmap_lock inside of that.
    
     (3) The afs filesystem uses a per-inode lock to prevent multiple
         revalidation RPCs and in writeback vs truncate to prevent parallel
         operations from deadlocking against the server on one side and local
         page locks on the other.
    
    Fix this by moving the getting of the name and value in {get,remove}xattr()
    outside of the sb_writers lock.  This also has the minor benefits that we
    don't need to reget these in the event of a retry and we never try to take
    the sb_writers lock in the event we can't pull the name and value into the
    kernel.
    
    Alternative approaches that might fix this include moving the dispatch of a
    write to the cache off to a workqueue or trying to do without the
    validation lock in afs.  Note that this might also affect other filesystems
    that use netfslib and/or cachefiles.
    
     ======================================================
     WARNING: possible circular locking dependency detected
     6.10.0-build2+ #956 Not tainted
     ------------------------------------------------------
     fsstress/6050 is trying to acquire lock:
     ffff888138fd82f0 (mapping.invalidate_lock#3){++++}-{3:3}, at: filemap_fault+0x26e/0x8b0
    
     but task is already holding lock:
     ffff888113f26d18 (&vma->vm_lock->lock){++++}-{3:3}, at: lock_vma_under_rcu+0x165/0x250
    
     which lock already depends on the new lock.
    
     the existing dependency chain (in reverse order) is:
    
     -> #4 (&vma->vm_lock->lock){++++}-{3:3}:
            __lock_acquire+0xaf0/0xd80
            lock_acquire.part.0+0x103/0x280
            down_write+0x3b/0x50
            vma_start_write+0x6b/0xa0
            vma_link+0xcc/0x140
            insert_vm_struct+0xb7/0xf0
            alloc_bprm+0x2c1/0x390
            kernel_execve+0x65/0x1a0
            call_usermodehelper_exec_async+0x14d/0x190
            ret_from_fork+0x24/0x40
            ret_from_fork_asm+0x1a/0x30
    
     -> #3 (&mm->mmap_lock){++++}-{3:3}:
            __lock_acquire+0xaf0/0xd80
            lock_acquire.part.0+0x103/0x280
            __might_fault+0x7c/0xb0
            strncpy_from_user+0x25/0x160
            removexattr+0x7f/0x100
            __do_sys_fremovexattr+0x7e/0xb0
            do_syscall_64+0x9f/0x100
            entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
     -> #2 (sb_writers#14){.+.+}-{0:0}:
            __lock_acquire+0xaf0/0xd80
            lock_acquire.part.0+0x103/0x280
            percpu_down_read+0x3c/0x90
            vfs_iocb_iter_write+0xe9/0x1d0
            __cachefiles_write+0x367/0x430
            cachefiles_issue_write+0x299/0x2f0
            netfs_advance_write+0x117/0x140
            netfs_write_folio.isra.0+0x5ca/0x6e0
            netfs_writepages+0x230/0x2f0
            afs_writepages+0x4d/0x70
            do_writepages+0x1e8/0x3e0
            filemap_fdatawrite_wbc+0x84/0xa0
            __filemap_fdatawrite_range+0xa8/0xf0
            file_write_and_wait_range+0x59/0x90
            afs_release+0x10f/0x270
            __fput+0x25f/0x3d0
            __do_sys_close+0x43/0x70
            do_syscall_64+0x9f/0x100
            entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
     -> #1 (&vnode->validate_lock){++++}-{3:3}:
            __lock_acquire+0xaf0/0xd80
            lock_acquire.part.0+0x103/0x280
            down_read+0x95/0x200
            afs_writepages+0x37/0x70
            do_writepages+0x1e8/0x3e0
            filemap_fdatawrite_wbc+0x84/0xa0
            filemap_invalidate_inode+0x167/0x1e0
            netfs_unbuffered_write_iter+0x1bd/0x2d0
            vfs_write+0x22e/0x320
            ksys_write+0xbc/0x130
            do_syscall_64+0x9f/0x100
            entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
     -> #0 (mapping.invalidate_lock#3){++++}-{3:3}:
            check_noncircular+0x119/0x160
            check_prev_add+0x195/0x430
            __lock_acquire+0xaf0/0xd80
            lock_acquire.part.0+0x103/0x280
            down_read+0x95/0x200
            filemap_fault+0x26e/0x8b0
            __do_fault+0x57/0xd0
            do_pte_missing+0x23b/0x320
            __handle_mm_fault+0x2d4/0x320
            handle_mm_fault+0x14f/0x260
            do_user_addr_fault+0x2a2/0x500
            exc_page_fault+0x71/0x90
            asm_exc_page_fault+0x22/0x30
    
     other info that might help us debug this:
    
     Chain exists of:
       mapping.invalidate_lock#3 --> &mm->mmap_lock --> &vma->vm_lock->lock
    
      Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       rlock(&vma->vm_lock->lock);
                                    lock(&mm->mmap_lock);
                                    lock(&vma->vm_lock->lock);
       rlock(mapping.invalidate_lock#3);
    
      *** DEADLOCK ***
    
     1 lock held by fsstress/6050:
      #0: ffff888113f26d18 (&vma->vm_lock->lock){++++}-{3:3}, at: lock_vma_under_rcu+0x165/0x250
    
     stack backtrace:
     CPU: 0 PID: 6050 Comm: fsstress Not tainted 6.10.0-build2+ #956
     Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
     Call Trace:
      <TASK>
      dump_stack_lvl+0x57/0x80
      check_noncircular+0x119/0x160
      ? queued_spin_lock_slowpath+0x4be/0x510
      ? __pfx_check_noncircular+0x10/0x10
      ? __pfx_queued_spin_lock_slowpath+0x10/0x10
      ? mark_lock+0x47/0x160
      ? init_chain_block+0x9c/0xc0
      ? add_chain_block+0x84/0xf0
      check_prev_add+0x195/0x430
      __lock_acquire+0xaf0/0xd80
      ? __pfx___lock_acquire+0x10/0x10
      ? __lock_release.isra.0+0x13b/0x230
      lock_acquire.part.0+0x103/0x280
      ? filemap_fault+0x26e/0x8b0
      ? __pfx_lock_acquire.part.0+0x10/0x10
      ? rcu_is_watching+0x34/0x60
      ? lock_acquire+0xd7/0x120
      down_read+0x95/0x200
      ? filemap_fault+0x26e/0x8b0
      ? __pfx_down_read+0x10/0x10
      ? __filemap_get_folio+0x25/0x1a0
      filemap_fault+0x26e/0x8b0
      ? __pfx_filemap_fault+0x10/0x10
      ? find_held_lock+0x7c/0x90
      ? __pfx___lock_release.isra.0+0x10/0x10
      ? __pte_offset_map+0x99/0x110
      __do_fault+0x57/0xd0
      do_pte_missing+0x23b/0x320
      __handle_mm_fault+0x2d4/0x320
      ? __pfx___handle_mm_fault+0x10/0x10
      handle_mm_fault+0x14f/0x260
      do_user_addr_fault+0x2a2/0x500
      exc_page_fault+0x71/0x90
      asm_exc_page_fault+0x22/0x30
    
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/2136178.1721725194@warthog.procyon.org.uk
    cc: Alexander Viro <viro@zeniv.linux.org.uk>
    cc: Christian Brauner <brauner@kernel.org>
    cc: Jan Kara <jack@suse.cz>
    cc: Jeff Layton <jlayton@kernel.org>
    cc: Gao Xiang <xiang@kernel.org>
    cc: Matthew Wilcox <willy@infradead.org>
    cc: netfs@lists.linux.dev
    cc: linux-erofs@lists.ozlabs.org
    cc: linux-fsdevel@vger.kernel.org
    [brauner: fix minor issues]
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio_ring: fix KMSAN error for premapped mode [+ + +]
Author: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Date:   Thu Jun 6 19:13:45 2024 +0800

    virtio_ring: fix KMSAN error for premapped mode
    
    [ Upstream commit 840b2d39a2dc1b96deb3f5c7fef76c9b24f08f51 ]
    
    Add kmsan for virtqueue_dma_map_single_attrs to fix:
    
    BUG: KMSAN: uninit-value in receive_buf+0x45ca/0x6990
     receive_buf+0x45ca/0x6990
     virtnet_poll+0x17e0/0x3130
     net_rx_action+0x832/0x26e0
     handle_softirqs+0x330/0x10f0
     [...]
    
    Uninit was created at:
     __alloc_pages_noprof+0x62a/0xe60
     alloc_pages_noprof+0x392/0x830
     skb_page_frag_refill+0x21a/0x5c0
     virtnet_rq_alloc+0x50/0x1500
     try_fill_recv+0x372/0x54c0
     virtnet_open+0x210/0xbe0
     __dev_open+0x56e/0x920
     __dev_change_flags+0x39c/0x2000
     dev_change_flags+0xaa/0x200
     do_setlink+0x197a/0x7420
     rtnl_setlink+0x77c/0x860
     [...]
    
    Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Tested-by: Alexander Potapenko <glider@google.com>
    Message-Id: <20240606111345.93600-1-xuanzhuo@linux.alibaba.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Tested-by: Ilya Leoshkevich <iii@linux.ibm.com>  # s390x
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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: ath12k: fix firmware crash due to invalid peer nss [+ + +]
Author: Ajith C <quic_ajithc@quicinc.com>
Date:   Thu Jun 13 11:05:28 2024 +0530

    wifi: ath12k: fix firmware crash due to invalid peer nss
    
    [ Upstream commit db163a463bb93cd3e37e1e7b10b9726fb6f95857 ]
    
    Currently, if the access point receives an association
    request containing an Extended HE Capabilities Information
    Element with an invalid MCS-NSS, it triggers a firmware
    crash.
    
    This issue arises when EHT-PHY capabilities shows support
    for a bandwidth and MCS-NSS set for that particular
    bandwidth is filled by zeros and due to this, driver obtains
    peer_nss as 0 and sending this value to firmware causes
    crash.
    
    Address this issue by implementing a validation step for
    the peer_nss value before passing it to the firmware. If
    the value is greater than zero, proceed with forwarding
    it to the firmware. However, if the value is invalid,
    reject the association request to prevent potential
    firmware crashes.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
    
    Signed-off-by: Ajith C <quic_ajithc@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://patch.msgid.link/20240613053528.2541645-1-quic_ajithc@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath12k: fix uninitialize symbol error on ath12k_peer_assoc_h_he() [+ + +]
Author: Aaradhana Sahu <quic_aarasahu@quicinc.com>
Date:   Tue Jun 11 08:40:17 2024 +0530

    wifi: ath12k: fix uninitialize symbol error on ath12k_peer_assoc_h_he()
    
    [ Upstream commit 19b77e7c656a3e125319cc3ef347b397cf042bf6 ]
    
    Smatch throws following errors
    
    drivers/net/wireless/ath/ath12k/mac.c:1922 ath12k_peer_assoc_h_he() error: uninitialized symbol 'rx_mcs_80'.
    drivers/net/wireless/ath/ath12k/mac.c:1922 ath12k_peer_assoc_h_he() error: uninitialized symbol 'rx_mcs_160'.
    drivers/net/wireless/ath/ath12k/mac.c:1924 ath12k_peer_assoc_h_he() error: uninitialized symbol 'rx_mcs_80'.
    
    In ath12k_peer_assoc_h_he() rx_mcs_80 and rx_mcs_160 variables
    remain uninitialized in the following conditions:
    1. Whenever the value of mcs_80 become equal to
       IEEE80211_HE_MCS_NOT_SUPPORTED then rx_mcs_80 remains uninitialized.
    2. Whenever phy capability is not supported 160 channel width and
       value of mcs_160 become equal to IEEE80211_HE_MCS_NOT_SUPPORTED
       then rx_mcs_160 remains uninitialized.
    
    Initialize these variables during declaration.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00188-QCAHKSWPL_SILICONZ-1
    
    Signed-off-by: Aaradhana Sahu <quic_aarasahu@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://patch.msgid.link/20240611031017.297927-3-quic_aarasahu@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.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: iwlwifi: mvm: use IWL_FW_CHECK for link ID check [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jun 25 19:51:09 2024 +0300

    wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check
    
    [ Upstream commit 9215152677d4b321801a92b06f6d5248b2b4465f ]
    
    The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is
    normally called with input from the firmware, so it should use
    IWL_FW_CHECK() instead of WARN_ON().
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://patch.msgid.link/20240625194805.4ea8fb7c47d4.I1c22af213f97f69bfc14674502511c1bc504adfb@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>

wifi: rtw88: usb: schedule rx work after everything is set up [+ + +]
Author: Marcin Ślusarz <mslusarz@renau.com>
Date:   Tue May 28 13:02:46 2024 +0200

    wifi: rtw88: usb: schedule rx work after everything is set up
    
    [ Upstream commit adc539784c98a7cc602cbf557debfc2e7b9be8b3 ]
    
    Right now it's possible to hit NULL pointer dereference in
    rtw_rx_fill_rx_status on hw object and/or its fields because
    initialization routine can start getting USB replies before
    rtw_dev is fully setup.
    
    The stack trace looks like this:
    
    rtw_rx_fill_rx_status
    rtw8821c_query_rx_desc
    rtw_usb_rx_handler
    ...
    queue_work
    rtw_usb_read_port_complete
    ...
    usb_submit_urb
    rtw_usb_rx_resubmit
    rtw_usb_init_rx
    rtw_usb_probe
    
    So while we do the async stuff rtw_usb_probe continues and calls
    rtw_register_hw, which does all kinds of initialization (e.g.
    via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.
    
    Fix this by moving the first usb_submit_urb after everything
    is set up.
    
    For me, this bug manifested as:
    [    8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped
    [    8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status
    because I'm using Larry's backport of rtw88 driver with the NULL
    checks in rtw_rx_fill_rx_status.
    
    Link: https://lore.kernel.org/linux-wireless/CA+shoWQ7P49jhQasofDcTdQhiuarPTjYEDa--NiVVx494WcuQw@mail.gmail.com/
    Signed-off-by: Marcin Ślusarz <mslusarz@renau.com>
    Cc: Tim K <tpkuester@gmail.com>
    Cc: Ping-Ke Shih <pkshih@realtek.com>
    Cc: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Kalle Valo <kvalo@kernel.org>
    Cc: linux-wireless@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20240528110246.477321-1-marcin.slusarz@gmail.com
    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/apic: Make x2apic_disable() work correctly [+ + +]
Author: Yuntao Wang <yuntao.wang@linux.dev>
Date:   Tue Aug 13 09:48:27 2024 +0800

    x86/apic: Make x2apic_disable() work correctly
    
    commit 0ecc5be200c84e67114f3640064ba2bae3ba2f5a upstream.
    
    x2apic_disable() clears x2apic_state and x2apic_mode unconditionally, even
    when the state is X2APIC_ON_LOCKED, which prevents the kernel to disable
    it thereby creating inconsistent state.
    
    Due to the early state check for X2APIC_ON, the code path which warns about
    a locked X2APIC cannot be reached.
    
    Test for state < X2APIC_ON instead and move the clearing of the state and
    mode variables to the place which actually disables X2APIC.
    
    [ tglx: Massaged change log. Added Fixes tag. Moved clearing so it's at the
            right place for back ports ]
    
    Fixes: a57e456a7b28 ("x86/apic: Fix fallout from x2apic cleanup")
    Signed-off-by: Yuntao Wang <yuntao.wang@linux.dev>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240813014827.895381-1-yuntao.wang@linux.dev
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/fpu: Avoid writing LBR bit to IA32_XSS unless supported [+ + +]
Author: Mitchell Levy <levymitchell0@gmail.com>
Date:   Mon Aug 12 13:44:12 2024 -0700

    x86/fpu: Avoid writing LBR bit to IA32_XSS unless supported
    
    commit 2848ff28d180bd63a95da8e5dcbcdd76c1beeb7b upstream.
    
    There are two distinct CPU features related to the use of XSAVES and LBR:
    whether LBR is itself supported and whether XSAVES supports LBR. The LBR
    subsystem correctly checks both in intel_pmu_arch_lbr_init(), but the
    XSTATE subsystem does not.
    
    The LBR bit is only removed from xfeatures_mask_independent when LBR is not
    supported by the CPU, but there is no validation of XSTATE support.
    
    If XSAVES does not support LBR the write to IA32_XSS causes a #GP fault,
    leaving the state of IA32_XSS unchanged, i.e. zero. The fault is handled
    with a warning and the boot continues.
    
    Consequently the next XRSTORS which tries to restore supervisor state fails
    with #GP because the RFBM has zero for all supervisor features, which does
    not match the XCOMP_BV field.
    
    As XFEATURE_MASK_FPSTATE includes supervisor features setting up the FPU
    causes a #GP, which ends up in fpu_reset_from_exception_fixup(). That fails
    due to the same problem resulting in recursive #GPs until the kernel runs
    out of stack space and double faults.
    
    Prevent this by storing the supported independent features in
    fpu_kernel_cfg during XSTATE initialization and use that cached value for
    retrieving the independent feature bits to be written into IA32_XSS.
    
    [ tglx: Massaged change log ]
    
    Fixes: f0dccc9da4c0 ("x86/fpu/xstate: Support dynamic supervisor feature for LBR")
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240812-xsave-lbr-fix-v3-1-95bac1bf62f4@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/kaslr: Expose and use the end of the physical memory address space [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Aug 14 00:29:36 2024 +0200

    x86/kaslr: Expose and use the end of the physical memory address space
    
    commit ea72ce5da22806d5713f3ffb39a6d5ae73841f93 upstream.
    
    iounmap() on x86 occasionally fails to unmap because the provided valid
    ioremap address is not below high_memory. It turned out that this
    happens due to KASLR.
    
    KASLR uses the full address space between PAGE_OFFSET and vaddr_end to
    randomize the starting points of the direct map, vmalloc and vmemmap
    regions.  It thereby limits the size of the direct map by using the
    installed memory size plus an extra configurable margin for hot-plug
    memory.  This limitation is done to gain more randomization space
    because otherwise only the holes between the direct map, vmalloc,
    vmemmap and vaddr_end would be usable for randomizing.
    
    The limited direct map size is not exposed to the rest of the kernel, so
    the memory hot-plug and resource management related code paths still
    operate under the assumption that the available address space can be
    determined with MAX_PHYSMEM_BITS.
    
    request_free_mem_region() allocates from (1 << MAX_PHYSMEM_BITS) - 1
    downwards.  That means the first allocation happens past the end of the
    direct map and if unlucky this address is in the vmalloc space, which
    causes high_memory to become greater than VMALLOC_START and consequently
    causes iounmap() to fail for valid ioremap addresses.
    
    MAX_PHYSMEM_BITS cannot be changed for that because the randomization
    does not align with address bit boundaries and there are other places
    which actually require to know the maximum number of address bits.  All
    remaining usage sites of MAX_PHYSMEM_BITS have been analyzed and found
    to be correct.
    
    Cure this by exposing the end of the direct map via PHYSMEM_END and use
    that for the memory hot-plug and resource management related places
    instead of relying on MAX_PHYSMEM_BITS. In the KASLR case PHYSMEM_END
    maps to a variable which is initialized by the KASLR initialization and
    otherwise it is based on MAX_PHYSMEM_BITS as before.
    
    To prevent future hickups add a check into add_pages() to catch callers
    trying to add memory above PHYSMEM_END.
    
    Fixes: 0483e1fa6e09 ("x86/mm: Implement ASLR for kernel memory regions")
    Reported-by: Max Ramanouski <max8rr8@gmail.com>
    Reported-by: Alistair Popple <apopple@nvidia.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-By: Max Ramanouski <max8rr8@gmail.com>
    Tested-by: Alistair Popple <apopple@nvidia.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Alistair Popple <apopple@nvidia.com>
    Reviewed-by: Kees Cook <kees@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/87ed6soy3z.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/kmsan: Fix hook for unaligned accesses [+ + +]
Author: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
Date:   Thu May 23 23:50:29 2024 +0200

    x86/kmsan: Fix hook for unaligned accesses
    
    [ Upstream commit bf6ab33d8487f5e2a0998ce75286eae65bb0a6d6 ]
    
    When called with a 'from' that is not 4-byte-aligned, string_memcpy_fromio()
    calls the movs() macro to copy the first few bytes, so that 'from' becomes
    4-byte-aligned before calling rep_movs(). This movs() macro modifies 'to', and
    the subsequent line modifies 'n'.
    
    As a result, on unaligned accesses, kmsan_unpoison_memory() uses the updated
    (aligned) values of 'to' and 'n'. Hence, it does not unpoison the entire
    region.
    
    Save the original values of 'to' and 'n', and pass those to
    kmsan_unpoison_memory(), so that the entire region is unpoisoned.
    
    Signed-off-by: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Alexander Potapenko <glider@google.com>
    Link: https://lore.kernel.org/r/20240523215029.4160518-1-bjohannesmeyer@gmail.com
    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>

 
x86/tdx: Fix data leak in mmio_read() [+ + +]
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Aug 26 15:53:04 2024 +0300

    x86/tdx: Fix data leak in mmio_read()
    
    commit b6fb565a2d15277896583d471b21bc14a0c99661 upstream.
    
    The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an
    address from the VMM.
    
    Sean noticed that mmio_read() unintentionally exposes the value of an
    initialized variable (val) on the stack to the VMM.
    
    This variable is only needed as an output value. It did not need to be
    passed to the VMM in the first place.
    
    Do not send the original value of *val to the VMM.
    
    [ dhansen: clarify what 'val' is used for. ]
    
    Fixes: 31d58c4e557d ("x86/tdx: Handle in-kernel MMIO")
    Reported-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Cc:stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240826125304.1566719-1-kirill.shutemov%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xen: privcmd: Fix possible access to a freed kirqfd instance [+ + +]
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Tue Jun 18 15:12:29 2024 +0530

    xen: privcmd: Fix possible access to a freed kirqfd instance
    
    [ Upstream commit 611ff1b1ae989a7bcce3e2a8e132ee30e968c557 ]
    
    Nothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and
    privcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd
    created and added to the irqfds_list by privcmd_irqfd_assign() may get
    removed by another thread executing privcmd_irqfd_deassign(), while the
    former is still using it after dropping the locks.
    
    This can lead to a situation where an already freed kirqfd instance may
    be accessed and cause kernel oops.
    
    Use SRCU locking to prevent the same, as is done for the KVM
    implementation for irqfds.
    
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/9e884af1f1f842eacbb7afc5672c8feb4dea7f3f.1718703669.git.viresh.kumar@linaro.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>