Changelog in Linux kernel 5.4.285

 
ACPI: battery: Fix possible crash when unregistering a battery hook [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Tue Oct 1 23:28:34 2024 +0200

    ACPI: battery: Fix possible crash when unregistering a battery hook
    
    [ Upstream commit 76959aff14a0012ad6b984ec7686d163deccdc16 ]
    
    When a battery hook returns an error when adding a new battery, then
    the battery hook is automatically unregistered.
    However the battery hook provider cannot know that, so it will later
    call battery_hook_unregister() on the already unregistered battery
    hook, resulting in a crash.
    
    Fix this by using the list head to mark already unregistered battery
    hooks as already being unregistered so that they can be ignored by
    battery_hook_unregister().
    
    Fixes: fa93854f7a7e ("battery: Add the battery hooking API")
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: All applicable <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: battery: Simplify battery hook locking [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Tue Oct 1 23:28:33 2024 +0200

    ACPI: battery: Simplify battery hook locking
    
    [ Upstream commit 86309cbed26139e1caae7629dcca1027d9a28e75 ]
    
    Move the conditional locking from __battery_hook_unregister()
    into battery_hook_unregister() and rename the low-level function
    to simplify the locking during battery hook removal.
    
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Reviewed-by: Pali Rohár <[email protected]>
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Stable-dep-of: 76959aff14a0 ("ACPI: battery: Fix possible crash when unregistering a battery hook")
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid detection issue [+ + +]
Author: Shubham Panwar <[email protected]>
Date:   Sun Oct 20 15:20:46 2024 +0530

    ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid detection issue
    
    commit 8fa73ee44daefc884c53a25158c25a4107eb5a94 upstream.
    
    Add a DMI quirk for Samsung Galaxy Book2 to fix an initial lid state
    detection issue.
    
    The _LID device incorrectly returns the lid status as "closed" during
    boot, causing the system to enter a suspend loop right after booting.
    
    The quirk ensures that the correct lid state is reported initially,
    preventing the system from immediately suspending after startup.  It
    only addresses the initial lid state detection and ensures proper
    system behavior upon boot.
    
    Signed-off-by: Shubham Panwar <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Changelog edits ]
    Cc: All applicable <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ACPI: EC: Do not release locks during operation region accesses [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Thu Jul 4 18:26:54 2024 +0200

    ACPI: EC: Do not release locks during operation region accesses
    
    [ Upstream commit dc171114926ec390ab90f46534545420ec03e458 ]
    
    It is not particularly useful to release locks (the EC mutex and the
    ACPI global lock, if present) and re-acquire them immediately thereafter
    during EC address space accesses in acpi_ec_space_handler().
    
    First, releasing them for a while before grabbing them again does not
    really help anyone because there may not be enough time for another
    thread to acquire them.
    
    Second, if another thread successfully acquires them and carries out
    a new EC write or read in the middle if an operation region access in
    progress, it may confuse the EC firmware, especially after the burst
    mode has been enabled.
    
    Finally, manipulating the locks after writing or reading every single
    byte of data is overhead that it is better to avoid.
    
    Accordingly, modify the code to carry out EC address space accesses
    entirely without releasing the locks.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe() [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Wed Jul 31 01:53:39 2024 +0300

    ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()
    
    [ Upstream commit 07442c46abad1d50ac82af5e0f9c5de2732c4592 ]
    
    In tps68470_pmic_opregion_probe() pointer 'dev' is compared to NULL which
    is useless.
    
    Fix this issue by removing unneeded check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: e13452ac3790 ("ACPI / PMIC: Add TI PMIC TPS68470 operation region driver")
    Suggested-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Reviewed-by: Sakari Ailus <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Subject edit ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: resource: Add another DMI match for the TongFang GMxXGxx [+ + +]
Author: Werner Sembach <[email protected]>
Date:   Tue Sep 10 11:40:06 2024 +0200

    ACPI: resource: Add another DMI match for the TongFang GMxXGxx
    
    commit a98cfe6ff15b62f94a44d565607a16771c847bc6 upstream.
    
    Internal documentation suggest that the TUXEDO Polaris 15 Gen5 AMD might
    have GMxXGxX as the board name instead of GMxXGxx.
    
    Adding both to be on the safe side.
    
    Signed-off-by: Werner Sembach <[email protected]>
    Cc: All applicable <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ACPI: resource: Add Asus ExpertBook B2502CVA to irq1_level_low_skip_override[] [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Fri Sep 27 16:16:06 2024 +0200

    ACPI: resource: Add Asus ExpertBook B2502CVA to irq1_level_low_skip_override[]
    
    commit 056301e7c7c886f96d799edd36f3406cc30e1822 upstream.
    
    Like other Asus ExpertBook models the B2502CVA has its keybopard IRQ (1)
    described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh
    which breaks the keyboard.
    
    Add the B2502CVA to the irq1_level_low_skip_override[] quirk table to fix
    this.
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217760
    Cc: All applicable <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[] [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Fri Sep 27 16:16:05 2024 +0200

    ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]
    
    commit 2f80ce0b78c340e332f04a5801dee5e4ac8cfaeb upstream.
    
    Like other Asus Vivobook models the X1704VAP has its keybopard IRQ (1)
    described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh
    which breaks the keyboard.
    
    Add the X1704VAP to the irq1_level_low_skip_override[] quirk table to fix
    this.
    
    Reported-by: Lamome Julien <[email protected]>
    Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078696
    Closes: https://lore.kernel.org/all/[email protected]/
    Cc: All applicable <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[] [+ + +]
Author: Christian Heusel <[email protected]>
Date:   Thu Oct 17 13:16:26 2024 +0200

    ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]
    
    commit 53f1a907d36fb3aa02a4d34073bcec25823a6c74 upstream.
    
    The LG Gram Pro 16 2-in-1 (2024) the 16T90SP has its keybopard IRQ (1)
    described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh
    which breaks the keyboard.
    
    Add the 16T90SP to the irq1_level_low_skip_override[] quirk table to fix
    this.
    
    Reported-by: Dirk Holten <[email protected]>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219382
    Cc: All applicable <[email protected]>
    Suggested-by: Dirk Holten <[email protected]>
    Signed-off-by: Christian Heusel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ACPI: sysfs: validate return type of _STR method [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Tue Jul 9 22:37:24 2024 +0200

    ACPI: sysfs: validate return type of _STR method
    
    commit 4bb1e7d027413835b086aed35bc3f0713bc0f72b upstream.
    
    Only buffer objects are valid return values of _STR.
    
    If something else is returned description_show() will access invalid
    memory.
    
    Fixes: d1efe3c324ea ("ACPI: Add new sysfs interface to export device description")
    Cc: All applicable <[email protected]>
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() [+ + +]
Author: Pei Xiao <[email protected]>
Date:   Thu Jul 18 14:05:48 2024 +0800

    ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()
    
    [ Upstream commit a5242874488eba2b9062985bf13743c029821330 ]
    
    ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0
    
    ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause
    NULL pointer dereference later.
    
    Link: https://github.com/acpica/acpica/commit/4d4547cf
    Signed-off-by: Pei Xiao <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPICA: Fix memory leak if acpi_ps_get_next_field() fails [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Sun Apr 14 21:50:33 2024 +0200

    ACPICA: Fix memory leak if acpi_ps_get_next_field() fails
    
    [ Upstream commit e6169a8ffee8a012badd8c703716e761ce851b15 ]
    
    ACPICA commit 1280045754264841b119a5ede96cd005bc09b5a7
    
    If acpi_ps_get_next_field() fails, the previously created field list
    needs to be properly disposed before returning the status code.
    
    Link: https://github.com/acpica/acpica/commit/12800457
    Signed-off-by: Armin Wolf <[email protected]>
    [ rjw: Rename local variable to avoid compiler confusion ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Wed Apr 3 20:50:11 2024 +0200

    ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails
    
    [ Upstream commit 5accb265f7a1b23e52b0ec42313d1e12895552f4 ]
    
    ACPICA commit 2802af722bbde7bf1a7ac68df68e179e2555d361
    
    If acpi_ps_get_next_namepath() fails, the previously allocated
    union acpi_parse_object needs to be freed before returning the
    status code.
    
    The issue was first being reported on the Linux ACPI mailing list:
    
    Link: https://lore.kernel.org/linux-acpi/[email protected]/T/
    Link: https://github.com/acpica/acpica/commit/2802af72
    Signed-off-by: Armin Wolf <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPICA: iasl: handle empty connection_node [+ + +]
Author: Aleksandrs Vinarskis <[email protected]>
Date:   Sun Aug 11 23:33:44 2024 +0200

    ACPICA: iasl: handle empty connection_node
    
    [ Upstream commit a0a2459b79414584af6c46dd8c6f866d8f1aa421 ]
    
    ACPICA commit 6c551e2c9487067d4b085333e7fe97e965a11625
    
    Link: https://github.com/acpica/acpica/commit/6c551e2c
    Signed-off-by: Aleksandrs Vinarskis <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: asihpi: Fix potential OOB array access [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Thu Aug 8 11:14:42 2024 +0200

    ALSA: asihpi: Fix potential OOB array access
    
    [ Upstream commit 7b986c7430a6bb68d523dac7bfc74cbd5b44ef96 ]
    
    ASIHPI driver stores some values in the static array upon a response
    from the driver, and its index depends on the firmware.  We shouldn't
    trust it blindly.
    
    This patch adds a sanity check of the array index to fit in the array
    size.
    
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: core: add isascii() check to card ID generator [+ + +]
Author: Jaroslav Kysela <[email protected]>
Date:   Wed Oct 2 21:46:49 2024 +0200

    ALSA: core: add isascii() check to card ID generator
    
    commit d278a9de5e1837edbe57b2f1f95a104ff6c84846 upstream.
    
    The card identifier should contain only safe ASCII characters. The isalnum()
    returns true also for characters for non-ASCII characters.
    
    Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4135
    Link: https://lore.kernel.org/linux-sound/yk3WTvKkwheOon_LzZlJ43PPInz6byYfBzpKkbasww1yzuiMRqn7n6Y8vZcXB-xwFCu_vb8hoNjv7DTNwH5TWjpEuiVsyn9HPCEXqwF4120=@protonmail.com/
    Cc: [email protected]
    Reported-by: Barnabás Pőcze <[email protected]>
    Signed-off-by: Jaroslav Kysela <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() [+ + +]
Author: Andrey Shumilin <[email protected]>
Date:   Fri Oct 18 09:00:18 2024 +0300

    ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()
    
    [ Upstream commit 72cafe63b35d06b5cfbaf807e90ae657907858da ]
    
    The step variable is initialized to zero. It is changed in the loop,
    but if it's not changed it will remain zero. Add a variable check
    before the division.
    
    The observed behavior was introduced by commit 826b5de90c0b
    ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"),
    and it is difficult to show that any of the interval parameters will
    satisfy the snd_interval_test() condition with data from the
    amdtp_rate_table[] table.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size")
    Signed-off-by: Andrey Shumilin <[email protected]>
    Reviewed-by: Takashi Sakamoto <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Fri Oct 4 10:25:58 2024 +0200

    ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin
    
    [ Upstream commit b3ebb007060f89d5a45c9b99f06a55e36a1945b5 ]
    
    We received a regression report for System76 Pangolin (pang14) due to
    the recent fix for Tuxedo Sirius devices to support the top speaker.
    The reason was the conflicting PCI SSID, as often seen.
    
    As a workaround, now the codec SSID is checked and the quirk is
    applied conditionally only to Sirius devices.
    
    Fixes: 4178d78cd7a8 ("ALSA: hda/conexant: Add pincfg quirk to enable top speakers on Sirius devices")
    Reported-by: Christian Heusel <[email protected]>
    Reported-by: Jerry <[email protected]>
    Closes: https://lore.kernel.org/[email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue Oct 1 14:14:36 2024 +0200

    ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs
    
    [ Upstream commit 1c801e7f77445bc56e5e1fec6191fd4503534787 ]
    
    Some time ago, we introduced the obey_preferred_dacs flag for choosing
    the DAC/pin pairs specified by the driver instead of parsing the
    paths.  This works as expected, per se, but there have been a few
    cases where we forgot to set this flag while preferred_dacs table is
    already set up.  It ended up with incorrect wiring and made us
    wondering why it doesn't work.
    
    Basically, when the preferred_dacs table is provided, it means that
    the driver really wants to wire up to follow that.  That is, the
    presence of the preferred_dacs table itself is already a "do-it"
    flag.
    
    In this patch, we simply replace the evaluation of obey_preferred_dacs
    flag with the presence of preferred_dacs table for fixing the
    misbehavior.  Another patch to drop of the obsoleted flag will
    follow.
    
    Fixes: 242d990c158d ("ALSA: hda/generic: Add option to enforce preferred_dacs pairs")
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1219803
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek - Fixed ALC256 headphone no sound [+ + +]
Author: Kailang Yang <[email protected]>
Date:   Thu Aug 22 10:54:19 2024 +0800

    ALSA: hda/realtek - Fixed ALC256 headphone no sound
    
    [ Upstream commit 9b82ff1362f50914c8292902e07be98a9f59d33d ]
    
    Dell platform, plug headphone or headset, it had a chance to get no
    sound from headphone.
    Replace depop procedure will solve this issue.
    
    Signed-off-by: Kailang Yang <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek - FIxed ALC285 headphone no sound [+ + +]
Author: Kailang Yang <[email protected]>
Date:   Thu Aug 22 16:46:56 2024 +0800

    ALSA: hda/realtek - FIxed ALC285 headphone no sound
    
    [ Upstream commit 1fa7b099d60ad64f559bd3b8e3f0d94b2e015514 ]
    
    Dell platform with ALC215 ALC285 ALC289 ALC225 ALC295 ALC299, plug
    headphone or headset.
    It had a chance to get no sound from headphone.
    Replace depop procedure will solve this issue.
    
    Signed-off-by: Kailang Yang <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593 [+ + +]
Author: José Relvas <[email protected]>
Date:   Sun Oct 20 11:27:56 2024 +0100

    ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593
    
    commit 35fdc6e1c16099078bcbd73a6c8f1733ae7f1909 upstream.
    
    The Acer Predator G9-593 has a 2+1 speaker system which isn't probed
    correctly.
    This patch adds a quirk with the proper pin connections.
    
    Note that I do not own this laptop, so I cannot guarantee that this
    fixes the issue.
    Testing was done by other users here:
    https://discussion.fedoraproject.org/t/-/118482
    
    This model appears to have two different dev IDs...
    
    - 0x1177 (as seen on the forum link above)
    - 0x1178 (as seen on https://linux-hardware.org/?probe=127df9999f)
    
    I don't think the audio system was changed between model revisions, so
    the patch applies for both IDs.
    
    Signed-off-by: José Relvas <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: hda/realtek: Fix the push button function for the ALC257 [+ + +]
Author: Oder Chiou <[email protected]>
Date:   Mon Sep 30 18:50:39 2024 +0800

    ALSA: hda/realtek: Fix the push button function for the ALC257
    
    [ Upstream commit 05df9732a0894846c46d0062d4af535c5002799d ]
    
    The headset push button cannot work properly in case of the ALC257.
    This patch reverted the previous commit to correct the side effect.
    
    Fixes: ef9718b3d54e ("ALSA: hda/realtek: Fix noise from speakers on Lenovo IdeaPad 3 15IAU7")
    Signed-off-by: Oder Chiou <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda/realtek: Update default depop procedure [+ + +]
Author: Kailang Yang <[email protected]>
Date:   Wed Oct 23 16:13:10 2024 +0800

    ALSA: hda/realtek: Update default depop procedure
    
    [ Upstream commit e3ea2757c312e51bbf62ebc434a6f7df1e3a201f ]
    
    Old procedure has a chance to meet Headphone no output.
    
    Fixes: c2d6af53a43f ("ALSA: hda/realtek - Add default procedure for suspend and resume state")
    Signed-off-by: Kailang Yang <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hdsp: Break infinite MIDI input flush loop [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Thu Aug 8 11:15:12 2024 +0200

    ALSA: hdsp: Break infinite MIDI input flush loop
    
    [ Upstream commit c01f3815453e2d5f699ccd8c8c1f93a5b8669e59 ]
    
    The current MIDI input flush on HDSP and HDSPM drivers relies on the
    hardware reporting the right value.  If the hardware doesn't give the
    proper value but returns -1, it may be stuck at an infinite loop.
    
    Add a counter and break if the loop is unexpectedly too long.
    
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
aoe: fix the potential use-after-free problem in more places [+ + +]
Author: Chun-Yi Lee <[email protected]>
Date:   Wed Oct 2 11:54:58 2024 +0800

    aoe: fix the potential use-after-free problem in more places
    
    commit 6d6e54fc71ad1ab0a87047fd9c211e75d86084a3 upstream.
    
    For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential
    use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put()
    instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs
    into use-after-free.
    
    Then Nicolai Stange found more places in aoe have potential use-after-free
    problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe()
    and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push
    packet to tx queue. So they should also use dev_hold() to increase the
    refcnt of skb->dev.
    
    On the other hand, moving dev_put() to tx() causes that the refcnt of
    skb->dev be reduced to a negative value, because corresponding
    dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(),
    probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.
    
    Cc: [email protected]
    Link: https://nvd.nist.gov/vuln/detail/CVE-2023-6270
    Fixes: f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts")
    Reported-by: Nicolai Stange <[email protected]>
    Signed-off-by: Chun-Yi Lee <[email protected]>
    Link: https://lore.kernel.org/stable/20240624064418.27043-1-jlee%40suse.com
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64/uprobes: change the uprobe_opcode_t typedef to fix the sparse warning [+ + +]
Author: junhua huang <[email protected]>
Date:   Wed Dec 28 09:54:12 2022 +0800

    arm64/uprobes: change the uprobe_opcode_t typedef to fix the sparse warning
    
    commit ef08c0fadd8a17ebe429b85e23952dac3263ad34 upstream.
    
    After we fixed the uprobe inst endian in aarch_be, the sparse check report
    the following warning info:
    
    sparse warnings: (new ones prefixed by >>)
    >> kernel/events/uprobes.c:223:25: sparse: sparse: restricted __le32 degrades to integer
    >> kernel/events/uprobes.c:574:56: sparse: sparse: incorrect type in argument 4 (different base types)
    @@     expected unsigned int [addressable] [usertype] opcode @@     got restricted __le32 [usertype] @@
       kernel/events/uprobes.c:574:56: sparse:     expected unsigned int [addressable] [usertype] opcode
       kernel/events/uprobes.c:574:56: sparse:     got restricted __le32 [usertype]
    >> kernel/events/uprobes.c:1483:32: sparse: sparse: incorrect type in initializer (different base types)
    @@     expected unsigned int [usertype] insn @@     got restricted __le32 [usertype] @@
       kernel/events/uprobes.c:1483:32: sparse:     expected unsigned int [usertype] insn
       kernel/events/uprobes.c:1483:32: sparse:     got restricted __le32 [usertype]
    
    use the __le32 to u32 for uprobe_opcode_t, to keep the same.
    
    Fixes: 60f07e22a73d ("arm64:uprobe fix the uprobe SWBP_INSN in big-endian")
    Reported-by: kernel test robot <[email protected]>
    Signed-off-by: junhua huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64: Add Cortex-715 CPU part definition [+ + +]
Author: Anshuman Khandual <[email protected]>
Date:   Mon Oct 7 13:18:48 2024 +0100

    arm64: Add Cortex-715 CPU part definition
    
    [ Upstream commit 07e39e60bbf0ccd5f895568e1afca032193705c0 ]
    
    Add the CPU Partnumbers for the new Arm designs.
    
    Cc: Catalin Marinas <[email protected]>
    Cc: Will Deacon <[email protected]>
    Cc: Suzuki K Poulose <[email protected]>
    Cc: James Morse <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Acked-by: Catalin Marinas <[email protected]>
    Signed-off-by: Anshuman Khandual <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    [ Mark: Trivial backport ]
    Signed-off-by: Mark Rutland <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: cputype: Add Neoverse-N3 definitions [+ + +]
Author: Mark Rutland <[email protected]>
Date:   Mon Oct 7 13:18:49 2024 +0100

    arm64: cputype: Add Neoverse-N3 definitions
    
    [ Upstream commit 924725707d80bc2588cefafef76ff3f164d299bc ]
    
    Add cputype definitions for Neoverse-N3. These will be used for errata
    detection in subsequent patches.
    
    These values can be found in Table A-261 ("MIDR_EL1 bit descriptions")
    in issue 02 of the Neoverse-N3 TRM, which can be found at:
    
      https://developer.arm.com/documentation/107997/0000/?lang=en
    
    Signed-off-by: Mark Rutland <[email protected]>
    Cc: James Morse <[email protected]>
    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Catalin Marinas <[email protected]>
    [ Mark: trivial backport ]
    Signed-off-by: Mark Rutland <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: override BIOS_DISABLE signal via GPIO hog on RK3399 Puma [+ + +]
Author: Quentin Schulz <[email protected]>
Date:   Wed Jul 31 13:05:29 2024 +0200

    arm64: dts: rockchip: override BIOS_DISABLE signal via GPIO hog on RK3399 Puma
    
    commit 741f5ba7ccba5d7ae796dd11c320e28045524771 upstream.
    
    The Qseven BIOS_DISABLE signal on the RK3399-Q7 keeps the on-module eMMC
    and SPI flash powered-down initially (in fact it keeps the reset signal
    asserted). BIOS_DISABLE_OVERRIDE pin allows to override that signal so
    that eMMC and SPI can be used regardless of the state of the signal.
    
    Let's make this GPIO a hog so that it's reserved and locked in the
    proper state.
    
    At the same time, make sure the pin is reserved for the hog and cannot
    be requested by another node.
    
    Cc: [email protected]
    Signed-off-by: Quentin Schulz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: errata: Expand speculative SSBS workaround once more [+ + +]
Author: Mark Rutland <[email protected]>
Date:   Mon Oct 7 13:18:50 2024 +0100

    arm64: errata: Expand speculative SSBS workaround once more
    
    [ Upstream commit 081eb7932c2b244f63317a982c5e3990e2c7fbdd ]
    
    A number of Arm Ltd CPUs suffer from errata whereby an MSR to the SSBS
    special-purpose register does not affect subsequent speculative
    instructions, permitting speculative store bypassing for a window of
    time.
    
    We worked around this for a number of CPUs in commits:
    
    * 7187bb7d0b5c7dfa ("arm64: errata: Add workaround for Arm errata 3194386 and 3312417")
    * 75b3c43eab594bfb ("arm64: errata: Expand speculative SSBS workaround")
    * 145502cac7ea70b5 ("arm64: errata: Expand speculative SSBS workaround (again)")
    
    Since then, a (hopefully final) batch of updates have been published,
    with two more affected CPUs. For the affected CPUs the existing
    mitigation is sufficient, as described in their respective Software
    Developer Errata Notice (SDEN) documents:
    
    * Cortex-A715 (MP148) SDEN v15.0, erratum 3456084
      https://developer.arm.com/documentation/SDEN-2148827/1500/
    
    * Neoverse-N3 (MP195) SDEN v5.0, erratum 3456111
      https://developer.arm.com/documentation/SDEN-3050973/0500/
    
    Enable the existing mitigation by adding the relevant MIDRs to
    erratum_spec_ssbs_list, and update silicon-errata.rst and the
    Kconfig text accordingly.
    
    Signed-off-by: Mark Rutland <[email protected]>
    Cc: James Morse <[email protected]>
    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Catalin Marinas <[email protected]>
    [ Mark: fix conflict in silicon-errata.rst, handle move ]
    Signed-off-by: Mark Rutland <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: probes: Fix simulate_ldr*_literal() [+ + +]
Author: Mark Rutland <[email protected]>
Date:   Tue Oct 8 16:58:47 2024 +0100

    arm64: probes: Fix simulate_ldr*_literal()
    
    commit 50f813e57601c22b6f26ced3193b9b94d70a2640 upstream.
    
    The simulate_ldr_literal() code always loads a 64-bit quantity, and when
    simulating a 32-bit load into a 'W' register, it discards the most
    significant 32 bits. For big-endian kernels this means that the relevant
    bits are discarded, and the value returned is the the subsequent 32 bits
    in memory (i.e. the value at addr + 4).
    
    Additionally, simulate_ldr_literal() and simulate_ldrsw_literal() use a
    plain C load, which the compiler may tear or elide (e.g. if the target
    is the zero register). Today this doesn't happen to matter, but it may
    matter in future if trampoline code uses a LDR (literal) or LDRSW
    (literal).
    
    Update simulate_ldr_literal() and simulate_ldrsw_literal() to use an
    appropriately-sized READ_ONCE() to perform the access, which avoids
    these problems.
    
    Fixes: 39a67d49ba35 ("arm64: kprobes instruction simulation support")
    Cc: [email protected]
    Signed-off-by: Mark Rutland <[email protected]>
    Cc: Catalin Marinas <[email protected]>
    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: probes: Fix uprobes for big-endian kernels [+ + +]
Author: Mark Rutland <[email protected]>
Date:   Tue Oct 8 16:58:48 2024 +0100

    arm64: probes: Fix uprobes for big-endian kernels
    
    [ Upstream commit 13f8f1e05f1dc36dbba6cba0ae03354c0dafcde7 ]
    
    The arm64 uprobes code is broken for big-endian kernels as it doesn't
    convert the in-memory instruction encoding (which is always
    little-endian) into the kernel's native endianness before analyzing and
    simulating instructions. This may result in a few distinct problems:
    
    * The kernel may may erroneously reject probing an instruction which can
      safely be probed.
    
    * The kernel may erroneously erroneously permit stepping an
      instruction out-of-line when that instruction cannot be stepped
      out-of-line safely.
    
    * The kernel may erroneously simulate instruction incorrectly dur to
      interpretting the byte-swapped encoding.
    
    The endianness mismatch isn't caught by the compiler or sparse because:
    
    * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so
      the compiler and sparse have no idea these contain a little-endian
      32-bit value. The core uprobes code populates these with a memcpy()
      which similarly does not handle endianness.
    
    * While the uprobe_opcode_t type is an alias for __le32, both
      arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]
      to the similarly-named probe_opcode_t, which is an alias for u32.
      Hence there is no endianness conversion warning.
    
    Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and
    adding the appropriate __le32_to_cpu() conversions prior to consuming
    the instruction encoding. The core uprobes copies these fields as opaque
    ranges of bytes, and so is unaffected by this change.
    
    At the same time, remove MAX_UINSN_BYTES and consistently use
    AARCH64_INSN_SIZE for clarity.
    
    Tested with the following:
    
    | #include <stdio.h>
    | #include <stdbool.h>
    |
    | #define noinline __attribute__((noinline))
    |
    | static noinline void *adrp_self(void)
    | {
    |         void *addr;
    |
    |         asm volatile(
    |         "       adrp    %x0, adrp_self\n"
    |         "       add     %x0, %x0, :lo12:adrp_self\n"
    |         : "=r" (addr));
    | }
    |
    |
    | int main(int argc, char *argv)
    | {
    |         void *ptr = adrp_self();
    |         bool equal = (ptr == adrp_self);
    |
    |         printf("adrp_self   => %p\n"
    |                "adrp_self() => %p\n"
    |                "%s\n",
    |                adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL");
    |
    |         return 0;
    | }
    
    .... where the adrp_self() function was compiled to:
    
    | 00000000004007e0 <adrp_self>:
    |   4007e0:       90000000        adrp    x0, 400000 <__ehdr_start>
    |   4007e4:       911f8000        add     x0, x0, #0x7e0
    |   4007e8:       d65f03c0        ret
    
    Before this patch, the ADRP is not recognized, and is assumed to be
    steppable, resulting in corruption of the result:
    
    | # ./adrp-self
    | adrp_self   => 0x4007e0
    | adrp_self() => 0x4007e0
    | EQUAL
    | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events
    | # echo 1 > /sys/kernel/tracing/events/uprobes/enable
    | # ./adrp-self
    | adrp_self   => 0x4007e0
    | adrp_self() => 0xffffffffff7e0
    | NOT EQUAL
    
    After this patch, the ADRP is correctly recognized and simulated:
    
    | # ./adrp-self
    | adrp_self   => 0x4007e0
    | adrp_self() => 0x4007e0
    | EQUAL
    | #
    | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events
    | # echo 1 > /sys/kernel/tracing/events/uprobes/enable
    | # ./adrp-self
    | adrp_self   => 0x4007e0
    | adrp_self() => 0x4007e0
    | EQUAL
    
    Fixes: 9842ceae9fa8 ("arm64: Add uprobe support")
    Cc: [email protected]
    Signed-off-by: Mark Rutland <[email protected]>
    Cc: Catalin Marinas <[email protected]>
    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: probes: Remove broken LDR (literal) uprobe support [+ + +]
Author: Mark Rutland <[email protected]>
Date:   Tue Oct 8 16:58:46 2024 +0100

    arm64: probes: Remove broken LDR (literal) uprobe support
    
    commit acc450aa07099d071b18174c22a1119c57da8227 upstream.
    
    The simulate_ldr_literal() and simulate_ldrsw_literal() functions are
    unsafe to use for uprobes. Both functions were originally written for
    use with kprobes, and access memory with plain C accesses. When uprobes
    was added, these were reused unmodified even though they cannot safely
    access user memory.
    
    There are three key problems:
    
    1) The plain C accesses do not have corresponding extable entries, and
       thus if they encounter a fault the kernel will treat these as
       unintentional accesses to user memory, resulting in a BUG() which
       will kill the kernel thread, and likely lead to further issues (e.g.
       lockup or panic()).
    
    2) The plain C accesses are subject to HW PAN and SW PAN, and so when
       either is in use, any attempt to simulate an access to user memory
       will fault. Thus neither simulate_ldr_literal() nor
       simulate_ldrsw_literal() can do anything useful when simulating a
       user instruction on any system with HW PAN or SW PAN.
    
    3) The plain C accesses are privileged, as they run in kernel context,
       and in practice can access a small range of kernel virtual addresses.
       The instructions they simulate have a range of +/-1MiB, and since the
       simulated instructions must itself be a user instructions in the
       TTBR0 address range, these can address the final 1MiB of the TTBR1
       acddress range by wrapping downwards from an address in the first
       1MiB of the TTBR0 address range.
    
       In contemporary kernels the last 8MiB of TTBR1 address range is
       reserved, and accesses to this will always fault, meaning this is no
       worse than (1).
    
       Historically, it was theoretically possible for the linear map or
       vmemmap to spill into the final 8MiB of the TTBR1 address range, but
       in practice this is extremely unlikely to occur as this would
       require either:
    
       * Having enough physical memory to fill the entire linear map all the
         way to the final 1MiB of the TTBR1 address range.
    
       * Getting unlucky with KASLR randomization of the linear map such
         that the populated region happens to overlap with the last 1MiB of
         the TTBR address range.
    
       ... and in either case if we were to spill into the final page there
       would be larger problems as the final page would alias with error
       pointers.
    
    Practically speaking, (1) and (2) are the big issues. Given there have
    been no reports of problems since the broken code was introduced, it
    appears that no-one is relying on probing these instructions with
    uprobes.
    
    Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW
    (literal), limiting the use of simulate_ldr_literal() and
    simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR
    (literal) and LDRSW (literal) will be rejected as
    arm_probe_decode_insn() will return INSN_REJECTED. In future we can
    consider introducing working uprobes support for these instructions, but
    this will require more significant work.
    
    Fixes: 9842ceae9fa8 ("arm64: Add uprobe support")
    Cc: [email protected]
    Signed-off-by: Mark Rutland <[email protected]>
    Cc: Catalin Marinas <[email protected]>
    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: arm64:uprobe fix the uprobe SWBP_INSN in big-endian [+ + +]
Author: junhua huang <[email protected]>
Date:   Fri Dec 2 15:11:10 2022 +0800

    arm64:uprobe fix the uprobe SWBP_INSN in big-endian
    
    [ Upstream commit 60f07e22a73d318cddaafa5ef41a10476807cc07 ]
    
    We use uprobe in aarch64_be, which we found the tracee task would exit
    due to SIGILL when we enable the uprobe trace.
    We can see the replace inst from uprobe is not correct in aarch big-endian.
    As in Armv8-A, instruction fetches are always treated as little-endian,
    we should treat the UPROBE_SWBP_INSN as little-endian。
    
    The test case is as following。
    bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null &
    bash-4.4# cd /sys/kernel/debug/tracing/
    bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events
    bash-4.4# echo 1 > events/uprobes/enable
    bash-4.4#
    bash-4.4# ps
      PID TTY          TIME CMD
      140 ?        00:00:01 bash
      237 ?        00:00:00 ps
    [1]+  Illegal instruction     ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null
    
    which we debug use gdb as following:
    
    bash-4.4# gdb attach 155
    (gdb) disassemble send
    Dump of assembler code for function send:
       0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
       0x0000000000400c34 <+4>:     mov     x29, sp
       0x0000000000400c38 <+8>:     str     w0, [sp, #28]
       0x0000000000400c3c <+12>:    strb    w1, [sp, #27]
       0x0000000000400c40 <+16>:    str     xzr, [sp, #40]
       0x0000000000400c44 <+20>:    str     xzr, [sp, #48]
       0x0000000000400c48 <+24>:    add     x0, sp, #0x1b
       0x0000000000400c4c <+28>:    mov     w3, #0x0                 // #0
       0x0000000000400c50 <+32>:    mov     x2, #0x1                 // #1
       0x0000000000400c54 <+36>:    mov     x1, x0
       0x0000000000400c58 <+40>:    ldr     w0, [sp, #28]
       0x0000000000400c5c <+44>:    bl      0x405e10 <mq_send>
       0x0000000000400c60 <+48>:    str     w0, [sp, #60]
       0x0000000000400c64 <+52>:    ldr     w0, [sp, #60]
       0x0000000000400c68 <+56>:    ldp     x29, x30, [sp], #64
       0x0000000000400c6c <+60>:    ret
    End of assembler dump.
    (gdb) info b
    No breakpoints or watchpoints.
    (gdb) c
    Continuing.
    
    Program received signal SIGILL, Illegal instruction.
    0x0000000000400c30 in send ()
    (gdb) x/10x 0x400c30
    0x400c30 <send>:    0xd42000a0   0xfd030091      0xe01f00b9      0xe16f0039
    0x400c40 <send+16>: 0xff1700f9   0xff1b00f9      0xe06f0091      0x03008052
    0x400c50 <send+32>: 0x220080d2   0xe10300aa
    (gdb) disassemble 0x400c30
    Dump of assembler code for function send:
    => 0x0000000000400c30 <+0>:     .inst   0xa00020d4 ; undefined
       0x0000000000400c34 <+4>:     mov     x29, sp
       0x0000000000400c38 <+8>:     str     w0, [sp, #28]
       0x0000000000400c3c <+12>:    strb    w1, [sp, #27]
       0x0000000000400c40 <+16>:    str     xzr, [sp, #40]
    
    Signed-off-by: junhua huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Stable-dep-of: 13f8f1e05f1d ("arm64: probes: Fix uprobes for big-endian kernels")
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin [+ + +]
Author: Florian Klink <[email protected]>
Date:   Tue Jul 16 02:03:11 2024 +0300

    ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin
    
    [ Upstream commit dc7785e4723510616d776862ddb4c08857a1bdb2 ]
    
    HDMI_HPD_N_1V8 is connected to GPIO pin 0, not 1.
    
    This fixes HDMI hotplug/output detection.
    
    See https://datasheets.raspberrypi.com/cm/cm3-schematics.pdf
    
    Signed-off-by: Florian Klink <[email protected]>
    Reviewed-by: Stefan Wahren <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Stefan Wahren <[email protected]>
    Fixes: a54fe8a6cf66 ("ARM: dts: add Raspberry Pi Compute Module 3 and IO board")
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Wed Aug 28 11:56:36 2024 +0200

    ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property
    
    [ Upstream commit 0e49cfe364dea4345551516eb2fe53135a10432b ]
    
    There is no "fsl,phy" property in pin controller pincfg nodes:
    
      imx7d-zii-rmu2.dtb: pinctrl@302c0000: enet1phyinterruptgrp: 'fsl,pins' is a required property
      imx7d-zii-rmu2.dtb: pinctrl@302c0000: enet1phyinterruptgrp: 'fsl,phy' does not match any of the regexes: 'pinctrl-[0-9]+'
    
    Fixes: f496e6750083 ("ARM: dts: Add ZII support for ZII i.MX7 RMU2 board")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: versatile: fix OF node leak in CPUs prepare [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Aug 26 07:49:33 2024 +0200

    ARM: versatile: fix OF node leak in CPUs prepare
    
    [ Upstream commit f2642d97f2105ed17b2ece0c597450f2ff95d704 ]
    
    Machine code is leaking OF node reference from of_find_matching_node()
    in realview_smp_prepare_cpus().
    
    Fixes: 5420b4b15617 ("ARM: realview: add an DT SMP boot method")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Liviu Dudau <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: allow module autoloading for table db1200_pids [+ + +]
Author: Hongbo Li <[email protected]>
Date:   Wed Aug 21 14:19:54 2024 +0800

    ASoC: allow module autoloading for table db1200_pids
    
    [ Upstream commit 0e9fdab1e8df490354562187cdbb8dec643eae2c ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly
    autoloaded based on the alias from platform_device_id table.
    
    Signed-off-by: Hongbo Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: cs42l51: Fix some error handling paths in cs42l51_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Oct 26 22:46:34 2024 +0200

    ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()
    
    [ Upstream commit d221b844ee79823ffc29b7badc4010bdb0960224 ]
    
    If devm_gpiod_get_optional() fails, we need to disable previously enabled
    regulators, as done in the other error handling path of the function.
    
    Also, gpiod_set_value_cansleep(, 1) needs to be called to undo a
    potential gpiod_set_value_cansleep(, 0).
    If the "reset" gpio is not defined, this additional call is just a no-op.
    
    This behavior is the same as the one already in the .remove() function.
    
    Fixes: 11b9cd748e31 ("ASoC: cs42l51: add reset management")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Charles Keepax <[email protected]>
    Link: https://patch.msgid.link/a5e5f4b9fb03f46abd2c93ed94b5c395972ce0d1.1729975570.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: meson: axg-card: fix 'use-after-free' [+ + +]
Author: Arseniy Krasnov <[email protected]>
Date:   Wed Sep 11 17:24:25 2024 +0300

    ASoC: meson: axg-card: fix 'use-after-free'
    
    [ Upstream commit 4f9a71435953f941969a4f017e2357db62d85a86 ]
    
    Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()',
    so move 'pad' pointer initialization after this function when memory is
    already reallocated.
    
    Kasan bug report:
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc
    Read of size 8 at addr ffff000000e8b260 by task modprobe/356
    
    CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1
    Call trace:
     dump_backtrace+0x94/0xec
     show_stack+0x18/0x24
     dump_stack_lvl+0x78/0x90
     print_report+0xfc/0x5c0
     kasan_report+0xb8/0xfc
     __asan_load8+0x9c/0xb8
     axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]
     meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]
     platform_probe+0x8c/0xf4
     really_probe+0x110/0x39c
     __driver_probe_device+0xb8/0x18c
     driver_probe_device+0x108/0x1d8
     __driver_attach+0xd0/0x25c
     bus_for_each_dev+0xe0/0x154
     driver_attach+0x34/0x44
     bus_add_driver+0x134/0x294
     driver_register+0xa8/0x1e8
     __platform_driver_register+0x44/0x54
     axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]
     do_one_initcall+0xdc/0x25c
     do_init_module+0x10c/0x334
     load_module+0x24c4/0x26cc
     init_module_from_file+0xd4/0x128
     __arm64_sys_finit_module+0x1f4/0x41c
     invoke_syscall+0x60/0x188
     el0_svc_common.constprop.0+0x78/0x13c
     do_el0_svc+0x30/0x40
     el0_svc+0x38/0x78
     el0t_64_sync_handler+0x100/0x12c
     el0t_64_sync+0x190/0x194
    
    Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support")
    Cc: [email protected]
    Signed-off-by: Arseniy Krasnov <[email protected]>
    Reviewed-by: Jerome Brunet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: meson: axg: extract sound card utils [+ + +]
Author: Jerome Brunet <[email protected]>
Date:   Thu Feb 13 16:51:57 2020 +0100

    ASoC: meson: axg: extract sound card utils
    
    [ Upstream commit aa9c3b7273a58b5d9b2c1161b76b5fc8ea8c159b ]
    
    This prepares the addition of the GX SoC family sound card driver.
    The GX sound card, while slightly different, will be similar to the
    AXG one. The purpose of this change is to share the utils common to
    both sound card driver.
    
    Signed-off-by: Jerome Brunet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: 4f9a71435953 ("ASoC: meson: axg-card: fix 'use-after-free'")
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tda7419: fix module autoloading [+ + +]
Author: Liao Chen <[email protected]>
Date:   Mon Aug 26 08:49:23 2024 +0000

    ASoC: tda7419: fix module autoloading
    
    [ Upstream commit 934b44589da9aa300201a00fe139c5c54f421563 ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
    based on the alias from of_device_id table.
    
    Signed-off-by: Liao Chen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ata: sata_sil: Rename sil_blacklist to sil_quirks [+ + +]
Author: Damien Le Moal <[email protected]>
Date:   Fri Jul 26 11:14:11 2024 +0900

    ata: sata_sil: Rename sil_blacklist to sil_quirks
    
    [ Upstream commit 93b0f9e11ce511353c65b7f924cf5f95bd9c3aba ]
    
    Rename the array sil_blacklist to sil_quirks as this name is more
    neutral and is also consistent with how this driver define quirks with
    the SIL_QUIRK_XXX flags.
    
    Signed-off-by: Damien Le Moal <[email protected]>
    Reviewed-by: Niklas Cassel <[email protected]>
    Reviewed-by: Igor Pylypiv <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
be2net: fix potential memory leak in be_xmit() [+ + +]
Author: Wang Hai <[email protected]>
Date:   Tue Oct 15 22:48:02 2024 +0800

    be2net: fix potential memory leak in be_xmit()
    
    [ Upstream commit e4dd8bfe0f6a23acd305f9b892c00899089bd621 ]
    
    The be_xmit() returns NETDEV_TX_OK without freeing skb
    in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.
    
    Fixes: 760c295e0e8d ("be2net: Support for OS2BMC.")
    Signed-off-by: Wang Hai <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Kalesh AP <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Andrew Lunn <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race [+ + +]
Author: Omar Sandoval <[email protected]>
Date:   Tue Oct 15 10:59:46 2024 -0700

    blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race
    
    commit e972b08b91ef48488bae9789f03cfedb148667fb upstream.
    
    We're seeing crashes from rq_qos_wake_function that look like this:
    
      BUG: unable to handle page fault for address: ffffafe180a40084
      #PF: supervisor write access in kernel mode
      #PF: error_code(0x0002) - not-present page
      PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0
      Oops: Oops: 0002 [#1] PREEMPT SMP PTI
      CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
      RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40
      Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00
      RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046
      RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011
      RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084
      RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011
      R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002
      R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003
      FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       <IRQ>
       try_to_wake_up+0x5a/0x6a0
       rq_qos_wake_function+0x71/0x80
       __wake_up_common+0x75/0xa0
       __wake_up+0x36/0x60
       scale_up.part.0+0x50/0x110
       wb_timer_fn+0x227/0x450
       ...
    
    So rq_qos_wake_function() calls wake_up_process(data->task), which calls
    try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock).
    
    p comes from data->task, and data comes from the waitqueue entry, which
    is stored on the waiter's stack in rq_qos_wait(). Analyzing the core
    dump with drgn, I found that the waiter had already woken up and moved
    on to a completely unrelated code path, clobbering what was previously
    data->task. Meanwhile, the waker was passing the clobbered garbage in
    data->task to wake_up_process(), leading to the crash.
    
    What's happening is that in between rq_qos_wake_function() deleting the
    waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding
    that it already got a token and returning. The race looks like this:
    
    rq_qos_wait()                           rq_qos_wake_function()
    ==============================================================
    prepare_to_wait_exclusive()
                                            data->got_token = true;
                                            list_del_init(&curr->entry);
    if (data.got_token)
            break;
    finish_wait(&rqw->wait, &data.wq);
      ^- returns immediately because
         list_empty_careful(&wq_entry->entry)
         is true
    ... return, go do something else ...
                                            wake_up_process(data->task)
                                              (NO LONGER VALID!)-^
    
    Normally, finish_wait() is supposed to synchronize against the waker.
    But, as noted above, it is returning immediately because the waitqueue
    entry has already been removed from the waitqueue.
    
    The bug is that rq_qos_wake_function() is accessing the waitqueue entry
    AFTER deleting it. Note that autoremove_wake_function() wakes the waiter
    and THEN deletes the waitqueue entry, which is the proper order.
    
    Fix it by swapping the order. We also need to use
    list_del_init_careful() to match the list_empty_careful() in
    finish_wait().
    
    Fixes: 38cfb5a45ee0 ("blk-wbt: improve waking of tasks")
    Cc: [email protected]
    Signed-off-by: Omar Sandoval <[email protected]>
    Acked-by: Tejun Heo <[email protected]>
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Link: https://lore.kernel.org/r/d3bee2463a67b1ee597211823bf7ad3721c26e41.1729014591.git.osandov@fb.com
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Mon Sep 2 21:03:27 2024 +0800

    block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()
    
    [ Upstream commit 0e456dba86c7f9a19792204a044835f1ca2c8dbb ]
    
    Consider the following merge chain:
    
    Process 1       Process 2       Process 3       Process 4
     (BIC1)          (BIC2)          (BIC3)          (BIC4)
      Λ                |               |               |
       \--------------\ \-------------\ \-------------\|
                       V               V               V
      bfqq1--------->bfqq2---------->bfqq3----------->bfqq4
    
    IO from Process 1 will get bfqf2 from BIC1 first, then
    bfq_setup_cooperator() will found bfqq2 already merged to bfqq3 and then
    handle this IO from bfqq3. However, the merge chain can be much deeper
    and bfqq3 can be merged to other bfqq as well.
    
    Fix this problem by iterating to the last bfqq in
    bfq_setup_cooperator().
    
    Fixes: 36eca8948323 ("block, bfq: add Early Queue Merge (EQM)")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block, bfq: don't break merge chain in bfq_split_bfqq() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Mon Sep 2 21:03:28 2024 +0800

    block, bfq: don't break merge chain in bfq_split_bfqq()
    
    [ Upstream commit 42c306ed723321af4003b2a41bb73728cab54f85 ]
    
    Consider the following scenario:
    
        Process 1       Process 2       Process 3       Process 4
         (BIC1)          (BIC2)          (BIC3)          (BIC4)
          Λ               |               |                |
           \-------------\ \-------------\ \--------------\|
                          V               V                V
          bfqq1--------->bfqq2---------->bfqq3----------->bfqq4
    ref    0              1               2                4
    
    If Process 1 issue a new IO and bfqq2 is found, and then bfq_init_rq()
    decide to spilt bfqq2 by bfq_split_bfqq(). Howerver, procress reference
    of bfqq2 is 1 and bfq_split_bfqq() just clear the coop flag, which will
    break the merge chain.
    
    Expected result: caller will allocate a new bfqq for BIC1
    
        Process 1       Process 2       Process 3       Process 4
         (BIC1)          (BIC2)          (BIC3)          (BIC4)
                          |               |                |
                           \-------------\ \--------------\|
                                          V                V
          bfqq1--------->bfqq2---------->bfqq3----------->bfqq4
    ref    0              0               1                3
    
    Since the condition is only used for the last bfqq4 when the previous
    bfqq2 and bfqq3 are already splited. Fix the problem by checking if
    bfqq is the last one in the merge chain as well.
    
    Fixes: 36eca8948323 ("block, bfq: add Early Queue Merge (EQM)")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block, bfq: fix possible UAF for bfqq->bic with merge chain [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Mon Sep 2 21:03:26 2024 +0800

    block, bfq: fix possible UAF for bfqq->bic with merge chain
    
    [ Upstream commit 18ad4df091dd5d067d2faa8fce1180b79f7041a7 ]
    
    1) initial state, three tasks:
    
                    Process 1       Process 2       Process 3
                     (BIC1)          (BIC2)          (BIC3)
                      |  Λ            |  Λ            |  Λ
                      |  |            |  |            |  |
                      V  |            V  |            V  |
                      bfqq1           bfqq2           bfqq3
    process ref:       1                1               1
    
    2) bfqq1 merged to bfqq2:
    
                    Process 1       Process 2       Process 3
                     (BIC1)          (BIC2)          (BIC3)
                      |               |               |  Λ
                      \--------------\|               |  |
                                      V               V  |
                      bfqq1--------->bfqq2            bfqq3
    process ref:       0                2               1
    
    3) bfqq2 merged to bfqq3:
    
                    Process 1       Process 2       Process 3
                     (BIC1)          (BIC2)          (BIC3)
             here -> Λ                |               |
                      \--------------\ \-------------\|
                                      V               V
                      bfqq1--------->bfqq2---------->bfqq3
    process ref:       0                1               3
    
    In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then
    get bfqq3 through merge chain, and finially handle IO by bfqq3.
    Howerver, current code will think bfqq2 is owned by BIC1, like initial
    state, and set bfqq2->bic to BIC1.
    
    bfq_insert_request
    -> by Process 1
     bfqq = bfq_init_rq(rq)
      bfqq = bfq_get_bfqq_handle_split
       bfqq = bic_to_bfqq
       -> get bfqq2 from BIC1
     bfqq->ref++
     rq->elv.priv[0] = bic
     rq->elv.priv[1] = bfqq
     if (bfqq_process_refs(bfqq) == 1)
      bfqq->bic = bic
      -> record BIC1 to bfqq2
    
      __bfq_insert_request
       new_bfqq = bfq_setup_cooperator
       -> get bfqq3 from bfqq2->new_bfqq
       bfqq_request_freed(bfqq)
       new_bfqq->ref++
       rq->elv.priv[1] = new_bfqq
       -> handle IO by bfqq3
    
    Fix the problem by checking bfqq is from merge chain fist. And this
    might fix a following problem reported by our syzkaller(unreproducible):
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
    BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
    BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
    Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595
    
    CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G             L     6.6.0-07439-gba2303cacfda #6
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
    Workqueue: kblockd blk_mq_requeue_work
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:364 [inline]
     print_report+0x10d/0x610 mm/kasan/report.c:475
     kasan_report+0x8e/0xc0 mm/kasan/report.c:588
     bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
     bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
     bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
     bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757
     bfq_init_rq block/bfq-iosched.c:6876 [inline]
     bfq_insert_request block/bfq-iosched.c:6254 [inline]
     bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304
     blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593
     blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502
     process_one_work kernel/workqueue.c:2627 [inline]
     process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
     worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
     kthread+0x33c/0x440 kernel/kthread.c:388
     ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
     </TASK>
    
    Allocated by task 20776:
     kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328
     kasan_slab_alloc include/linux/kasan.h:188 [inline]
     slab_post_alloc_hook mm/slab.h:763 [inline]
     slab_alloc_node mm/slub.c:3458 [inline]
     kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503
     ioc_create_icq block/blk-ioc.c:370 [inline]
     ioc_find_get_icq+0x180/0xaa0 block/blk-ioc.c:436
     bfq_prepare_request+0x39/0xf0 block/bfq-iosched.c:6812
     blk_mq_rq_ctx_init.isra.7+0x6ac/0xa00 block/blk-mq.c:403
     __blk_mq_alloc_requests+0xcc0/0x1070 block/blk-mq.c:517
     blk_mq_get_new_requests block/blk-mq.c:2940 [inline]
     blk_mq_submit_bio+0x624/0x27c0 block/blk-mq.c:3042
     __submit_bio+0x331/0x6f0 block/blk-core.c:624
     __submit_bio_noacct_mq block/blk-core.c:703 [inline]
     submit_bio_noacct_nocheck+0x816/0xb40 block/blk-core.c:732
     submit_bio_noacct+0x7a6/0x1b50 block/blk-core.c:826
     xlog_write_iclog+0x7d5/0xa00 fs/xfs/xfs_log.c:1958
     xlog_state_release_iclog+0x3b8/0x720 fs/xfs/xfs_log.c:619
     xlog_cil_push_work+0x19c5/0x2270 fs/xfs/xfs_log_cil.c:1330
     process_one_work kernel/workqueue.c:2627 [inline]
     process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
     worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
     kthread+0x33c/0x440 kernel/kthread.c:388
     ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
    
    Freed by task 946:
     kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522
     ____kasan_slab_free mm/kasan/common.c:236 [inline]
     __kasan_slab_free+0x12c/0x1c0 mm/kasan/common.c:244
     kasan_slab_free include/linux/kasan.h:164 [inline]
     slab_free_hook mm/slub.c:1815 [inline]
     slab_free_freelist_hook mm/slub.c:1841 [inline]
     slab_free mm/slub.c:3786 [inline]
     kmem_cache_free+0x118/0x6f0 mm/slub.c:3808
     rcu_do_batch+0x35c/0xe30 kernel/rcu/tree.c:2189
     rcu_core+0x819/0xd90 kernel/rcu/tree.c:2462
     __do_softirq+0x1b0/0x7a2 kernel/softirq.c:553
    
    Last potentially related work creation:
     kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
     __kasan_record_aux_stack+0xaf/0xc0 mm/kasan/generic.c:492
     __call_rcu_common kernel/rcu/tree.c:2712 [inline]
     call_rcu+0xce/0x1020 kernel/rcu/tree.c:2826
     ioc_destroy_icq+0x54c/0x830 block/blk-ioc.c:105
     ioc_release_fn+0xf0/0x360 block/blk-ioc.c:124
     process_one_work kernel/workqueue.c:2627 [inline]
     process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
     worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
     kthread+0x33c/0x440 kernel/kthread.c:388
     ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
    
    Second to last potentially related work creation:
     kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
     __kasan_record_aux_stack+0xaf/0xc0 mm/kasan/generic.c:492
     __call_rcu_common kernel/rcu/tree.c:2712 [inline]
     call_rcu+0xce/0x1020 kernel/rcu/tree.c:2826
     ioc_destroy_icq+0x54c/0x830 block/blk-ioc.c:105
     ioc_release_fn+0xf0/0x360 block/blk-ioc.c:124
     process_one_work kernel/workqueue.c:2627 [inline]
     process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
     worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
     kthread+0x33c/0x440 kernel/kthread.c:388
     ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
    
    The buggy address belongs to the object at ffff888123839d68
     which belongs to the cache bfq_io_cq of size 1360
    The buggy address is located 336 bytes inside of
     freed 1360-byte region [ffff888123839d68, ffff88812383a2b8)
    
    The buggy address belongs to the physical page:
    page:ffffea00048e0e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88812383f588 pfn:0x123838
    head:ffffea00048e0e00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    flags: 0x17ffffc0000a40(workingset|slab|head|node=0|zone=2|lastcpupid=0x1fffff)
    page_type: 0xffffffff()
    raw: 0017ffffc0000a40 ffff88810588c200 ffffea00048ffa10 ffff888105889488
    raw: ffff88812383f588 0000000000150006 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff888123839d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888123839e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff888123839e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                            ^
     ffff888123839f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888123839f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Fixes: 36eca8948323 ("block, bfq: add Early Queue Merge (EQM)")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Bluetooth: bnep: fix wild-memory-access in proto_unregister [+ + +]
Author: Ye Bin <[email protected]>
Date:   Mon Oct 14 17:07:08 2024 +0800

    Bluetooth: bnep: fix wild-memory-access in proto_unregister
    
    [ Upstream commit 64a90991ba8d4e32e3173ddd83d0b24167a5668c ]
    
    There's issue as follows:
      KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]
      CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G        W
      RIP: 0010:proto_unregister+0xee/0x400
      Call Trace:
       <TASK>
       __do_sys_delete_module+0x318/0x580
       do_syscall_64+0xc1/0x1d0
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()
    will cleanup all resource. Then when remove bnep module will call
    bnep_sock_cleanup() to cleanup sock's resource.
    To solve above issue just return bnep_sock_init()'s return value in
    bnep_exit().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Ye Bin <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Thu Sep 12 11:12:04 2024 +0800

    Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit 7b1ab460592ca818e7b52f27cd3ec86af79220d1 ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: bb7f4f0bcee6 ("btmrvl: add platform specific wakeup interrupt support")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: btmrvl_sdio: Refactor irq wakeup [+ + +]
Author: Abhishek Pandit-Subedi <[email protected]>
Date:   Wed Jun 10 18:53:55 2020 -0700

    Bluetooth: btmrvl_sdio: Refactor irq wakeup
    
    [ Upstream commit e660b3510eb4b3c06ce1188a1d305b6f653106fc ]
    
    Use device_init_wakeup to allow the Bluetooth dev to wake the system
    from suspend. Currently, the device can wake the system but no
    power/wakeup entry is created in sysfs to allow userspace to disable
    wakeup.
    
    Signed-off-by: Abhishek Pandit-Subedi <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>
    Stable-dep-of: 7b1ab460592c ("Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()")
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: btusb: Fix not handling ZPL/short-transfer [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Mon Sep 9 16:51:52 2024 -0400

    Bluetooth: btusb: Fix not handling ZPL/short-transfer
    
    [ Upstream commit 7b05933340f4490ef5b09e84d644d12484b05fdf ]
    
    Requesting transfers of the exact same size of wMaxPacketSize may result
    in ZPL/short-transfer since the USB stack cannot handle it as we are
    limiting the buffer size to be the same as wMaxPacketSize.
    
    Also, in terms of throughput this change has the same effect to
    interrupt endpoint as 290ba200815f "Bluetooth: Improve USB driver throughput
    by increasing the frame size" had for the bulk endpoint, so users of the
    advertisement bearer (e.g. BT Mesh) may benefit from this change.
    
    Fixes: 5e23b923da03 ("[Bluetooth] Add generic driver for Bluetooth USB devices")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Tested-by: Kiran K <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Oct 16 11:47:00 2024 -0400

    Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001
    
    commit 2c1dda2acc4192d826e84008d963b528e24d12bc upstream.
    
    Fake CSR controllers don't seem to handle short-transfer properly which
    cause command to time out:
    
    kernel: usb 1-1: new full-speed USB device number 19 using xhci_hcd
    kernel: usb 1-1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
    kernel: usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
    kernel: usb 1-1: Product: BT DONGLE10
    ...
    Bluetooth: hci1: Opcode 0x1004 failed: -110
    kernel: Bluetooth: hci1: command 0x1004 tx timeout
    
    According to USB Spec 2.0 Section 5.7.3 Interrupt Transfer Packet Size
    Constraints a interrupt transfer is considered complete when the size is 0
    (ZPL) or < wMaxPacketSize:
    
     'When an interrupt transfer involves more data than can fit in one
     data payload of the currently established maximum size, all data
     payloads are required to be maximum-sized except for the last data
     payload, which will contain the remaining data. An interrupt transfer
     is complete when the endpoint does one of the following:
    
     • Has transferred exactly the amount of data expected
     • Transfers a packet with a payload size less than wMaxPacketSize or
     transfers a zero-length packet'
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219365
    Fixes: 7b05933340f4 ("Bluetooth: btusb: Fix not handling ZPL/short-transfer")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Bluetooth: Remove debugfs directory on module init failure [+ + +]
Author: Aaron Thompson <[email protected]>
Date:   Fri Oct 4 23:04:10 2024 +0000

    Bluetooth: Remove debugfs directory on module init failure
    
    commit 1db4564f101b47188c1b71696bd342ef09172b22 upstream.
    
    If bt_init() fails, the debugfs directory currently is not removed. If
    the module is loaded again after that, the debugfs directory is not set
    up properly due to the existing directory.
    
      # modprobe bluetooth
      # ls -laF /sys/kernel/debug/bluetooth
      total 0
      drwxr-xr-x  2 root root 0 Sep 27 14:26 ./
      drwx------ 31 root root 0 Sep 27 14:25 ../
      -r--r--r--  1 root root 0 Sep 27 14:26 l2cap
      -r--r--r--  1 root root 0 Sep 27 14:26 sco
      # modprobe -r bluetooth
      # ls -laF /sys/kernel/debug/bluetooth
      ls: cannot access '/sys/kernel/debug/bluetooth': No such file or directory
      #
    
      # modprobe bluetooth
      modprobe: ERROR: could not insert 'bluetooth': Invalid argument
      # dmesg | tail -n 6
      Bluetooth: Core ver 2.22
      NET: Registered PF_BLUETOOTH protocol family
      Bluetooth: HCI device and connection manager initialized
      Bluetooth: HCI socket layer initialized
      Bluetooth: Faking l2cap_init() failure for testing
      NET: Unregistered PF_BLUETOOTH protocol family
      # ls -laF /sys/kernel/debug/bluetooth
      total 0
      drwxr-xr-x  2 root root 0 Sep 27 14:31 ./
      drwx------ 31 root root 0 Sep 27 14:26 ../
      #
    
      # modprobe bluetooth
      # dmesg | tail -n 7
      Bluetooth: Core ver 2.22
      debugfs: Directory 'bluetooth' with parent '/' already present!
      NET: Registered PF_BLUETOOTH protocol family
      Bluetooth: HCI device and connection manager initialized
      Bluetooth: HCI socket layer initialized
      Bluetooth: L2CAP socket layer initialized
      Bluetooth: SCO socket layer initialized
      # ls -laF /sys/kernel/debug/bluetooth
      total 0
      drwxr-xr-x  2 root root 0 Sep 27 14:31 ./
      drwx------ 31 root root 0 Sep 27 14:26 ../
      #
    
    Cc: [email protected]
    Fixes: ffcecac6a738 ("Bluetooth: Create root debugfs directory during module init")
    Signed-off-by: Aaron Thompson <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Mon Sep 30 13:26:21 2024 -0400

    Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change
    
    [ Upstream commit 08d1914293dae38350b8088980e59fbc699a72fe ]
    
    rfcomm_sk_state_change attempts to use sock_lock so it must never be
    called with it locked but rfcomm_sock_ioctl always attempt to lock it
    causing the following trace:
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
    ------------------------------------------------------
    syz-executor386/5093 is trying to acquire lock:
    ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
    ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73
    
    but task is already holding lock:
    ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491
    
    Reported-by: [email protected]
    Tested-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=d7ce59b06b3eb14fd218
    Fixes: 3241ad820dbb ("[Bluetooth] Add timestamp support to L2CAP, RFCOMM and SCO")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: Check percpu map value size first [+ + +]
Author: Tao Chen <[email protected]>
Date:   Tue Sep 10 22:41:10 2024 +0800

    bpf: Check percpu map value size first
    
    [ Upstream commit 1d244784be6b01162b732a5a7d637dfc024c3203 ]
    
    Percpu map is often used, but the map value size limit often ignored,
    like issue: https://github.com/iovisor/bcc/issues/2519. Actually,
    percpu map value size is bound by PCPU_MIN_UNIT_SIZE, so we
    can check the value size whether it exceeds PCPU_MIN_UNIT_SIZE first,
    like percpu map of local_storage. Maybe the error message seems clearer
    compared with "cannot allocate memory".
    
    Signed-off-by: Jinke Han <[email protected]>
    Signed-off-by: Tao Chen <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Fri Sep 13 21:17:46 2024 +0200

    bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit
    
    [ Upstream commit cfe69c50b05510b24e26ccb427c7cc70beafd6c1 ]
    
    The bpf_strtol() and bpf_strtoul() helpers are currently broken on 32bit:
    
    The argument type ARG_PTR_TO_LONG is BPF-side "long", not kernel-side "long"
    and therefore always considered fixed 64bit no matter if 64 or 32bit underlying
    architecture.
    
    This contract breaks in case of the two mentioned helpers since their BPF_CALL
    definition for the helpers was added with {unsigned,}long *res. Meaning, the
    transition from BPF-side "long" (BPF program) to kernel-side "long" (BPF helper)
    breaks here.
    
    Both helpers call __bpf_strtoll() with "long long" correctly, but later assigning
    the result into 32-bit "*(long *)" on 32bit architectures. From a BPF program
    point of view, this means upper bits will be seen as uninitialised.
    
    Therefore, fix both BPF_CALL signatures to {s,u}64 types to fix this situation.
    
    Now, changing also uapi/bpf.h helper documentation which generates bpf_helper_defs.h
    for BPF programs is tricky: Changing signatures there to __{s,u}64 would trigger
    compiler warnings (incompatible pointer types passing 'long *' to parameter of type
    '__s64 *' (aka 'long long *')) for existing BPF programs.
    
    Leaving the signatures as-is would be fine as from BPF program point of view it is
    still BPF-side "long" and thus equivalent to __{s,u}64 on 64 or 32bit underlying
    architectures.
    
    Note that bpf_strtol() and bpf_strtoul() are the only helpers with this issue.
    
    Fixes: d7a4cb9b6705 ("bpf: Introduce bpf_strtol and bpf_strtoul helpers")
    Reported-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix DEVMAP_HASH overflow check on 32-bit arches [+ + +]
Author: Toke Høiland-Jørgensen <[email protected]>
Date:   Thu Mar 7 13:03:35 2024 +0100

    bpf: Fix DEVMAP_HASH overflow check on 32-bit arches
    
    commit 281d464a34f540de166cee74b723e97ac2515ec3 upstream.
    
    The devmap code allocates a number hash buckets equal to the next power
    of two of the max_entries value provided when creating the map. When
    rounding up to the next power of two, the 32-bit variable storing the
    number of buckets can overflow, and the code checks for overflow by
    checking if the truncated 32-bit value is equal to 0. However, on 32-bit
    arches the rounding up itself can overflow mid-way through, because it
    ends up doing a left-shift of 32 bits on an unsigned long value. If the
    size of an unsigned long is four bytes, this is undefined behaviour, so
    there is no guarantee that we'll end up with a nice and tidy 0-value at
    the end.
    
    Syzbot managed to turn this into a crash on arm32 by creating a
    DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.
    Fix this by moving the overflow check to before the rounding up
    operation.
    
    Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
    Link: https://lore.kernel.org/r/[email protected]
    Reported-and-tested-by: [email protected]
    Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Pu Lehui <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bpf: Fix out-of-bounds write in trie_get_next_key() [+ + +]
Author: Byeonguk Jeong <[email protected]>
Date:   Sat Oct 26 14:02:43 2024 +0900

    bpf: Fix out-of-bounds write in trie_get_next_key()
    
    [ Upstream commit 13400ac8fb80c57c2bfb12ebd35ee121ce9b4d21 ]
    
    trie_get_next_key() allocates a node stack with size trie->max_prefixlen,
    while it writes (trie->max_prefixlen + 1) nodes to the stack when it has
    full paths from the root to leaves. For example, consider a trie with
    max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...
    0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with
    .prefixlen = 8 make 9 nodes be written on the node stack with size 8.
    
    Fixes: b471f2f1de8b ("bpf: implement MAP_GET_NEXT_KEY command for LPM_TRIE map")
    Signed-off-by: Byeonguk Jeong <[email protected]>
    Reviewed-by: Toke Høiland-Jørgensen <[email protected]>
    Tested-by: Hou Tao <[email protected]>
    Acked-by: Hou Tao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [+ + +]
Author: Qu Wenruo <[email protected]>
Date:   Sat Sep 28 08:05:58 2024 +0930

    btrfs: fix a NULL pointer dereference when failed to start a new trasacntion
    
    commit c3b47f49e83197e8dffd023ec568403bcdbb774b upstream.
    
    [BUG]
    Syzbot reported a NULL pointer dereference with the following crash:
    
      FAULT_INJECTION: forcing a failure.
       start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676
       prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642
       relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678
      ...
      BTRFS info (device loop0): balance: ended with status: -12
      Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI
      KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]
      RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926
      Call Trace:
       <TASK>
       commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496
       btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430
       del_balance_item fs/btrfs/volumes.c:3678 [inline]
       reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742
       btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574
       btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:907 [inline]
       __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    [CAUSE]
    The allocation failure happens at the start_transaction() inside
    prepare_to_relocate(), and during the error handling we call
    unset_reloc_control(), which makes fs_info->balance_ctl to be NULL.
    
    Then we continue the error path cleanup in btrfs_balance() by calling
    reset_balance_state() which will call del_balance_item() to fully delete
    the balance item in the root tree.
    
    However during the small window between set_reloc_contrl() and
    unset_reloc_control(), we can have a subvolume tree update and created a
    reloc_root for that subvolume.
    
    Then we go into the final btrfs_commit_transaction() of
    del_balance_item(), and into btrfs_update_reloc_root() inside
    commit_fs_roots().
    
    That function checks if fs_info->reloc_ctl is in the merge_reloc_tree
    stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer
    dereference.
    
    [FIX]
    Just add extra check on fs_info->reloc_ctl inside
    btrfs_update_reloc_root(), before checking
    fs_info->reloc_ctl->merge_reloc_tree.
    
    That DEAD_RELOC_TREE handling is to prevent further modification to the
    reloc tree during merge stage, but since there is no reloc_ctl at all,
    we do not need to bother that.
    
    Reported-by: [email protected]
    Link: https://lore.kernel.org/linux-btrfs/[email protected]/
    CC: [email protected] # 4.19+
    Reviewed-by: Josef Bacik <[email protected]>
    Signed-off-by: Qu Wenruo <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: wait for fixup workers before stopping cleaner kthread during umount [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Tue Oct 1 11:06:52 2024 +0100

    btrfs: wait for fixup workers before stopping cleaner kthread during umount
    
    commit 41fd1e94066a815a7ab0a7025359e9b40e4b3576 upstream.
    
    During unmount, at close_ctree(), we have the following steps in this order:
    
    1) Park the cleaner kthread - this doesn't destroy the kthread, it basically
       halts its execution (wake ups against it work but do nothing);
    
    2) We stop the cleaner kthread - this results in freeing the respective
       struct task_struct;
    
    3) We call btrfs_stop_all_workers() which waits for any jobs running in all
       the work queues and then free the work queues.
    
    Syzbot reported a case where a fixup worker resulted in a crash when doing
    a delayed iput on its inode while attempting to wake up the cleaner at
    btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread
    was already freed. This can happen during unmount because we don't wait
    for any fixup workers still running before we call kthread_stop() against
    the cleaner kthread, which stops and free all its resources.
    
    Fix this by waiting for any fixup workers at close_ctree() before we call
    kthread_stop() against the cleaner and run pending delayed iputs.
    
    The stack traces reported by syzbot were the following:
    
      BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065
      Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52
    
      CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
      Workqueue: btrfs-fixup btrfs_work_helper
      Call Trace:
       <TASK>
       __dump_stack lib/dump_stack.c:94 [inline]
       dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
       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
       __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065
       lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
       _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162
       class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]
       try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154
       btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842
       btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314
       process_one_work kernel/workqueue.c:3229 [inline]
       process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310
       worker_thread+0x870/0xd30 kernel/workqueue.c:3391
       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>
    
      Allocated by task 2:
       kasan_save_stack mm/kasan/common.c:47 [inline]
       kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
       unpoison_slab_object mm/kasan/common.c:319 [inline]
       __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345
       kasan_slab_alloc include/linux/kasan.h:247 [inline]
       slab_post_alloc_hook mm/slub.c:4086 [inline]
       slab_alloc_node mm/slub.c:4135 [inline]
       kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187
       alloc_task_struct_node kernel/fork.c:180 [inline]
       dup_task_struct+0x57/0x8c0 kernel/fork.c:1107
       copy_process+0x5d1/0x3d50 kernel/fork.c:2206
       kernel_clone+0x223/0x880 kernel/fork.c:2787
       kernel_thread+0x1bc/0x240 kernel/fork.c:2849
       create_kthread kernel/kthread.c:412 [inline]
       kthreadd+0x60d/0x810 kernel/kthread.c:765
       ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
       ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
    
      Freed by task 61:
       kasan_save_stack mm/kasan/common.c:47 [inline]
       kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
       kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
       poison_slab_object mm/kasan/common.c:247 [inline]
       __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
       kasan_slab_free include/linux/kasan.h:230 [inline]
       slab_free_hook mm/slub.c:2343 [inline]
       slab_free mm/slub.c:4580 [inline]
       kmem_cache_free+0x1a2/0x420 mm/slub.c:4682
       put_task_struct include/linux/sched/task.h:144 [inline]
       delayed_put_task_struct+0x125/0x300 kernel/exit.c:228
       rcu_do_batch kernel/rcu/tree.c:2567 [inline]
       rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823
       handle_softirqs+0x2c5/0x980 kernel/softirq.c:554
       __do_softirq kernel/softirq.c:588 [inline]
       invoke_softirq kernel/softirq.c:428 [inline]
       __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
       irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
       instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1037 [inline]
       sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1037
       asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
    
      Last potentially related work creation:
       kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
       __kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:541
       __call_rcu_common kernel/rcu/tree.c:3086 [inline]
       call_rcu+0x167/0xa70 kernel/rcu/tree.c:3190
       context_switch kernel/sched/core.c:5318 [inline]
       __schedule+0x184b/0x4ae0 kernel/sched/core.c:6675
       schedule_idle+0x56/0x90 kernel/sched/core.c:6793
       do_idle+0x56a/0x5d0 kernel/sched/idle.c:354
       cpu_startup_entry+0x42/0x60 kernel/sched/idle.c:424
       start_secondary+0x102/0x110 arch/x86/kernel/smpboot.c:314
       common_startup_64+0x13e/0x147
    
      The buggy address belongs to the object at ffff8880272a8000
       which belongs to the cache task_struct of size 7424
      The buggy address is located 2584 bytes inside of
       freed 7424-byte region [ffff8880272a8000, ffff8880272a9d00)
    
      The buggy address belongs to the physical page:
      page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x272a8
      head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
      flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
      page_type: f5(slab)
      raw: 00fff00000000040 ffff88801bafa500 dead000000000122 0000000000000000
      raw: 0000000000000000 0000000080040004 00000001f5000000 0000000000000000
      head: 00fff00000000040 ffff88801bafa500 dead000000000122 0000000000000000
      head: 0000000000000000 0000000080040004 00000001f5000000 0000000000000000
      head: 00fff00000000003 ffffea00009caa01 ffffffffffffffff 0000000000000000
      head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      page_owner tracks the page as allocated
      page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 2, tgid 2 (kthreadd), ts 71247381401, free_ts 71214998153
       set_page_owner include/linux/page_owner.h:32 [inline]
       post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537
       prep_new_page mm/page_alloc.c:1545 [inline]
       get_page_from_freelist+0x3039/0x3180 mm/page_alloc.c:3457
       __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4733
       alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265
       alloc_slab_page+0x6a/0x120 mm/slub.c:2413
       allocate_slab+0x5a/0x2f0 mm/slub.c:2579
       new_slab mm/slub.c:2632 [inline]
       ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3819
       __slab_alloc+0x58/0xa0 mm/slub.c:3909
       __slab_alloc_node mm/slub.c:3962 [inline]
       slab_alloc_node mm/slub.c:4123 [inline]
       kmem_cache_alloc_node_noprof+0x1fe/0x320 mm/slub.c:4187
       alloc_task_struct_node kernel/fork.c:180 [inline]
       dup_task_struct+0x57/0x8c0 kernel/fork.c:1107
       copy_process+0x5d1/0x3d50 kernel/fork.c:2206
       kernel_clone+0x223/0x880 kernel/fork.c:2787
       kernel_thread+0x1bc/0x240 kernel/fork.c:2849
       create_kthread kernel/kthread.c:412 [inline]
       kthreadd+0x60d/0x810 kernel/kthread.c:765
       ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
       ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
      page last free pid 5230 tgid 5230 stack trace:
       reset_page_owner include/linux/page_owner.h:25 [inline]
       free_pages_prepare mm/page_alloc.c:1108 [inline]
       free_unref_page+0xcd0/0xf00 mm/page_alloc.c:2638
       discard_slab mm/slub.c:2678 [inline]
       __put_partials+0xeb/0x130 mm/slub.c:3146
       put_cpu_partial+0x17c/0x250 mm/slub.c:3221
       __slab_free+0x2ea/0x3d0 mm/slub.c:4450
       qlink_free mm/kasan/quarantine.c:163 [inline]
       qlist_free_all+0x9a/0x140 mm/kasan/quarantine.c:179
       kasan_quarantine_reduce+0x14f/0x170 mm/kasan/quarantine.c:286
       __kasan_slab_alloc+0x23/0x80 mm/kasan/common.c:329
       kasan_slab_alloc include/linux/kasan.h:247 [inline]
       slab_post_alloc_hook mm/slub.c:4086 [inline]
       slab_alloc_node mm/slub.c:4135 [inline]
       kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4142
       getname_flags+0xb7/0x540 fs/namei.c:139
       do_sys_openat2+0xd2/0x1d0 fs/open.c:1409
       do_sys_open fs/open.c:1430 [inline]
       __do_sys_openat fs/open.c:1446 [inline]
       __se_sys_openat fs/open.c:1441 [inline]
       __x64_sys_openat+0x247/0x2a0 fs/open.c:1441
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
      Memory state around the buggy address:
       ffff8880272a8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880272a8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8880272a8a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                  ^
       ffff8880272a8a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880272a8b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
    
    Reported-by: [email protected]
    Link: https://lore.kernel.org/linux-btrfs/[email protected]/
    CC: [email protected] # 4.19+
    Reviewed-by: Qu Wenruo <[email protected]>
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Wed Sep 4 18:22:37 2024 -0700

    can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().
    
    [ Upstream commit 94b0818fa63555a65f6ba107080659ea6bcca63e ]
    
    syzbot reported a warning in bcm_release(). [0]
    
    The blamed change fixed another warning that is triggered when
    connect() is issued again for a socket whose connect()ed device has
    been unregistered.
    
    However, if the socket is just close()d without the 2nd connect(), the
    remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry()
    in bcm_release().
    
    Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify().
    
    [0]
    name '4986'
    WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711
    Modules linked in:
    CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
    RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711
    Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07
    RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246
    RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a
    R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640
    R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000
    FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     bcm_release+0x250/0x880 net/can/bcm.c:1578
     __sock_release net/socket.c:659 [inline]
     sock_close+0xbc/0x240 net/socket.c:1421
     __fput+0x24a/0x8a0 fs/file_table.c:422
     task_work_run+0x24f/0x310 kernel/task_work.c:228
     exit_task_work include/linux/task_work.h:40 [inline]
     do_exit+0xa2f/0x27f0 kernel/exit.c:882
     do_group_exit+0x207/0x2c0 kernel/exit.c:1031
     __do_sys_exit_group kernel/exit.c:1042 [inline]
     __se_sys_exit_group kernel/exit.c:1040 [inline]
     __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040
     x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7fcfb51ee969
    Code: Unable to access opcode bytes at 0x7fcfb51ee93f.
    RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969
    RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001
    RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000
    R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0
    R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160
     </TASK>
    
    Fixes: 76fe372ccb81 ("can: bcm: Remove proc entry when dev is unregistered.")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=0532ac7a06fb1a03187e
    Tested-by: [email protected]
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Vincent Mailhol <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: j1939: use correct function name in comment [+ + +]
Author: Zhang Changzhong <[email protected]>
Date:   Thu Aug 29 20:48:23 2024 +0800

    can: j1939: use correct function name in comment
    
    [ Upstream commit dc2ddcd136fe9b6196a7dd01f75f824beb02d43f ]
    
    The function j1939_cancel_all_active_sessions() was renamed to
    j1939_cancel_active_session() but name in comment wasn't updated.
    
    Signed-off-by: Zhang Changzhong <[email protected]>
    Acked-by: Oleksij Rempel <[email protected]>
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
CDC-NCM: avoid overflow in sanity checking [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Tue Feb 15 11:35:47 2022 +0100

    CDC-NCM: avoid overflow in sanity checking
    
    commit 8d2b1a1ec9f559d30b724877da4ce592edc41fdc upstream.
    
    A broken device may give an extreme offset like 0xFFF0
    and a reasonable length for a fragment. In the sanity
    check as formulated now, this will create an integer
    overflow, defeating the sanity check. Both offset
    and offset + len need to be checked in such a manner
    that no overflow can occur.
    And those quantities should be unsigned.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    Reviewed-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Bruno VERNAY <[email protected]>
    Signed-off-by: Hugo SIMELIERE <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ceph: remove the incorrect Fw reference check when dirtying pages [+ + +]
Author: Xiubo Li <[email protected]>
Date:   Thu Sep 5 06:22:18 2024 +0800

    ceph: remove the incorrect Fw reference check when dirtying pages
    
    [ Upstream commit c08dfb1b49492c09cf13838c71897493ea3b424e ]
    
    When doing the direct-io reads it will also try to mark pages dirty,
    but for the read path it won't hold the Fw caps and there is case
    will it get the Fw reference.
    
    Fixes: 5dda377cf0a6 ("ceph: set i_head_snapc when getting CEPH_CAP_FILE_WR reference")
    Signed-off-by: Xiubo Li <[email protected]>
    Reviewed-by: Patrick Donnelly <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cgroup: Fix potential overflow issue when checking max_depth [+ + +]
Author: Xiu Jianfeng <[email protected]>
Date:   Sat Oct 12 07:22:46 2024 +0000

    cgroup: Fix potential overflow issue when checking max_depth
    
    [ Upstream commit 3cc4e13bb1617f6a13e5e6882465984148743cf4 ]
    
    cgroup.max.depth is the maximum allowed descent depth below the current
    cgroup. If the actual descent depth is equal or larger, an attempt to
    create a new child cgroup will fail. However due to the cgroup->max_depth
    is of int type and having the default value INT_MAX, the condition
    'level > cgroup->max_depth' will never be satisfied, and it will cause
    an overflow of the level after it reaches to INT_MAX.
    
    Fix it by starting the level from 0 and using '>=' instead.
    
    It's worth mentioning that this issue is unlikely to occur in reality,
    as it's impossible to have a depth of INT_MAX hierarchy, but should be
    be avoided logically.
    
    Fixes: 1a926e0bbab8 ("cgroup: implement hierarchy limits")
    Signed-off-by: Xiu Jianfeng <[email protected]>
    Reviewed-by: Michal Koutný <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
clk: bcm: bcm53573: fix OF node leak in init [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Aug 26 08:58:01 2024 +0200

    clk: bcm: bcm53573: fix OF node leak in init
    
    [ Upstream commit f92d67e23b8caa81f6322a2bad1d633b00ca000e ]
    
    Driver code is leaking OF node reference from of_get_parent() in
    bcm53573_ilp_init().  Usage of of_get_parent() is not needed in the
    first place, because the parent node will not be freed while we are
    processing given node (triggered by CLK_OF_DECLARE()).  Thus fix the
    leak by accessing parent directly, instead of of_get_parent().
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: clk-rpmh: Fix overflow in BCM vote [+ + +]
Author: Mike Tipton <[email protected]>
Date:   Fri Aug 9 10:51:29 2024 +0530

    clk: qcom: clk-rpmh: Fix overflow in BCM vote
    
    [ Upstream commit a4e5af27e6f6a8b0d14bc0d7eb04f4a6c7291586 ]
    
    Valid frequencies may result in BCM votes that exceed the max HW value.
    Set vote ceiling to BCM_TCS_CMD_VOTE_MASK to ensure the votes aren't
    truncated, which can result in lower frequencies than desired.
    
    Fixes: 04053f4d23a4 ("clk: qcom: clk-rpmh: Add IPA clock support")
    Cc: [email protected]
    Signed-off-by: Mike Tipton <[email protected]>
    Reviewed-by: Taniya Das <[email protected]>
    Signed-off-by: Imran Shaik <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: rpmh: Simplify clk_rpmh_bcm_send_cmd() [+ + +]
Author: Stephen Boyd <[email protected]>
Date:   Mon Mar 9 15:12:31 2020 -0700

    clk: qcom: rpmh: Simplify clk_rpmh_bcm_send_cmd()
    
    [ Upstream commit 2cf7a4cbcb4e108aae666dc6a81cedf69e1cba37 ]
    
    This function has some duplication in unlocking a mutex and returns in a
    few different places. Let's use some if statements to consolidate code
    and make this a bit easier to read.
    
    Cc: Bjorn Andersson <[email protected]>
    CC: Taniya Das <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Stable-dep-of: a4e5af27e6f6 ("clk: qcom: clk-rpmh: Fix overflow in BCM vote")
    Signed-off-by: Sasha Levin <[email protected]>

clk: rockchip: fix error for unknown clocks [+ + +]
Author: Sebastian Reichel <[email protected]>
Date:   Mon Mar 25 20:33:36 2024 +0100

    clk: rockchip: fix error for unknown clocks
    
    commit 12fd64babaca4dc09d072f63eda76ba44119816a upstream.
    
    There is a clk == NULL check after the switch to check for
    unsupported clk types. Since clk is re-assigned in a loop,
    this check is useless right now for anything but the first
    round. Let's fix this up by assigning clk = NULL in the
    loop before the switch statement.
    
    Fixes: a245fecbb806 ("clk: rockchip: add basic infrastructure for clock branches")
    Cc: [email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    [added fixes + stable-cc]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228 [+ + +]
Author: Jonas Karlman <[email protected]>
Date:   Sat Jun 15 17:03:53 2024 +0000

    clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228
    
    [ Upstream commit 1d34b9757523c1ad547bd6d040381f62d74a3189 ]
    
    Similar to DCLK_LCDC on RK3328, the DCLK_VOP on RK3228 is typically
    parented by the hdmiphy clk and it is expected that the DCLK_VOP and
    hdmiphy clk rate are kept in sync.
    
    Use CLK_SET_RATE_PARENT and CLK_SET_RATE_NO_REPARENT flags, same as used
    on RK3328, to make full use of all possible supported display modes.
    
    Fixes: 0a9d4ac08ebc ("clk: rockchip: set the clock ids for RK3228 VOP")
    Fixes: 307a2e9ac524 ("clk: rockchip: add clock controller for rk3228")
    Signed-off-by: Jonas Karlman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: ti: dra7-atl: Fix leak of of_nodes [+ + +]
Author: David Lechner <[email protected]>
Date:   Mon Aug 26 10:35:29 2024 -0500

    clk: ti: dra7-atl: Fix leak of of_nodes
    
    [ Upstream commit 9d6e9f10e2e031fb7bfb3030a7d1afc561a28fea ]
    
    This fix leaking the of_node references in of_dra7_atl_clk_probe().
    
    The docs for of_parse_phandle_with_args() say that the caller must call
    of_node_put() on the returned node. This adds the missing of_node_put()
    to fix the leak.
    
    Fixes: 9ac33b0ce81f ("CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)")
    Signed-off-by: David Lechner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
clocksource/drivers/qcom: Add missing iounmap() on errors in msm_dt_timer_init() [+ + +]
Author: Ankit Agrawal <[email protected]>
Date:   Sat Jul 13 15:27:13 2024 +0530

    clocksource/drivers/qcom: Add missing iounmap() on errors in msm_dt_timer_init()
    
    [ Upstream commit ca140a0dc0a18acd4653b56db211fec9b2339986 ]
    
    Add the missing iounmap() when clock frequency fails to get read by the
    of_property_read_u32() call, or if the call to msm_timer_init() fails.
    
    Fixes: 6e3321631ac2 ("ARM: msm: Add DT support to msm_timer")
    Signed-off-by: Ankit Agrawal <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/20240713095713.GA430091@bnew-VirtualBox
    Signed-off-by: Daniel Lezcano <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: tmc: sg: Do not leak sg_table [+ + +]
Author: Suzuki K Poulose <[email protected]>
Date:   Tue Jul 2 14:28:46 2024 +0100

    coresight: tmc: sg: Do not leak sg_table
    
    [ Upstream commit c58dc5a1f886f2fcc1133746d0cbaa1fe7fd44ff ]
    
    Running perf with cs_etm on Juno triggers the following kmemleak warning !
    
    :~# cat /sys/kernel/debug/kmemleak
     unreferenced object 0xffffff8806b6d720 (size 96):
     comm "perf", pid 562, jiffies 4297810960
     hex dump (first 32 bytes):
     38 d8 13 07 88 ff ff ff 00 d0 9e 85 c0 ff ff ff  8...............
     00 10 00 88 c0 ff ff ff 00 f0 ff f7 ff 00 00 00  ................
     backtrace (crc 1dbf6e00):
     [<ffffffc08107381c>] kmemleak_alloc+0xbc/0xd8
     [<ffffffc0802f9798>] kmalloc_trace_noprof+0x220/0x2e8
     [<ffffffc07bb71948>] tmc_alloc_sg_table+0x48/0x208 [coresight_tmc]
     [<ffffffc07bb71cbc>] tmc_etr_alloc_sg_buf+0xac/0x240 [coresight_tmc]
     [<ffffffc07bb72538>] tmc_alloc_etr_buf.constprop.0+0x1f0/0x260 [coresight_tmc]
     [<ffffffc07bb7280c>] alloc_etr_buf.constprop.0.isra.0+0x74/0xa8 [coresight_tmc]
     [<ffffffc07bb72950>] tmc_alloc_etr_buffer+0x110/0x260 [coresight_tmc]
     [<ffffffc07bb38afc>] etm_setup_aux+0x204/0x3b0 [coresight]
     [<ffffffc08025837c>] rb_alloc_aux+0x20c/0x318
     [<ffffffc08024dd84>] perf_mmap+0x2e4/0x7a0
     [<ffffffc0802cceb0>] mmap_region+0x3b0/0xa08
     [<ffffffc0802cd8a8>] do_mmap+0x3a0/0x500
     [<ffffffc080295328>] vm_mmap_pgoff+0x100/0x1d0
     [<ffffffc0802cadf8>] ksys_mmap_pgoff+0xb8/0x110
     [<ffffffc080020688>] __arm64_sys_mmap+0x38/0x58
     [<ffffffc080028fc0>] invoke_syscall.constprop.0+0x58/0x100
    
    This due to the fact that we do not free the "sg_table" itself while
    freeing up  the SG table and data pages. Fix this by freeing the sg_table
    in tmc_free_sg_table().
    
    Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework")
    Cc: Mike Leach <[email protected]>
    Cc: James Clark <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Reviewed-by: Anshuman Khandual <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
crypto: aead,cipher - zeroize key buffer after use [+ + +]
Author: Hailey Mothershead <[email protected]>
Date:   Mon Apr 15 22:19:15 2024 +0000

    crypto: aead,cipher - zeroize key buffer after use
    
    commit 23e4099bdc3c8381992f9eb975c79196d6755210 upstream.
    
    I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
    cryptographic information should be zeroized once they are no longer
    needed. Accomplish this by using kfree_sensitive for buffers that
    previously held the private key.
    
    Signed-off-by: Hailey Mothershead <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Hugo SIMELIERE <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
debugobjects: Fix conditions in fill_pool() [+ + +]
Author: Zhen Lei <[email protected]>
Date:   Wed Sep 4 21:39:40 2024 +0800

    debugobjects: Fix conditions in fill_pool()
    
    commit 684d28feb8546d1e9597aa363c3bfcf52fe250b7 upstream.
    
    fill_pool() uses 'obj_pool_min_free' to decide whether objects should be
    handed back to the kmem cache. But 'obj_pool_min_free' records the lowest
    historical value of the number of objects in the object pool and not the
    minimum number of objects which should be kept in the pool.
    
    Use 'debug_objects_pool_min_level' instead, which holds the minimum number
    which was scaled to the number of CPUs at boot time.
    
    [ tglx: Massage change log ]
    
    Fixes: d26bf5056fc0 ("debugobjects: Reduce number of pool_lock acquisitions in fill_pool()")
    Fixes: 36c4ead6f6df ("debugobjects: Add global free list and the counter")
    Signed-off-by: Zhen Lei <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drbd: Add NULL check for net_conf to prevent dereference in state validation [+ + +]
Author: Mikhail Lobanov <[email protected]>
Date:   Mon Sep 9 09:37:36 2024 -0400

    drbd: Add NULL check for net_conf to prevent dereference in state validation
    
    commit a5e61b50c9f44c5edb6e134ede6fee8806ffafa9 upstream.
    
    If the net_conf pointer is NULL and the code attempts to access its
    fields without a check, it will lead to a null pointer dereference.
    Add a NULL check before dereferencing the pointer.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 44ed167da748 ("drbd: rcu_read_lock() and rcu_dereference() for tconn->net_conf")
    Cc: [email protected]
    Signed-off-by: Mikhail Lobanov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drbd: Fix atomicity violation in drbd_uuid_set_bm() [+ + +]
Author: Qiu-ji Chen <[email protected]>
Date:   Fri Sep 13 16:35:04 2024 +0800

    drbd: Fix atomicity violation in drbd_uuid_set_bm()
    
    commit 2f02b5af3a4482b216e6a466edecf6ba8450fa45 upstream.
    
    The violation of atomicity occurs when the drbd_uuid_set_bm function is
    executed simultaneously with modifying the value of
    device->ldev->md.uuid[UI_BITMAP]. Consider a scenario where, while
    device->ldev->md.uuid[UI_BITMAP] passes the validity check when its
    value is not zero, the value of device->ldev->md.uuid[UI_BITMAP] is
    written to zero. In this case, the check in drbd_uuid_set_bm might refer
    to the old value of device->ldev->md.uuid[UI_BITMAP] (before locking),
    which allows an invalid value to pass the validity check, resulting in
    inconsistency.
    
    To address this issue, it is recommended to include the data validity
    check within the locked section of the function. This modification
    ensures that the value of device->ldev->md.uuid[UI_BITMAP] does not
    change during the validation process, thereby maintaining its integrity.
    
    This possible bug is found by an experimental static analysis tool
    developed by our team. This tool analyzes the locking APIs to extract
    function pairs that can be concurrently executed, and then analyzes the
    instructions in the paired functions to identify possible concurrency
    bugs including data races and atomicity violations.
    
    Fixes: 9f2247bb9b75 ("drbd: Protect accesses to the uuid set with a spinlock")
    Cc: [email protected]
    Signed-off-by: Qiu-ji Chen <[email protected]>
    Reviewed-by: Philipp Reisner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
driver core: bus: Return -EIO instead of 0 when show/store invalid bus attribute [+ + +]
Author: Zijun Hu <[email protected]>
Date:   Wed Jul 24 21:54:48 2024 +0800

    driver core: bus: Return -EIO instead of 0 when show/store invalid bus attribute
    
    [ Upstream commit c0fd973c108cdc22a384854bc4b3e288a9717bb2 ]
    
    Return -EIO instead of 0 for below erroneous bus attribute operations:
     - read a bus attribute without show().
     - write a bus attribute without store().
    
    Signed-off-by: Zijun Hu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/misc: ti-st: Remove unneeded variable in st_tty_open [+ + +]
Author: zhong jiang <[email protected]>
Date:   Fri Sep 13 00:52:27 2019 +0800

    drivers/misc: ti-st: Remove unneeded variable in st_tty_open
    
    [ Upstream commit 8b063441b7417a79b0c27efc401479748ccf8ad1 ]
    
    st_tty_open do not need local variable to store different value,
    Hence just remove it.
    
    Signed-off-by: zhong jiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: c83212d79be2 ("firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()")
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error [+ + +]
Author: Junlin Li <[email protected]>
Date:   Wed Jul 3 01:50:23 2024 +0800

    drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error
    
    [ Upstream commit 46d7ebfe6a75a454a5fa28604f0ef1491f9d8d14 ]
    
    Ensure index in rtl2830_pid_filter does not exceed 31 to prevent
    out-of-bounds access.
    
    dev->filters is a 32-bit value, so set_bit and clear_bit functions should
    only operate on indices from 0 to 31. If index is 32, it will attempt to
    access a non-existent 33rd bit, leading to out-of-bounds access.
    Change the boundary check from index > 32 to index >= 32 to resolve this
    issue.
    
    Fixes: df70ddad81b4 ("[media] rtl2830: implement PID filter")
    Signed-off-by: Junlin Li <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error [+ + +]
Author: Junlin Li <[email protected]>
Date:   Tue Jul 2 21:24:13 2024 +0800

    drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
    
    [ Upstream commit 8ae06f360cfaca2b88b98ca89144548b3186aab1 ]
    
    Ensure index in rtl2832_pid_filter does not exceed 31 to prevent
    out-of-bounds access.
    
    dev->filters is a 32-bit value, so set_bit and clear_bit functions should
    only operate on indices from 0 to 31. If index is 32, it will attempt to
    access a non-existent 33rd bit, leading to out-of-bounds access.
    Change the boundary check from index > 32 to index >= 32 to resolve this
    issue.
    
    Signed-off-by: Junlin Li <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Fixes: 4b01e01a81b6 ("[media] rtl2832: implement PID filter")
    [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]
    Signed-off-by: Sasha Levin <[email protected]>

drivers: net: Fix Kconfig indentation, continued [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Thu Nov 21 21:28:28 2019 +0800

    drivers: net: Fix Kconfig indentation, continued
    
    [ Upstream commit 5421cf84af69a94ebb179fec252f3772c4681cca ]
    
    Adjust indentation from spaces to tab (+optional two spaces) as in
    coding style.  This fixes various indentation mixups (seven spaces,
    tab+one space, etc).
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: addf89774e48 ("ieee802154: Fix build error")
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind() [+ + +]
Author: Yuesong Li <[email protected]>
Date:   Thu Aug 22 17:09:27 2024 +0800

    drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()
    
    [ Upstream commit 94ebc3d3235c5c516f67315059ce657e5090e94b ]
    
    cocci reported a double assignment problem. Upon reviewing previous
    commits, it appears this may actually be an incorrect assignment.
    
    Fixes: 8b9550344d39 ("drm/ipp: clean up debug messages")
    Signed-off-by: Yuesong Li <[email protected]>
    Signed-off-by: Inki Dae <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Check stream before comparing them [+ + +]
Author: Alex Hung <[email protected]>
Date:   Thu Jun 27 20:05:14 2024 -0600

    drm/amd/display: Check stream before comparing them
    
    [ Upstream commit 35ff747c86767937ee1e0ca987545b7eed7a0810 ]
    
    [WHAT & HOW]
    amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is
    necessary to check for null before dereferencing them.
    
    This fixes 1 FORWARD_NULL issue reported by Coverity.
    
    Reviewed-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: Jerry Zuo <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Fix index out of bounds in degamma hardware format translation [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Sat Jul 20 17:48:27 2024 +0530

    drm/amd/display: Fix index out of bounds in degamma hardware format translation
    
    [ Upstream commit b7e99058eb2e86aabd7a10761e76cae33d22b49f ]
    
    Fixes index out of bounds issue in
    `cm_helper_translate_curve_to_degamma_hw_format` function. The issue
    could occur when the index 'i' exceeds the number of transfer function
    points (TRANSFER_FUNC_POINTS).
    
    The fix adds a check to ensure 'i' is within bounds before accessing the
    transfer function points. If 'i' is out of bounds the function returns
    false to indicate an error.
    
    Reported by smatch:
    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
    
    Cc: Tom Chung <[email protected]>
    Cc: Rodrigo Siqueira <[email protected]>
    Cc: Roman Li <[email protected]>
    Cc: Alex Hung <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Cc: Harry Wentland <[email protected]>
    Cc: Hamza Mahfooz <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Tom Chung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Initialize get_bytes_per_element's default to 1 [+ + +]
Author: Alex Hung <[email protected]>
Date:   Mon Jul 15 09:57:01 2024 -0600

    drm/amd/display: Initialize get_bytes_per_element's default to 1
    
    [ Upstream commit 4067f4fa0423a89fb19a30b57231b384d77d2610 ]
    
    Variables, used as denominators and maybe not assigned to other values,
    should not be 0. bytes_per_element_y & bytes_per_element_c are
    initialized by get_bytes_per_element() which should never return 0.
    
    This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.
    
    Signed-off-by: Alex Hung <[email protected]>
    Reviewed-by: Aurabindo Pillai <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Round calculated vtotal [+ + +]
Author: Robin Chen <[email protected]>
Date:   Fri Aug 23 15:00:28 2024 +0800

    drm/amd/display: Round calculated vtotal
    
    commit c03fca619fc687338a3b6511fdbed94096abdf79 upstream.
    
    [WHY]
    The calculated vtotal may has 1 line deviation. To get precisely
    vtotal number, round the vtotal result.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Cc: [email protected]
    Reviewed-by: Anthony Koo <[email protected]>
    Signed-off-by: Robin Chen <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amd: Guard against bad data for ATIF ACPI method [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Fri Oct 11 12:23:15 2024 -0500

    drm/amd: Guard against bad data for ATIF ACPI method
    
    commit bf58f03931fdcf7b3c45cb76ac13244477a60f44 upstream.
    
    If a BIOS provides bad data in response to an ATIF method call
    this causes a NULL pointer dereference in the caller.
    
    ```
    ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))
    ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)
    ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))
    ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))
    ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)
    ? exc_page_fault (arch/x86/mm/fault.c:1542)
    ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
    ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu
    ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu
    ```
    
    It has been encountered on at least one system, so guard for it.
    
    Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu: properly handle vbios fake edid sizing [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Tue Jul 23 13:23:56 2024 -0400

    drm/amdgpu: properly handle vbios fake edid sizing
    
    [ Upstream commit 8155566a26b8d6c1dd914f06a0c652e4e2f2adf1 ]
    
    The comment in the vbios structure says:
    // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128
    
    This fake edid struct has not been used in a long time, so I'm
    not sure if there were actually any boards out there with a non-128 byte
    EDID, but align the code with the comment.
    
    Reviewed-by: Thomas Weißschuh <[email protected]>
    Reported-by: Thomas Weißschuh <[email protected]>
    Link: https://lists.freedesktop.org/archives/amd-gfx/2024-June/109964.html
    Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amdgpu: Replace one-element array with flexible-array member [+ + +]
Author: Paulo Miguel Almeida <[email protected]>
Date:   Sat Oct 29 14:30:44 2022 +1300

    drm/amdgpu: Replace one-element array with flexible-array member
    
    [ Upstream commit 320e2590e281d0a7865e861f50155b5b435e9813 ]
    
    One-element arrays are deprecated, and we are replacing them with
    flexible array members instead. So, replace one-element array with
    flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and
    refactor the rest of the code accordingly.
    
    Important to mention is that doing a build before/after this patch
    results in no binary output differences.
    
    This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
    routines on memcpy() and help us make progress towards globally
    enabling -fstrict-flex-arrays=3 [1].
    
    Link: https://github.com/KSPP/linux/issues/79
    Link: https://github.com/KSPP/linux/issues/238
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1]
    
    Signed-off-by: Paulo Miguel Almeida <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 8155566a26b8 ("drm/amdgpu: properly handle vbios fake edid sizing")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/crtc: fix uninitialized variable use even harder [+ + +]
Author: Rob Clark <[email protected]>
Date:   Mon Feb 12 13:55:34 2024 -0800

    drm/crtc: fix uninitialized variable use even harder
    
    [ Upstream commit b6802b61a9d0e99dcfa6fff7c50db7c48a9623d3 ]
    
    DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop),
    which means we can't rely too much on variable initializers.
    
    Fixes: 6e455f5dcdd1 ("drm/crtc: fix uninitialized variable use")
    Signed-off-by: Rob Clark <[email protected]>
    Reviewed-by: Daniel Vetter <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Tested-by: Dmitry Baryshkov <[email protected]> # sc7180, sdm845
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/a5xx: disable preemption in submits by default [+ + +]
Author: Vladimir Lypak <[email protected]>
Date:   Sun Sep 1 13:54:00 2024 +0000

    drm/msm/a5xx: disable preemption in submits by default
    
    [ Upstream commit db9dec2db76146d65e1cfbb6afb2e2bd5dab67f8 ]
    
    Fine grain preemption (switching from/to points within submits)
    requires extra handling in command stream of those submits, especially
    when rendering with tiling (using GMEM). However this handling is
    missing at this point in mesa (and always was). For this reason we get
    random GPU faults and hangs if more than one priority level is used
    because local preemption is enabled prior to executing command stream
    from submit.
    With that said it was ahead of time to enable local preemption by
    default considering the fact that even on downstream kernel it is only
    enabled if requested via UAPI.
    
    Fixes: a7a4c19c36de ("drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LOCAL register")
    Signed-off-by: Vladimir Lypak <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/612041/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/a5xx: fix races in preemption evaluation stage [+ + +]
Author: Vladimir Lypak <[email protected]>
Date:   Sun Sep 1 13:54:02 2024 +0000

    drm/msm/a5xx: fix races in preemption evaluation stage
    
    [ Upstream commit ce050f307ad93bcc5958d0dd35fc276fd394d274 ]
    
    On A5XX GPUs when preemption is used it's invietable to enter a soft
    lock-up state in which GPU is stuck at empty ring-buffer doing nothing.
    This appears as full UI lockup and not detected as GPU hang (because
    it's not). This happens due to not triggering preemption when it was
    needed. Sometimes this state can be recovered by some new submit but
    generally it won't happen because applications are waiting for old
    submits to retire.
    
    One of the reasons why this happens is a race between a5xx_submit and
    a5xx_preempt_trigger called from IRQ during submit retire. Former thread
    updates ring->cur of previously empty and not current ring right after
    latter checks it for emptiness. Then both threads can just exit because
    for first one preempt_state wasn't NONE yet and for second one all rings
    appeared to be empty.
    
    To prevent such situations from happening we need to establish guarantee
    for preempt_trigger to make decision after each submit or retire. To
    implement this we serialize preemption initiation using spinlock. If
    switch is already in progress we need to re-trigger preemption when it
    finishes.
    
    Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets")
    Signed-off-by: Vladimir Lypak <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/612045/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/a5xx: properly clear preemption records on resume [+ + +]
Author: Vladimir Lypak <[email protected]>
Date:   Sun Sep 1 13:54:01 2024 +0000

    drm/msm/a5xx: properly clear preemption records on resume
    
    [ Upstream commit 64fd6d01a52904bdbda0ce810a45a428c995a4ca ]
    
    Two fields of preempt_record which are used by CP aren't reset on
    resume: "data" and "info". This is the reason behind faults which happen
    when we try to switch to the ring that was active last before suspend.
    In addition those faults can't be recovered from because we use suspend
    and resume to do so (keeping values of those fields again).
    
    Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets")
    Signed-off-by: Vladimir Lypak <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/612043/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation [+ + +]
Author: Jonathan Marek <[email protected]>
Date:   Mon Oct 7 01:01:49 2024 -0400

    drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation
    
    [ Upstream commit 358b762400bd94db2a14a72dfcef74c7da6bd845 ]
    
    When (mode->clock * 1000) is larger than (1<<31), int to unsigned long
    conversion will sign extend the int to 64 bits and the pclk_rate value
    will be incorrect.
    
    Fix this by making the result of the multiplication unsigned.
    
    Note that above (1<<32) would still be broken and require more changes, but
    its unlikely anyone will need that anytime soon.
    
    Fixes: c4d8cfe516dc ("drm/msm/dsi: add implementation for helper functions")
    Signed-off-by: Jonathan Marek <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/618434/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abhinav Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm: fix %s null argument error [+ + +]
Author: Sherry Yang <[email protected]>
Date:   Tue Aug 27 09:53:37 2024 -0700

    drm/msm: fix %s null argument error
    
    [ Upstream commit 25b85075150fe8adddb096db8a4b950353045ee1 ]
    
    The following build error was triggered because of NULL string argument:
    
    BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c: In function 'mdp5_smp_dump':
    BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=]
    BUILDSTDERR:   352 |                         drm_printf(p, "%s:%d\t%d\t%s\n",
    BUILDSTDERR:       |                                                   ^~
    BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=]
    
    This happens from the commit a61ddb4393ad ("drm: enable (most) W=1
    warnings by default across the subsystem"). Using "(null)" instead
    to fix it.
    
    Fixes: bc5289eed481 ("drm/msm/mdp5: add debugfs to show smp block status")
    Signed-off-by: Sherry Yang <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/611071/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm: Fix incorrect file name output in adreno_request_fw() [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Fri Jul 5 12:13:12 2024 +0300

    drm/msm: Fix incorrect file name output in adreno_request_fw()
    
    [ Upstream commit e19366911340c2313a1abbb09c54eaf9bdea4f58 ]
    
    In adreno_request_fw() when debugging information is printed to the log
    after firmware load, an incorrect filename is printed. 'newname' is used
    instead of 'fwname', so prefix "qcom/" is being added to filename.
    Looks like "copy-paste" mistake.
    
    Fix this mistake by replacing 'newname' with 'fwname'.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 2c41ef1b6f7d ("drm/msm/adreno: deal with linux-firmware fw paths")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/602382/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/printer: Allow NULL data in devcoredump printer [+ + +]
Author: Matthew Brost <[email protected]>
Date:   Thu Aug 1 08:41:17 2024 -0700

    drm/printer: Allow NULL data in devcoredump printer
    
    [ Upstream commit 53369581dc0c68a5700ed51e1660f44c4b2bb524 ]
    
    We want to determine the size of the devcoredump before writing it out.
    To that end, we will run the devcoredump printer with NULL data to get
    the size, alloc data based on the generated offset, then run the
    devcorecump again with a valid data pointer to print.  This necessitates
    not writing data to the data pointer on the initial pass, when it is
    NULL.
    
    v5:
     - Better commit message (Jonathan)
     - Add kerenl doc with examples (Jani)
    
    Cc: Maarten Lankhorst <[email protected]>
    Acked-by: Maarten Lankhorst <[email protected]>
    Signed-off-by: Matthew Brost <[email protected]>
    Reviewed-by: Jonathan Cavitt <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Tue Aug 6 10:19:04 2024 -0700

    drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets
    
    [ Upstream commit 3fbaf475a5b8361ebee7da18964db809e37518b7 ]
    
    Several cs track offsets (such as 'track->db_s_read_offset')
    either are initialized with or plainly take big enough values that,
    once shifted 8 bits left, may be hit with integer overflow if the
    resulting values end up going over u32 limit.
    
    Same goes for a few instances of 'surf.layer_size * mslice'
    multiplications that are added to 'offset' variable - they may
    potentially overflow as well and need to be validated properly.
    
    While some debug prints in this code section take possible overflow
    issues into account, simply casting to (unsigned long) may be
    erroneous in its own way, as depending on CPU architecture one is
    liable to get different results.
    
    Fix said problems by:
     - casting 'offset' to fixed u64 data type instead of
     ambiguous unsigned long.
     - casting one of the operands in vulnerable to integer
     overflow cases to u64.
     - adjust format specifiers in debug prints to properly
     represent 'offset' values.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 285484e2d55e ("drm/radeon: add support for evergreen/ni tiling informations v11")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/r100: Handle unknown family in r100_cp_init_microcode() [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Jul 30 17:58:12 2024 +0200

    drm/radeon/r100: Handle unknown family in r100_cp_init_microcode()
    
    [ Upstream commit c6dbab46324b1742b50dc2fb5c1fee2c28129439 ]
    
    With -Werror:
    
        In function ‘r100_cp_init_microcode’,
            inlined from ‘r100_cp_init’ at drivers/gpu/drm/radeon/r100.c:1136:7:
        include/linux/printk.h:465:44: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
          465 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
              |                                            ^
        include/linux/printk.h:437:17: note: in definition of macro ‘printk_index_wrap’
          437 |                 _p_func(_fmt, ##__VA_ARGS__);                           \
              |                 ^~~~~~~
        include/linux/printk.h:508:9: note: in expansion of macro ‘printk’
          508 |         printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
              |         ^~~~~~
        drivers/gpu/drm/radeon/r100.c:1062:17: note: in expansion of macro ‘pr_err’
         1062 |                 pr_err("radeon_cp: Failed to load firmware \"%s\"\n", fw_name);
              |                 ^~~~~~
    
    Fix this by converting the if/else if/... construct into a proper
    switch() statement with a default to handle the error case.
    
    As a bonus, the generated code is ca. 100 bytes smaller (with gcc 11.4.0
    targeting arm32).
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon: properly handle vbios fake edid sizing [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Tue Jul 23 13:31:58 2024 -0400

    drm/radeon: properly handle vbios fake edid sizing
    
    [ Upstream commit 17c6baff3d5f65c8da164137a58742541a060b2f ]
    
    The comment in the vbios structure says:
    // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128
    
    This fake edid struct has not been used in a long time, so I'm
    not sure if there were actually any boards out there with a non-128 byte
    EDID, but align the code with the comment.
    
    Reviewed-by: Thomas Weißschuh <[email protected]>
    Reported-by: Thomas Weißschuh <[email protected]>
    Link: https://lists.freedesktop.org/archives/amd-gfx/2024-June/109964.html
    Fixes: c324acd5032f ("drm/radeon/kms: parse the extended LCD info block")
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/radeon: Replace one-element array with flexible-array member [+ + +]
Author: Paulo Miguel Almeida <[email protected]>
Date:   Sat Oct 29 16:32:05 2022 +1300

    drm/radeon: Replace one-element array with flexible-array member
    
    [ Upstream commit c81c5bd5cf2f428867e0bcfcccd4e4d2f8c68f51 ]
    
    One-element arrays are deprecated, and we are replacing them with
    flexible array members instead. So, replace one-element array with
    flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and
    refactor the rest of the code accordingly.
    
    It's worth mentioning that doing a build before/after this patch results
    in no binary output differences.
    
    This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
    routines on memcpy() and help us make progress towards globally
    enabling -fstrict-flex-arrays=3 [1].
    
    Link: https://github.com/KSPP/linux/issues/79
    Link: https://github.com/KSPP/linux/issues/239
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1]
    
    Reviewed-by: Kees Cook <[email protected]>
    Signed-off-by: Paulo Miguel Almeida <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: 17c6baff3d5f ("drm/radeon: properly handle vbios fake edid sizing")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode [+ + +]
Author: Jonas Karlman <[email protected]>
Date:   Sat Jun 15 17:03:55 2024 +0000

    drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode
    
    [ Upstream commit a5d024541ec466f428e6c514577d511a40779c7b ]
    
    EDID cannot be read on RK3328 until after read_hpd has been called and
    correct io voltage has been configured based on connection status.
    
    When a forced mode is used, e.g. video=1920x1080@60e, the connector
    detect ops, that in turn normally calls the read_hpd, never gets called.
    
    This result in reading EDID to fail in connector get_modes ops.
    
    Call dw_hdmi_rk3328_read_hpd at end of dw_hdmi_rk3328_setup_hpd to
    correct io voltage and allow reading EDID after setup_hpd.
    
    Fixes: 1c53ba8f22a1 ("drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328")
    Signed-off-by: Jonas Karlman <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/rockchip: vop: Allow 4096px width scaling [+ + +]
Author: Alex Bee <[email protected]>
Date:   Sat Jun 15 17:03:54 2024 +0000

    drm/rockchip: vop: Allow 4096px width scaling
    
    [ Upstream commit 0ef968d91a20b5da581839f093f98f7a03a804f7 ]
    
    There is no reason to limit VOP scaling to 3840px width, the limit of
    RK3288, when there are newer VOP versions that support 4096px width.
    
    Change to enforce a maximum of 4096px width plane scaling, the maximum
    supported output width of the VOP versions supported by this driver.
    
    Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale")
    Signed-off-by: Alex Bee <[email protected]>
    Signed-off-by: Jonas Karlman <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/stm: Fix an error handling path in stm_drm_platform_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Jan 6 17:54:32 2024 +0100

    drm/stm: Fix an error handling path in stm_drm_platform_probe()
    
    [ Upstream commit ce7c90bfda2656418c69ba0dd8f8a7536b8928d4 ]
    
    If drm_dev_register() fails, a call to drv_load() must be undone, as
    already done in the remove function.
    
    Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Acked-by: Raphael Gallais-Pou <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20fff7f853f20a48a96db8ff186124470ec4d976.1704560028.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Raphael Gallais-Pou <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Tue Aug 27 12:45:23 2024 +0200

    drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA
    
    [ Upstream commit d92b90f9a54d9300a6e883258e79f36dab53bfae ]
    
    Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with
    a real VLA to fix a "memcpy: detected field-spanning write error" warning:
    
    [   13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4)
    [   13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo]
    [   13.320038] Call Trace:
    [   13.320173]  hgsmi_update_pointer_shape [vboxvideo]
    [   13.320184]  vbox_cursor_atomic_update [vboxvideo]
    
    Note as mentioned in the added comment it seems the original length
    calculation for the allocated and send hgsmi buffer is 4 bytes too large.
    Changing this is not the goal of this patch, so this behavior is kept.
    
    Signed-off-by: Hans de Goede <[email protected]>
    Reviewed-by: Jani Nikula <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vmwgfx: Handle surface check failure correctly [+ + +]
Author: Nikolay Kuratov <[email protected]>
Date:   Wed Oct 2 15:24:29 2024 +0300

    drm/vmwgfx: Handle surface check failure correctly
    
    commit 26498b8d54373d31a621d7dec95c4bd842563b3b upstream.
    
    Currently if condition (!bo and !vmw_kms_srf_ok()) was met
    we go to err_out with ret == 0.
    err_out dereferences vfb if ret == 0, but in our case vfb is still NULL.
    
    Fix this by assigning sensible error to ret.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE
    
    Signed-off-by: Nikolay Kuratov <[email protected]>
    Cc: [email protected]
    Fixes: 810b3e1683d0 ("drm/vmwgfx: Support topology greater than texture size")
    Signed-off-by: Zack Rusin <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS [+ + +]
Author: Thomas Zimmermann <[email protected]>
Date:   Mon Sep 23 09:58:14 2024 +0200

    drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
    
    commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
    
    FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
    should only use UAPI types. Hence replace struct drm_rect with
    struct drm_mode_rect in drm_atomic_plane_set_property(). Both types
    are identical in practice, so there's no change in behavior.
    
    Reported-by: Ville Syrjälä <[email protected]>
    Closes: https://lore.kernel.org/dri-devel/[email protected]/
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane update")
    Cc: Lukasz Spintzyk <[email protected]>
    Cc: Deepak Rawat <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: Thomas Hellstrom <[email protected]>
    Cc: David Airlie <[email protected]>
    Cc: Simona Vetter <[email protected]>
    Cc: Maarten Lankhorst <[email protected]>
    Cc: Maxime Ripard <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: [email protected]
    Cc: <[email protected]> # v5.0+
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm: komeda: Fix an issue related to normalized zpos [+ + +]
Author: hongchi.peng <[email protected]>
Date:   Mon Aug 26 10:45:17 2024 +0800

    drm: komeda: Fix an issue related to normalized zpos
    
    [ Upstream commit 258905cb9a6414be5c9ca4aa20ef855f8dc894d4 ]
    
    We use komeda_crtc_normalize_zpos to normalize zpos of affected planes
    to their blending zorder in CU. If there's only one slave plane in
    affected planes and its layer_split property is enabled, order++ for
    its split layer, so that when calculating the normalized_zpos
    of master planes, the split layer of the slave plane is included, but
    the max_slave_zorder does not include the split layer and keep zero
    because there's only one slave plane in affacted planes, although we
    actually use two slave layers in this commit.
    
    In most cases, this bug does not result in a commit failure, but assume
    the following situation:
        slave_layer 0: zpos = 0, layer split enabled, normalized_zpos =
        0;(use slave_layer 2 as its split layer)
        master_layer 0: zpos = 2, layer_split enabled, normalized_zpos =
        2;(use master_layer 2 as its split layer)
        master_layer 1: zpos = 4, normalized_zpos = 4;
        master_layer 3: zpos = 5, normalized_zpos = 5;
        kcrtc_st->max_slave_zorder = 0;
    When we use master_layer 3 as a input of CU in function
    komeda_compiz_set_input and check it with function
    komeda_component_check_input, the parameter idx is equal to
    normailzed_zpos minus max_slave_zorder, the value of idx is 5
    and is euqal to CU's max_active_inputs, so that
    komeda_component_check_input returns a -EINVAL value.
    
    To fix the bug described above, when calculating the max_slave_zorder
    with the layer_split enabled, count the split layer in this calculation
    directly.
    
    Signed-off-by: hongchi.peng <[email protected]>
    Acked-by: Liviu Dudau <[email protected]>
    Signed-off-by: Liviu Dudau <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm: omapdrm: Add missing check for alloc_ordered_workqueue [+ + +]
Author: Ma Ke <[email protected]>
Date:   Thu Aug 8 14:13:36 2024 +0800

    drm: omapdrm: Add missing check for alloc_ordered_workqueue
    
    commit e794b7b9b92977365c693760a259f8eef940c536 upstream.
    
    As it may return NULL pointer and cause NULL pointer dereference. Add check
    for the return value of alloc_ordered_workqueue.
    
    Cc: [email protected]
    Fixes: 2f95bc6d324a ("drm: omapdrm: Perform initialization/cleanup at probe/remove time")
    Signed-off-by: Ma Ke <[email protected]>
    Signed-off-by: Tomi Valkeinen <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dt-bindings: gpu: Convert Samsung Image Rotator to dt-schema [+ + +]
Author: Maciej Falkowski <[email protected]>
Date:   Tue Sep 17 12:37:27 2019 +0200

    dt-bindings: gpu: Convert Samsung Image Rotator to dt-schema
    
    [ Upstream commit 6e3ffcd592060403ee2d956c9b1704775898db79 ]
    
    Convert Samsung Image Rotator to newer dt-schema format.
    
    Signed-off-by: Maciej Falkowski <[email protected]>
    Signed-off-by: Marek Szyprowski <[email protected]>
    Signed-off-by: Rob Herring <[email protected]>
    Stable-dep-of: 338c4d3902fe ("igb: Disable threaded IRQ for igb_msix_other")
    Signed-off-by: Sasha Levin <[email protected]>

 
erofs: fix lz4 inplace decompression [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Wed Dec 6 12:55:34 2023 +0800

    erofs: fix lz4 inplace decompression
    
    commit 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de upstream.
    
    Currently EROFS can map another compressed buffer for inplace
    decompression, that was used to handle the cases that some pages of
    compressed data are actually not in-place I/O.
    
    However, like most simple LZ77 algorithms, LZ4 expects the compressed
    data is arranged at the end of the decompressed buffer and it
    explicitly uses memmove() to handle overlapping:
      __________________________________________________________
     |_ direction of decompression --> ____ |_ compressed data _|
    
    Although EROFS arranges compressed data like this, it typically maps two
    individual virtual buffers so the relative order is uncertain.
    Previously, it was hardly observed since LZ4 only uses memmove() for
    short overlapped literals and x86/arm64 memmove implementations seem to
    completely cover it up and they don't have this issue.  Juhyung reported
    that EROFS data corruption can be found on a new Intel x86 processor.
    After some analysis, it seems that recent x86 processors with the new
    FSRM feature expose this issue with "rep movsb".
    
    Let's strictly use the decompressed buffer for lz4 inplace
    decompression for now.  Later, as an useful improvement, we could try
    to tie up these two buffers together in the correct order.
    
    Reported-and-tested-by: Juhyung Park <[email protected]>
    Closes: https://lore.kernel.org/r/CAD14+f2AVKf8Fa2OO1aAUdDNTDsVzzR6ctU_oJSmTyd6zSYR2Q@mail.gmail.com
    Fixes: 0ffd71bcc3a0 ("staging: erofs: introduce LZ4 decompression inplace")
    Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
    Cc: stable <[email protected]> # 5.4+
    Tested-by: Yifan Zhao <[email protected]>
    Signed-off-by: Gao Xiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ext4: aovid use-after-free in ext4_ext_insert_extent() [+ + +]
Author: Baokun Li <[email protected]>
Date:   Thu Aug 22 10:35:26 2024 +0800

    ext4: aovid use-after-free in ext4_ext_insert_extent()
    
    commit a164f3a432aae62ca23d03e6d926b122ee5b860d upstream.
    
    As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is
    reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and
    cause UAF. Below is a sample trace with dummy values:
    
    ext4_ext_insert_extent
      path = *ppath = 2000
      ext4_ext_create_new_leaf(ppath)
        ext4_find_extent(ppath)
          path = *ppath = 2000
          if (depth > path[0].p_maxdepth)
                kfree(path = 2000);
                *ppath = path = NULL;
          path = kcalloc() = 3000
          *ppath = 3000;
          return path;
      /* here path is still 2000, UAF! */
      eh = path[depth].p_hdr
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330
    Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179
    CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866
    Call Trace:
     <TASK>
     ext4_ext_insert_extent+0x26d4/0x3330
     ext4_ext_map_blocks+0xe22/0x2d40
     ext4_map_blocks+0x71e/0x1700
     ext4_do_writepages+0x1290/0x2800
    [...]
    
    Allocated by task 179:
     ext4_find_extent+0x81c/0x1f70
     ext4_ext_map_blocks+0x146/0x2d40
     ext4_map_blocks+0x71e/0x1700
     ext4_do_writepages+0x1290/0x2800
     ext4_writepages+0x26d/0x4e0
     do_writepages+0x175/0x700
    [...]
    
    Freed by task 179:
     kfree+0xcb/0x240
     ext4_find_extent+0x7c0/0x1f70
     ext4_ext_insert_extent+0xa26/0x3330
     ext4_ext_map_blocks+0xe22/0x2d40
     ext4_map_blocks+0x71e/0x1700
     ext4_do_writepages+0x1290/0x2800
     ext4_writepages+0x26d/0x4e0
     do_writepages+0x175/0x700
    [...]
    ==================================================================
    
    So use *ppath to update the path to avoid the above problem.
    
    Reported-by: Ojaswin Mujoo <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Fixes: 10809df84a4d ("ext4: teach ext4_ext_find_extent() to realloc path if necessary")
    Cc: [email protected]
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: avoid negative min_clusters in find_group_orlov() [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Tue Aug 20 21:22:30 2024 +0800

    ext4: avoid negative min_clusters in find_group_orlov()
    
    [ Upstream commit bb0a12c3439b10d88412fd3102df5b9a6e3cd6dc ]
    
    min_clusters is signed integer and will be converted to unsigned
    integer when compared with unsigned number stats.free_clusters.
    If min_clusters is negative, it will be converted to a huge unsigned
    value in which case all groups may not meet the actual desired free
    clusters.
    Set negative min_clusters to 0 to avoid unexpected behavior.
    
    Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3")
    Signed-off-by: Kemeng Shi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: avoid OOB when system.data xattr changes underneath the filesystem [+ + +]
Author: Thadeu Lima de Souza Cascardo <[email protected]>
Date:   Wed Aug 21 12:23:24 2024 -0300

    ext4: avoid OOB when system.data xattr changes underneath the filesystem
    
    [ Upstream commit c6b72f5d82b1017bad80f9ebf502832fc321d796 ]
    
    When looking up for an entry in an inlined directory, if e_value_offs is
    changed underneath the filesystem by some change in the block device, it
    will lead to an out-of-bounds access that KASAN detects as an UAF.
    
    EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
    loop0: detected capacity change from 2048 to 2047
    ==================================================================
    BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
    Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103
    
    CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
    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
     ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
     ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
     __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573
     ext4_lookup_entry fs/ext4/namei.c:1727 [inline]
     ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795
     lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633
     filename_create+0x297/0x540 fs/namei.c:3980
     do_symlinkat+0xf9/0x3a0 fs/namei.c:4587
     __do_sys_symlinkat fs/namei.c:4610 [inline]
     __se_sys_symlinkat fs/namei.c:4607 [inline]
     __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f3e73ced469
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a
    RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469
    RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0
    RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290
    R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c
    R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0
     </TASK>
    
    Calling ext4_xattr_ibody_find right after reading the inode with
    ext4_get_inode_loc will lead to a check of the validity of the xattrs,
    avoiding this problem.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=0c2508114d912a54ee79
    Fixes: e8e948e7802a ("ext4: let ext4_find_entry handle inline data")
    Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard [+ + +]
Author: yangerkun <[email protected]>
Date:   Sat Aug 17 16:55:10 2024 +0800

    ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard
    
    [ Upstream commit 20cee68f5b44fdc2942d20f3172a262ec247b117 ]
    
    Commit 3d56b8d2c74c ("ext4: Speed up FITRIM by recording flags in
    ext4_group_info") speed up fstrim by skipping trim trimmed group. We
    also has the chance to clear trimmed once there exists some block free
    for this group(mount without discard), and the next trim for this group
    will work well too.
    
    For mount with discard, we will issue dicard when we free blocks, so
    leave trimmed flag keep alive to skip useless trim trigger from
    userspace seems reasonable. But for some case like ext4 build on
    dm-thinpool(ext4 blocksize 4K, pool blocksize 128K), discard from ext4
    maybe unaligned for dm thinpool, and thinpool will just finish this
    discard(see process_discard_bio when begein equals to end) without
    actually process discard. For this case, trim from userspace can really
    help us to free some thinpool block.
    
    So convert to clear trimmed flag for all case no matter mounted with
    discard or not.
    
    Fixes: 3d56b8d2c74c ("ext4: Speed up FITRIM by recording flags in ext4_group_info")
    Signed-off-by: yangerkun <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: ext4_search_dir should return a proper error [+ + +]
Author: Thadeu Lima de Souza Cascardo <[email protected]>
Date:   Wed Aug 21 12:23:21 2024 -0300

    ext4: ext4_search_dir should return a proper error
    
    [ Upstream commit cd69f8f9de280e331c9e6ff689ced0a688a9ce8f ]
    
    ext4_search_dir currently returns -1 in case of a failure, while it returns
    0 when the name is not found. In such failure cases, it should return an
    error code instead.
    
    This becomes even more important when ext4_find_inline_entry returns an
    error code as well in the next commit.
    
    -EFSCORRUPTED seems appropriate as such error code as these failures would
    be caused by unexpected record lengths and is in line with other instances
    of ext4_check_dir_entry failures.
    
    In the case of ext4_dx_find_entry, the current use of ERR_BAD_DX_DIR was
    left as is to reduce the risk of regressions.
    
    Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: fix double brelse() the buffer of the extents path [+ + +]
Author: Baokun Li <[email protected]>
Date:   Thu Aug 22 10:35:28 2024 +0800

    ext4: fix double brelse() the buffer of the extents path
    
    commit dcaa6c31134c0f515600111c38ed7750003e1b9c upstream.
    
    In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been
    released, otherwise it may be released twice. An example of what triggers
    this is as follows:
    
      split2    map    split1
    |--------|-------|--------|
    
    ext4_ext_map_blocks
     ext4_ext_handle_unwritten_extents
      ext4_split_convert_extents
       // path->p_depth == 0
       ext4_split_extent
         // 1. do split1
         ext4_split_extent_at
           |ext4_ext_insert_extent
           |  ext4_ext_create_new_leaf
           |    ext4_ext_grow_indepth
           |      le16_add_cpu(&neh->eh_depth, 1)
           |    ext4_find_extent
           |      // return -ENOMEM
           |// get error and try zeroout
           |path = ext4_find_extent
           |  path->p_depth = 1
           |ext4_ext_try_to_merge
           |  ext4_ext_try_to_merge_up
           |    path->p_depth = 0
           |    brelse(path[1].p_bh)  ---> not set to NULL here
           |// zeroout success
         // 2. update path
         ext4_find_extent
         // 3. do split2
         ext4_split_extent_at
           ext4_ext_insert_extent
             ext4_ext_create_new_leaf
               ext4_ext_grow_indepth
                 le16_add_cpu(&neh->eh_depth, 1)
               ext4_find_extent
                 path[0].p_bh = NULL;
                 path->p_depth = 1
                 read_extent_tree_block  ---> return err
                 // path[1].p_bh is still the old value
                 ext4_free_ext_path
                   ext4_ext_drop_refs
                     // path->p_depth == 1
                     brelse(path[1].p_bh)  ---> brelse a buffer twice
    
    Finally got the following WARRNING when removing the buffer from lru:
    
    ============================================
    VFS: brelse: Trying to free free buffer
    WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90
    CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716
    RIP: 0010:__brelse+0x58/0x90
    Call Trace:
     <TASK>
     __find_get_block+0x6e7/0x810
     bdev_getblk+0x2b/0x480
     __ext4_get_inode_loc+0x48a/0x1240
     ext4_get_inode_loc+0xb2/0x150
     ext4_reserve_inode_write+0xb7/0x230
     __ext4_mark_inode_dirty+0x144/0x6a0
     ext4_ext_insert_extent+0x9c8/0x3230
     ext4_ext_map_blocks+0xf45/0x2dc0
     ext4_map_blocks+0x724/0x1700
     ext4_do_writepages+0x12d6/0x2a70
    [...]
    ============================================
    
    Fixes: ecb94f5fdf4b ("ext4: collapse a single extent tree block into the inode if possible")
    Cc: [email protected]
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Tested-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix i_data_sem unlock order in ext4_ind_migrate() [+ + +]
Author: Artem Sadovnikov <[email protected]>
Date:   Thu Aug 29 15:22:09 2024 +0000

    ext4: fix i_data_sem unlock order in ext4_ind_migrate()
    
    [ Upstream commit cc749e61c011c255d81b192a822db650c68b313f ]
    
    Fuzzing reports a possible deadlock in jbd2_log_wait_commit.
    
    This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require
    synchronous updates because the file descriptor is opened with O_SYNC.
    This can lead to the jbd2_journal_stop() function calling
    jbd2_might_wait_for_commit(), potentially causing a deadlock if the
    EXT4_IOC_MIGRATE call races with a write(2) system call.
    
    This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this
    case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the
    jbd2_journal_stop function while i_data_sem is locked. This triggers
    lockdep because the jbd2_journal_start function might also lock the same
    jbd2_handle simultaneously.
    
    Found by Linux Verification Center (linuxtesting.org) with syzkaller.
    
    Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
    Co-developed-by: Mikhail Ukhin <[email protected]>
    Signed-off-by: Mikhail Ukhin <[email protected]>
    Signed-off-by: Artem Sadovnikov <[email protected]>
    Rule: add
    Link: https://lore.kernel.org/stable/20240404095000.5872-1-mish.uxin2012%40yandex.ru
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space() [+ + +]
Author: Luis Henriques (SUSE) <[email protected]>
Date:   Wed Jul 24 17:11:16 2024 +0100

    ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space()
    
    commit 972090651ee15e51abfb2160e986fa050cfc7a40 upstream.
    
    Function __jbd2_log_wait_for_space() assumes that '0' is not a valid value
    for transaction IDs, which is incorrect.  Don't assume that and invoke
    jbd2_log_wait_commit() if the journal had a committing transaction instead.
    
    Signed-off-by: Luis Henriques (SUSE) <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit() [+ + +]
Author: Luis Henriques (SUSE) <[email protected]>
Date:   Wed Jul 24 17:11:15 2024 +0100

    ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit()
    
    commit dd589b0f1445e1ea1085b98edca6e4d5dedb98d0 upstream.
    
    Function ext4_wait_for_tail_page_commit() assumes that '0' is not a valid
    value for transaction IDs, which is incorrect.  Don't assume that and invoke
    jbd2_log_wait_commit() if the journal had a committing transaction instead.
    
    Signed-off-by: Luis Henriques (SUSE) <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix inode tree inconsistency caused by ENOMEM [+ + +]
Author: zhanchengbin <[email protected]>
Date:   Tue Jan 3 10:28:12 2023 +0800

    ext4: fix inode tree inconsistency caused by ENOMEM
    
    commit 3f5424790d4377839093b68c12b130077a4e4510 upstream.
    
    If ENOMEM fails when the extent is splitting, we need to restore the length
    of the split extent.
    In the ext4_split_extent_at function, only in ext4_ext_create_new_leaf will
    it alloc memory and change the shape of the extent tree,even if an ENOMEM
    is returned at this time, the extent tree is still self-consistent, Just
    restore the split extent lens in the function ext4_split_extent_at.
    
    ext4_split_extent_at
     ext4_ext_insert_extent
      ext4_ext_create_new_leaf
       1)ext4_ext_split
         ext4_find_extent
       2)ext4_ext_grow_indepth
         ext4_find_extent
    
    Signed-off-by: zhanchengbin <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Cc: Baokun Li <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: nested locking for xattr inode [+ + +]
Author: Wojciech Gładysz <[email protected]>
Date:   Thu Aug 1 16:38:27 2024 +0200

    ext4: nested locking for xattr inode
    
    [ Upstream commit d1bc560e9a9c78d0b2314692847fc8661e0aeb99 ]
    
    Add nested locking with I_MUTEX_XATTR subclass to avoid lockdep warning
    while handling xattr inode on file open syscall at ext4_xattr_inode_iget.
    
    Backtrace
    EXT4-fs (loop0): Ignoring removed oldalloc option
    ======================================================
    WARNING: possible circular locking dependency detected
    5.10.0-syzkaller #0 Not tainted
    ------------------------------------------------------
    syz-executor543/2794 is trying to acquire lock:
    ffff8880215e1a48 (&ea_inode->i_rwsem#7/1){+.+.}-{3:3}, at: inode_lock include/linux/fs.h:782 [inline]
    ffff8880215e1a48 (&ea_inode->i_rwsem#7/1){+.+.}-{3:3}, at: ext4_xattr_inode_iget+0x42a/0x5c0 fs/ext4/xattr.c:425
    
    but task is already holding lock:
    ffff8880215e3278 (&ei->i_data_sem/3){++++}-{3:3}, at: ext4_setattr+0x136d/0x19c0 fs/ext4/inode.c:5559
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (&ei->i_data_sem/3){++++}-{3:3}:
           lock_acquire+0x197/0x480 kernel/locking/lockdep.c:5566
           down_write+0x93/0x180 kernel/locking/rwsem.c:1564
           ext4_update_i_disksize fs/ext4/ext4.h:3267 [inline]
           ext4_xattr_inode_write fs/ext4/xattr.c:1390 [inline]
           ext4_xattr_inode_lookup_create fs/ext4/xattr.c:1538 [inline]
           ext4_xattr_set_entry+0x331a/0x3d80 fs/ext4/xattr.c:1662
           ext4_xattr_ibody_set+0x124/0x390 fs/ext4/xattr.c:2228
           ext4_xattr_set_handle+0xc27/0x14e0 fs/ext4/xattr.c:2385
           ext4_xattr_set+0x219/0x390 fs/ext4/xattr.c:2498
           ext4_xattr_user_set+0xc9/0xf0 fs/ext4/xattr_user.c:40
           __vfs_setxattr+0x404/0x450 fs/xattr.c:177
           __vfs_setxattr_noperm+0x11d/0x4f0 fs/xattr.c:208
           __vfs_setxattr_locked+0x1f9/0x210 fs/xattr.c:266
           vfs_setxattr+0x112/0x2c0 fs/xattr.c:283
           setxattr+0x1db/0x3e0 fs/xattr.c:548
           path_setxattr+0x15a/0x240 fs/xattr.c:567
           __do_sys_setxattr fs/xattr.c:582 [inline]
           __se_sys_setxattr fs/xattr.c:578 [inline]
           __x64_sys_setxattr+0xc5/0xe0 fs/xattr.c:578
           do_syscall_64+0x6d/0xa0 arch/x86/entry/common.c:62
           entry_SYSCALL_64_after_hwframe+0x61/0xcb
    
    -> #0 (&ea_inode->i_rwsem#7/1){+.+.}-{3:3}:
           check_prev_add kernel/locking/lockdep.c:2988 [inline]
           check_prevs_add kernel/locking/lockdep.c:3113 [inline]
           validate_chain+0x1695/0x58f0 kernel/locking/lockdep.c:3729
           __lock_acquire+0x12fd/0x20d0 kernel/locking/lockdep.c:4955
           lock_acquire+0x197/0x480 kernel/locking/lockdep.c:5566
           down_write+0x93/0x180 kernel/locking/rwsem.c:1564
           inode_lock include/linux/fs.h:782 [inline]
           ext4_xattr_inode_iget+0x42a/0x5c0 fs/ext4/xattr.c:425
           ext4_xattr_inode_get+0x138/0x410 fs/ext4/xattr.c:485
           ext4_xattr_move_to_block fs/ext4/xattr.c:2580 [inline]
           ext4_xattr_make_inode_space fs/ext4/xattr.c:2682 [inline]
           ext4_expand_extra_isize_ea+0xe70/0x1bb0 fs/ext4/xattr.c:2774
           __ext4_expand_extra_isize+0x304/0x3f0 fs/ext4/inode.c:5898
           ext4_try_to_expand_extra_isize fs/ext4/inode.c:5941 [inline]
           __ext4_mark_inode_dirty+0x591/0x810 fs/ext4/inode.c:6018
           ext4_setattr+0x1400/0x19c0 fs/ext4/inode.c:5562
           notify_change+0xbb6/0xe60 fs/attr.c:435
           do_truncate+0x1de/0x2c0 fs/open.c:64
           handle_truncate fs/namei.c:2970 [inline]
           do_open fs/namei.c:3311 [inline]
           path_openat+0x29f3/0x3290 fs/namei.c:3425
           do_filp_open+0x20b/0x450 fs/namei.c:3452
           do_sys_openat2+0x124/0x460 fs/open.c:1207
           do_sys_open fs/open.c:1223 [inline]
           __do_sys_open fs/open.c:1231 [inline]
           __se_sys_open fs/open.c:1227 [inline]
           __x64_sys_open+0x221/0x270 fs/open.c:1227
           do_syscall_64+0x6d/0xa0 arch/x86/entry/common.c:62
           entry_SYSCALL_64_after_hwframe+0x61/0xcb
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&ei->i_data_sem/3);
                                   lock(&ea_inode->i_rwsem#7/1);
                                   lock(&ei->i_data_sem/3);
      lock(&ea_inode->i_rwsem#7/1);
    
     *** DEADLOCK ***
    
    5 locks held by syz-executor543/2794:
     #0: ffff888026fbc448 (sb_writers#4){.+.+}-{0:0}, at: mnt_want_write+0x4a/0x2a0 fs/namespace.c:365
     #1: ffff8880215e3488 (&sb->s_type->i_mutex_key#7){++++}-{3:3}, at: inode_lock include/linux/fs.h:782 [inline]
     #1: ffff8880215e3488 (&sb->s_type->i_mutex_key#7){++++}-{3:3}, at: do_truncate+0x1cf/0x2c0 fs/open.c:62
     #2: ffff8880215e3310 (&ei->i_mmap_sem){++++}-{3:3}, at: ext4_setattr+0xec4/0x19c0 fs/ext4/inode.c:5519
     #3: ffff8880215e3278 (&ei->i_data_sem/3){++++}-{3:3}, at: ext4_setattr+0x136d/0x19c0 fs/ext4/inode.c:5559
     #4: ffff8880215e30c8 (&ei->xattr_sem){++++}-{3:3}, at: ext4_write_trylock_xattr fs/ext4/xattr.h:162 [inline]
     #4: ffff8880215e30c8 (&ei->xattr_sem){++++}-{3:3}, at: ext4_try_to_expand_extra_isize fs/ext4/inode.c:5938 [inline]
     #4: ffff8880215e30c8 (&ei->xattr_sem){++++}-{3:3}, at: __ext4_mark_inode_dirty+0x4fb/0x810 fs/ext4/inode.c:6018
    
    stack backtrace:
    CPU: 1 PID: 2794 Comm: syz-executor543 Not tainted 5.10.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x177/0x211 lib/dump_stack.c:118
     print_circular_bug+0x146/0x1b0 kernel/locking/lockdep.c:2002
     check_noncircular+0x2cc/0x390 kernel/locking/lockdep.c:2123
     check_prev_add kernel/locking/lockdep.c:2988 [inline]
     check_prevs_add kernel/locking/lockdep.c:3113 [inline]
     validate_chain+0x1695/0x58f0 kernel/locking/lockdep.c:3729
     __lock_acquire+0x12fd/0x20d0 kernel/locking/lockdep.c:4955
     lock_acquire+0x197/0x480 kernel/locking/lockdep.c:5566
     down_write+0x93/0x180 kernel/locking/rwsem.c:1564
     inode_lock include/linux/fs.h:782 [inline]
     ext4_xattr_inode_iget+0x42a/0x5c0 fs/ext4/xattr.c:425
     ext4_xattr_inode_get+0x138/0x410 fs/ext4/xattr.c:485
     ext4_xattr_move_to_block fs/ext4/xattr.c:2580 [inline]
     ext4_xattr_make_inode_space fs/ext4/xattr.c:2682 [inline]
     ext4_expand_extra_isize_ea+0xe70/0x1bb0 fs/ext4/xattr.c:2774
     __ext4_expand_extra_isize+0x304/0x3f0 fs/ext4/inode.c:5898
     ext4_try_to_expand_extra_isize fs/ext4/inode.c:5941 [inline]
     __ext4_mark_inode_dirty+0x591/0x810 fs/ext4/inode.c:6018
     ext4_setattr+0x1400/0x19c0 fs/ext4/inode.c:5562
     notify_change+0xbb6/0xe60 fs/attr.c:435
     do_truncate+0x1de/0x2c0 fs/open.c:64
     handle_truncate fs/namei.c:2970 [inline]
     do_open fs/namei.c:3311 [inline]
     path_openat+0x29f3/0x3290 fs/namei.c:3425
     do_filp_open+0x20b/0x450 fs/namei.c:3452
     do_sys_openat2+0x124/0x460 fs/open.c:1207
     do_sys_open fs/open.c:1223 [inline]
     __do_sys_open fs/open.c:1231 [inline]
     __se_sys_open fs/open.c:1227 [inline]
     __x64_sys_open+0x221/0x270 fs/open.c:1227
     do_syscall_64+0x6d/0xa0 arch/x86/entry/common.c:62
     entry_SYSCALL_64_after_hwframe+0x61/0xcb
    RIP: 0033:0x7f0cde4ea229
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffd81d1c978 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
    RAX: ffffffffffffffda RBX: 0030656c69662f30 RCX: 00007f0cde4ea229
    RDX: 0000000000000089 RSI: 00000000000a0a00 RDI: 00000000200001c0
    RBP: 2f30656c69662f2e R08: 0000000000208000 R09: 0000000000208000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd81d1c9c0
    R13: 00007ffd81d1ca00 R14: 0000000000080000 R15: 0000000000000003
    EXT4-fs error (device loop0): ext4_expand_extra_isize_ea:2730: inode #13: comm syz-executor543: corrupted in-inode xattr
    
    Signed-off-by: Wojciech Gładysz <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: no need to continue when the number of entries is 1 [+ + +]
Author: Edward Adam Davis <[email protected]>
Date:   Mon Jul 1 22:25:03 2024 +0800

    ext4: no need to continue when the number of entries is 1
    
    commit 1a00a393d6a7fb1e745a41edd09019bd6a0ad64c upstream.
    
    Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=ae688d469e36fb5138d0
    Signed-off-by: Edward Adam Davis <[email protected]>
    Reported-and-tested-by: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: propagate errors from ext4_find_extent() in ext4_insert_range() [+ + +]
Author: Baokun Li <[email protected]>
Date:   Thu Aug 22 10:35:30 2024 +0800

    ext4: propagate errors from ext4_find_extent() in ext4_insert_range()
    
    commit 369c944ed1d7c3fb7b35f24e4735761153afe7b3 upstream.
    
    Even though ext4_find_extent() returns an error, ext4_insert_range() still
    returns 0. This may confuse the user as to why fallocate returns success,
    but the contents of the file are not as expected. So propagate the error
    returned by ext4_find_extent() to avoid inconsistencies.
    
    Fixes: 331573febb6a ("ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate")
    Cc: [email protected]
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Tested-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: return error on ext4_find_inline_entry [+ + +]
Author: Thadeu Lima de Souza Cascardo <[email protected]>
Date:   Wed Aug 21 12:23:22 2024 -0300

    ext4: return error on ext4_find_inline_entry
    
    [ Upstream commit 4d231b91a944f3cab355fce65af5871fb5d7735b ]
    
    In case of errors when reading an inode from disk or traversing inline
    directory entries, return an error-encoded ERR_PTR instead of returning
    NULL. ext4_find_inline_entry only caller, __ext4_find_entry already returns
    such encoded errors.
    
    Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: c6b72f5d82b1 ("ext4: avoid OOB when system.data xattr changes underneath the filesystem")
    Signed-off-by: Sasha Levin <[email protected]>

 
f2fs: avoid potential int overflow in sanity_check_area_boundary() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Wed Jul 24 10:51:58 2024 -0700

    f2fs: avoid potential int overflow in sanity_check_area_boundary()
    
    commit 50438dbc483ca6a133d2bce9d5d6747bcee38371 upstream.
    
    While calculating the end addresses of main area and segment 0, u32
    may be not enough to hold the result without the danger of int
    overflow.
    
    Just in case, play it safe and cast one of the operands to a
    wider type (u64).
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: fd694733d523 ("f2fs: cover large section in sanity check of super")
    Cc: [email protected]
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

f2fs: enhance to update i_mode and acl atomically in f2fs_setattr() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Fri Dec 25 16:52:27 2020 +0800

    f2fs: enhance to update i_mode and acl atomically in f2fs_setattr()
    
    [ Upstream commit 17232e830afb800acdcc22ae8980bf9d330393ef ]
    
    Previously, in f2fs_setattr(), we don't update S_ISUID|S_ISGID|S_ISVTX
    bits with S_IRWXUGO bits and acl entries atomically, so in error path,
    chmod() may partially success, this patch enhances to make chmod() flow
    being atomical.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: aaf8c0b9ae04 ("f2fs: reduce expensive checkpoint trigger frequency")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to update i_ctime in __f2fs_setxattr() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Jul 19 21:50:45 2023 +0800

    f2fs: fix to update i_ctime in __f2fs_setxattr()
    
    [ Upstream commit 8874ad7dae8d91d24cc87c545c0073b3b2da5688 ]
    
    generic/728       - output mismatch (see /media/fstests/results//generic/728.out.bad)
        --- tests/generic/728.out   2023-07-19 07:10:48.362711407 +0000
        +++ /media/fstests/results//generic/728.out.bad     2023-07-19 08:39:57.000000000 +0000
         QA output created by 728
        +Expected ctime to change after setxattr.
        +Expected ctime to change after removexattr.
         Silence is golden
        ...
        (Run 'diff -u /media/fstests/tests/generic/728.out /media/fstests/results//generic/728.out.bad'  to see the entire diff)
    generic/729        1s
    
    It needs to update i_ctime after {set,remove}xattr, fix it.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: aaf8c0b9ae04 ("f2fs: reduce expensive checkpoint trigger frequency")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix typo [+ + +]
Author: Yonggil Song <[email protected]>
Date:   Fri Sep 2 11:07:49 2022 +0900

    f2fs: fix typo
    
    [ Upstream commit d382e36970ecf8242921400db2afde15fb6ed49e ]
    
    Fix typo in f2fs.h
    Detected by Jaeyoon Choi
    
    Signed-off-by: Yonggil Song <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: aaf8c0b9ae04 ("f2fs: reduce expensive checkpoint trigger frequency")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: prevent possible int overflow in dir_block_index() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Wed Jul 24 10:05:44 2024 -0700

    f2fs: prevent possible int overflow in dir_block_index()
    
    commit 47f268f33dff4a5e31541a990dc09f116f80e61c upstream.
    
    The result of multiplication between values derived from functions
    dir_buckets() and bucket_blocks() *could* technically reach
    2^30 * 2^2 = 2^32.
    
    While unlikely to happen, it is prudent to ensure that it will not
    lead to integer overflow. Thus, use mul_u32_u32() as it's more
    appropriate to mitigate the issue.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 3843154598a0 ("f2fs: introduce large directory support")
    Cc: [email protected]
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

f2fs: reduce expensive checkpoint trigger frequency [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Jun 26 09:47:27 2024 +0800

    f2fs: reduce expensive checkpoint trigger frequency
    
    [ Upstream commit aaf8c0b9ae042494cb4585883b15c1332de77840 ]
    
    We may trigger high frequent checkpoint for below case:
    1. mkdir /mnt/dir1; set dir1 encrypted
    2. touch /mnt/file1; fsync /mnt/file1
    3. mkdir /mnt/dir2; set dir2 encrypted
    4. touch /mnt/file2; fsync /mnt/file2
    ...
    
    Although, newly created dir and file are not related, due to
    commit bbf156f7afa7 ("f2fs: fix lost xattrs of directories"), we will
    trigger checkpoint whenever fsync() comes after a new encrypted dir
    created.
    
    In order to avoid such performance regression issue, let's record an
    entry including directory's ino in global cache whenever we update
    directory's xattr data, and then triggerring checkpoint() only if
    xattr metadata of target file's parent was updated.
    
    This patch updates to cover below no encryption case as well:
    1) parent is checkpointed
    2) set_xattr(dir) w/ new xnid
    3) create(file)
    4) fsync(file)
    
    Fixes: bbf156f7afa7 ("f2fs: fix lost xattrs of directories")
    Reported-by: wangzijie <[email protected]>
    Reported-by: Zhiguo Niu <[email protected]>
    Tested-by: Zhiguo Niu <[email protected]>
    Reported-by: Yunlei He <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: remove unneeded check condition in __f2fs_setxattr() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Jul 19 21:50:46 2023 +0800

    f2fs: remove unneeded check condition in __f2fs_setxattr()
    
    [ Upstream commit bc3994ffa4cf23f55171943c713366132c3ff45d ]
    
    It has checked return value of write_all_xattrs(), remove unneeded
    following check condition.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: aaf8c0b9ae04 ("f2fs: reduce expensive checkpoint trigger frequency")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: Require FMODE_WRITE for atomic write ioctls [+ + +]
Author: Jann Horn <[email protected]>
Date:   Fri Oct 4 19:37:10 2024 +0000

    f2fs: Require FMODE_WRITE for atomic write ioctls
    
    commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream.
    
    The F2FS ioctls for starting and committing atomic writes check for
    inode_owner_or_capable(), but this does not give LSMs like SELinux or
    Landlock an opportunity to deny the write access - if the caller's FSUID
    matches the inode's UID, inode_owner_or_capable() immediately returns true.
    
    There are scenarios where LSMs want to deny a process the ability to write
    particular files, even files that the FSUID of the process owns; but this
    can currently partially be bypassed using atomic write ioctls in two ways:
    
     - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can
       truncate an inode to size 0
     - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert
       changes another process concurrently made to a file
    
    Fix it by requiring FMODE_WRITE for these operations, just like for
    F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these
    ioctls when intending to write into the file, that seems unlikely to break
    anything.
    
    Fixes: 88b88a667971 ("f2fs: support atomic writes")
    Cc: [email protected]
    Signed-off-by: Jann Horn <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Reviewed-by: Eric Biggers <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fat: fix uninitialized variable [+ + +]
Author: OGAWA Hirofumi <[email protected]>
Date:   Fri Oct 4 15:03:49 2024 +0900

    fat: fix uninitialized variable
    
    commit 963a7f4d3b90ee195b895ca06b95757fcba02d1a upstream.
    
    syszbot produced this with a corrupted fs image.  In theory, however an IO
    error would trigger this also.
    
    This affects just an error report, so should not be a serious error.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: OGAWA Hirofumi <[email protected]>
    Reported-by: [email protected]
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fbdev: hpfb: Fix an error handling path in hpfb_dio_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Thu Aug 1 22:34:39 2024 +0200

    fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()
    
    [ Upstream commit aa578e897520f32ae12bec487f2474357d01ca9c ]
    
    If an error occurs after request_mem_region(), a corresponding
    release_mem_region() should be called, as already done in the remove
    function.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fbdev: pxafb: Fix possible use after free in pxafb_task() [+ + +]
Author: Kaixin Wang <[email protected]>
Date:   Wed Sep 11 22:29:52 2024 +0800

    fbdev: pxafb: Fix possible use after free in pxafb_task()
    
    [ Upstream commit 4a6921095eb04a900e0000da83d9475eb958e61e ]
    
    In the pxafb_probe function, it calls the pxafb_init_fbinfo function,
    after which &fbi->task is associated with pxafb_task. Moreover,
    within this pxafb_init_fbinfo function, the pxafb_blank function
    within the &pxafb_ops struct is capable of scheduling work.
    
    If we remove the module which will call pxafb_remove to make cleanup,
    it will call unregister_framebuffer function which can call
    do_unregister_framebuffer to free fbi->fb through
    put_fb_info(fb_info), while the work mentioned above will be used.
    The sequence of operations that may lead to a UAF bug is as follows:
    
    CPU0                                                CPU1
    
                                       | pxafb_task
    pxafb_remove                       |
    unregister_framebuffer(info)       |
    do_unregister_framebuffer(fb_info) |
    put_fb_info(fb_info)               |
    // free fbi->fb                    | set_ctrlr_state(fbi, state)
                                       | __pxafb_lcd_power(fbi, 0)
                                       | fbi->lcd_power(on, &fbi->fb.var)
                                       | //use fbi->fb
    
    Fix it by ensuring that the work is canceled before proceeding
    with the cleanup in pxafb_remove.
    
    Note that only root user can remove the driver at runtime.
    
    Signed-off-by: Kaixin Wang <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fbdev: sisfb: Fix strbuf array overflow [+ + +]
Author: Andrey Shumilin <[email protected]>
Date:   Fri Sep 27 22:34:24 2024 +0300

    fbdev: sisfb: Fix strbuf array overflow
    
    [ Upstream commit 9cf14f5a2746c19455ce9cb44341b5527b5e19c3 ]
    
    The values of the variables xres and yres are placed in strbuf.
    These variables are obtained from strbuf1.
    The strbuf1 array contains digit characters
    and a space if the array contains non-digit characters.
    Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres);
    more than 16 bytes will be written to strbuf.
    It is suggested to increase the size of the strbuf array to 24.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Andrey Shumilin <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state() [+ + +]
Author: Xiongfeng Wang <[email protected]>
Date:   Wed Oct 16 16:47:40 2024 +0800

    firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()
    
    [ Upstream commit c83212d79be2c9886d3e6039759ecd388fd5fed1 ]
    
    In sdei_device_freeze(), the input parameter of cpuhp_remove_state() is
    passed as 'sdei_entry_point' by mistake. Change it to 'sdei_hp_state'.
    
    Fixes: d2c48b2387eb ("firmware: arm_sdei: Fix sleep from invalid context BUG")
    Signed-off-by: Xiongfeng Wang <[email protected]>
    Reviewed-by: James Morse <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp() [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Fri Aug 16 15:57:21 2024 +0200

    firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()
    
    commit 9c3a62c20f7fb00294a4237e287254456ba8a48b upstream.
    
    mbox_client_to_bpmp() is not used, W=1 builds:
    
      drivers/firmware/tegra/bpmp.c:28:1: error: unused function 'mbox_client_to_bpmp' [-Werror,-Wunused-function]
    
    Fixes: cdfa358b248e ("firmware: tegra: Refactor BPMP driver")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
firmware_loader: Block path traversal [+ + +]
Author: Jann Horn <[email protected]>
Date:   Wed Aug 28 01:45:48 2024 +0200

    firmware_loader: Block path traversal
    
    commit f0e5311aa8022107d63c54e2f03684ec097d1394 upstream.
    
    Most firmware names are hardcoded strings, or are constructed from fairly
    constrained format strings where the dynamic parts are just some hex
    numbers or such.
    
    However, there are a couple codepaths in the kernel where firmware file
    names contain string components that are passed through from a device or
    semi-privileged userspace; the ones I could find (not counting interfaces
    that require root privileges) are:
    
     - lpfc_sli4_request_firmware_update() seems to construct the firmware
       filename from "ModelName", a string that was previously parsed out of
       some descriptor ("Vital Product Data") in lpfc_fill_vpd()
     - nfp_net_fw_find() seems to construct a firmware filename from a model
       name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I
       think parses some descriptor that was read from the device.
       (But this case likely isn't exploitable because the format string looks
       like "netronome/nic_%s", and there shouldn't be any *folders* starting
       with "netronome/nic_". The previous case was different because there,
       the "%s" is *at the start* of the format string.)
     - module_flash_fw_schedule() is reachable from the
       ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
       GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
       enough to pass the privilege check), and takes a userspace-provided
       firmware name.
       (But I think to reach this case, you need to have CAP_NET_ADMIN over a
       network namespace that a special kind of ethernet device is mapped into,
       so I think this is not a viable attack path in practice.)
    
    Fix it by rejecting any firmware names containing ".." path components.
    
    For what it's worth, I went looking and haven't found any USB device
    drivers that use the firmware loader dangerously.
    
    Cc: [email protected]
    Reviewed-by: Danilo Krummrich <[email protected]>
    Fixes: abb139e75c2c ("firmware: teach the kernel to load firmware files directly from the filesystem")
    Signed-off-by: Jann Horn <[email protected]>
    Acked-by: Luis Chamberlain <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fs/namespace: fnic: Switch to use %ptTd [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Tue Mar 14 17:09:06 2023 +0200

    fs/namespace: fnic: Switch to use %ptTd
    
    [ Upstream commit 74e60b8b2f0fe3702710e648a31725ee8224dbdf ]
    
    Use %ptTd instead of open-coded variant to print contents
    of time64_t type in human readable form.
    
    Signed-off-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Christian Brauner (Microsoft) <[email protected]>
    Stable-dep-of: 4bcda1eaf184 ("mount: handle OOM on mnt_warn_timestamp_expiry")
    Signed-off-by: Sasha Levin <[email protected]>

 
fs: explicitly unregister per-superblock BDIs [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Fri Nov 5 13:36:58 2021 -0700

    fs: explicitly unregister per-superblock BDIs
    
    [ Upstream commit 0b3ea0926afb8dde70cfab00316ae0a70b93a7cc ]
    
    Add a new SB_I_ flag to mark superblocks that have an ephemeral bdi
    associated with them, and unregister it when the superblock is shut
    down.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Cc: Miquel Raynal <[email protected]>
    Cc: Richard Weinberger <[email protected]>
    Cc: Vignesh Raghavendra <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Stable-dep-of: 4bcda1eaf184 ("mount: handle OOM on mnt_warn_timestamp_expiry")
    Signed-off-by: Sasha Levin <[email protected]>

fs: Fix file_set_fowner LSM hook inconsistencies [+ + +]
Author: Mickaël Salaün <[email protected]>
Date:   Wed Aug 21 11:56:05 2024 +0200

    fs: Fix file_set_fowner LSM hook inconsistencies
    
    commit 26f204380a3c182e5adf1a798db0724d6111b597 upstream.
    
    The fcntl's F_SETOWN command sets the process that handle SIGIO/SIGURG
    for the related file descriptor.  Before this change, the
    file_set_fowner LSM hook was always called, ignoring the VFS logic which
    may not actually change the process that handles SIGIO (e.g. TUN, TTY,
    dnotify), nor update the related UID/EUID.
    
    Moreover, because security_file_set_fowner() was called without lock
    (e.g. f_owner.lock), concurrent F_SETOWN commands could result to a race
    condition and inconsistent LSM states (e.g. SELinux's fown_sid) compared
    to struct fown_struct's UID/EUID.
    
    This change makes sure the LSM states are always in sync with the VFS
    state by moving the security_file_set_fowner() call close to the
    UID/EUID updates and using the same f_owner.lock .
    
    Rename f_modown() to __f_setown() to simplify code.
    
    Cc: [email protected]
    Cc: Al Viro <[email protected]>
    Cc: Casey Schaufler <[email protected]>
    Cc: Christian Brauner <[email protected]>
    Cc: James Morris <[email protected]>
    Cc: Jann Horn <[email protected]>
    Cc: Ondrej Mosnacek <[email protected]>
    Cc: Paul Moore <[email protected]>
    Cc: Serge E. Hallyn <[email protected]>
    Cc: Stephen Smalley <[email protected]>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Mickaël Salaün <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
genetlink: hold RCU in genlmsg_mcast() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Oct 11 17:12:17 2024 +0000

    genetlink: hold RCU in genlmsg_mcast()
    
    [ Upstream commit 56440d7ec28d60f8da3bfa09062b3368ff9b16db ]
    
    While running net selftests with CONFIG_PROVE_RCU_LIST=y I saw
    one lockdep splat [1].
    
    genlmsg_mcast() uses for_each_net_rcu(), and must therefore hold RCU.
    
    Instead of letting all callers guard genlmsg_multicast_allns()
    with a rcu_read_lock()/rcu_read_unlock() pair, do it in genlmsg_mcast().
    
    This also means the @flags parameter is useless, we need to always use
    GFP_ATOMIC.
    
    [1]
    [10882.424136] =============================
    [10882.424166] WARNING: suspicious RCU usage
    [10882.424309] 6.12.0-rc2-virtme #1156 Not tainted
    [10882.424400] -----------------------------
    [10882.424423] net/netlink/genetlink.c:1940 RCU-list traversed in non-reader section!!
    [10882.424469]
    other info that might help us debug this:
    
    [10882.424500]
    rcu_scheduler_active = 2, debug_locks = 1
    [10882.424744] 2 locks held by ip/15677:
    [10882.424791] #0: ffffffffb6b491b0 (cb_lock){++++}-{3:3}, at: genl_rcv (net/netlink/genetlink.c:1219)
    [10882.426334] #1: ffffffffb6b49248 (genl_mutex){+.+.}-{3:3}, at: genl_rcv_msg (net/netlink/genetlink.c:61 net/netlink/genetlink.c:57 net/netlink/genetlink.c:1209)
    [10882.426465]
    stack backtrace:
    [10882.426805] CPU: 14 UID: 0 PID: 15677 Comm: ip Not tainted 6.12.0-rc2-virtme #1156
    [10882.426919] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    [10882.427046] Call Trace:
    [10882.427131]  <TASK>
    [10882.427244] dump_stack_lvl (lib/dump_stack.c:123)
    [10882.427335] lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)
    [10882.427387] genlmsg_multicast_allns (net/netlink/genetlink.c:1940 (discriminator 7) net/netlink/genetlink.c:1977 (discriminator 7))
    [10882.427436] l2tp_tunnel_notify.constprop.0 (net/l2tp/l2tp_netlink.c:119) l2tp_netlink
    [10882.427683] l2tp_nl_cmd_tunnel_create (net/l2tp/l2tp_netlink.c:253) l2tp_netlink
    [10882.427748] genl_family_rcv_msg_doit (net/netlink/genetlink.c:1115)
    [10882.427834] genl_rcv_msg (net/netlink/genetlink.c:1195 net/netlink/genetlink.c:1210)
    [10882.427877] ? __pfx_l2tp_nl_cmd_tunnel_create (net/l2tp/l2tp_netlink.c:186) l2tp_netlink
    [10882.427927] ? __pfx_genl_rcv_msg (net/netlink/genetlink.c:1201)
    [10882.427959] netlink_rcv_skb (net/netlink/af_netlink.c:2551)
    [10882.428069] genl_rcv (net/netlink/genetlink.c:1220)
    [10882.428095] netlink_unicast (net/netlink/af_netlink.c:1332 net/netlink/af_netlink.c:1357)
    [10882.428140] netlink_sendmsg (net/netlink/af_netlink.c:1901)
    [10882.428210] ____sys_sendmsg (net/socket.c:729 (discriminator 1) net/socket.c:744 (discriminator 1) net/socket.c:2607 (discriminator 1))
    
    Fixes: 33f72e6f0c67 ("l2tp : multicast notification to the registered listeners")
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: James Chapman <[email protected]>
    Cc: Tom Parkin <[email protected]>
    Cc: Johannes Berg <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
gpio: aspeed: Add the flush write to ensure the write complete. [+ + +]
Author: Billy Tsai <[email protected]>
Date:   Tue Oct 8 16:14:44 2024 +0800

    gpio: aspeed: Add the flush write to ensure the write complete.
    
    [ Upstream commit 1bb5a99e1f3fd27accb804aa0443a789161f843c ]
    
    Performing a dummy read ensures that the register write operation is fully
    completed, mitigating any potential bus delays that could otherwise impact
    the frequency of bitbang usage. E.g., if the JTAG application uses GPIO to
    control the JTAG pins (TCK, TMS, TDI, TDO, and TRST), and the application
    sets the TCK clock to 1 MHz, the GPIO's high/low transitions will rely on
    a delay function to ensure the clock frequency does not exceed 1 MHz.
    However, this can lead to rapid toggling of the GPIO because the write
    operation is POSTed and does not wait for a bus acknowledgment.
    
    Fixes: 361b79119a4b ("gpio: Add Aspeed driver")
    Reviewed-by: Andrew Jeffery <[email protected]>
    Signed-off-by: Billy Tsai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gpio: aspeed: Use devm_clk api to manage clock source [+ + +]
Author: Billy Tsai <[email protected]>
Date:   Tue Oct 8 16:14:45 2024 +0800

    gpio: aspeed: Use devm_clk api to manage clock source
    
    [ Upstream commit a6191a3d18119184237f4ee600039081ad992320 ]
    
    Replace of_clk_get with devm_clk_get_enabled to manage the clock source.
    
    Fixes: 5ae4cb94b313 ("gpio: aspeed: Add debounce support")
    Reviewed-by: Andrew Jeffery <[email protected]>
    Signed-off-by: Billy Tsai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gpio: davinci: fix lazy disable [+ + +]
Author: Emanuele Ghidoli <[email protected]>
Date:   Wed Aug 28 15:32:07 2024 +0200

    gpio: davinci: fix lazy disable
    
    commit 3360d41f4ac490282fddc3ccc0b58679aa5c065d upstream.
    
    On a few platforms such as TI's AM69 device, disable_irq() fails to keep
    track of the interrupts that happen between disable_irq() and
    enable_irq() and those interrupts are missed. Use the ->irq_unmask() and
    ->irq_mask() methods instead of ->irq_enable() and ->irq_disable() to
    correctly keep track of edges when disable_irq is called.
    
    This solves the issue of disable_irq() not working as expected on such
    platforms.
    
    Fixes: 23265442b02b ("ARM: davinci: irq_data conversion.")
    Signed-off-by: Emanuele Ghidoli <[email protected]>
    Signed-off-by: Parth Pancholi <[email protected]>
    Acked-by: Keerthy <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

gpio: prevent potential speculation leaks in gpio_device_get_desc() [+ + +]
Author: Hagar Hemdan <[email protected]>
Date:   Thu May 23 08:53:32 2024 +0000

    gpio: prevent potential speculation leaks in gpio_device_get_desc()
    
    commit d795848ecce24a75dfd46481aee066ae6fe39775 upstream.
    
    Userspace may trigger a speculative read of an address outside the gpio
    descriptor array.
    Users can do that by calling gpio_ioctl() with an offset out of range.
    Offset is copied from user and then used as an array index to get
    the gpio descriptor without sanitization in gpio_device_get_desc().
    
    This change ensures that the offset is sanitized by using
    array_index_nospec() to mitigate any possibility of speculative
    information leaks.
    
    This bug was discovered and resolved using Coverity Static Analysis
    Security Testing (SAST) by Synopsys, Inc.
    
    Signed-off-by: Hagar Hemdan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Hugo SIMELIERE <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
gtp: allow -1 to be specified as file description from userspace [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Oct 22 16:48:25 2024 +0200

    gtp: allow -1 to be specified as file description from userspace
    
    [ Upstream commit 7515e37bce5c428a56a9b04ea7e96b3f53f17150 ]
    
    Existing user space applications maintained by the Osmocom project are
    breaking since a recent fix that addresses incorrect error checking.
    
    Restore operation for user space programs that specify -1 as file
    descriptor to skip GTPv0 or GTPv1 only sockets.
    
    Fixes: defd8b3c37b0 ("gtp: fix a potential NULL pointer dereference")
    Reported-by: Pau Espin Pedrol <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Tested-by: Oliver Smith <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gtp: simplify error handling code in 'gtp_encap_enable()' [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Jan 5 18:36:07 2020 +0100

    gtp: simplify error handling code in 'gtp_encap_enable()'
    
    [ Upstream commit b289ba5e07105548b8219695e5443d807a825eb8 ]
    
    'gtp_encap_disable_sock(sk)' handles the case where sk is NULL, so there
    is no need to test it before calling the function.
    
    This saves a few line of code.
    
    Signed-off-by: Christophe JAILLET <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 7515e37bce5c ("gtp: allow -1 to be specified as file description from userspace")
    Signed-off-by: Sasha Levin <[email protected]>

 
hid: intel-ish-hid: Fix uninitialized variable 'rv' in ish_fw_xfer_direct_dma [+ + +]
Author: SurajSonawane2415 <[email protected]>
Date:   Fri Oct 4 13:29:44 2024 +0530

    hid: intel-ish-hid: Fix uninitialized variable 'rv' in ish_fw_xfer_direct_dma
    
    commit d41bff05a61fb539f21e9bf0d39fac77f457434e upstream.
    
    Fix the uninitialized symbol 'rv' in the function ish_fw_xfer_direct_dma
    to resolve the following warning from the smatch tool:
    drivers/hid/intel-ish-hid/ishtp-fw-loader.c:714 ish_fw_xfer_direct_dma()
    error: uninitialized symbol 'rv'.
    Initialize 'rv' to 0 to prevent undefined behavior from uninitialized
    access.
    
    Cc: [email protected]
    Fixes: 91b228107da3 ("HID: intel-ish-hid: ISH firmware loader client driver")
    Signed-off-by: SurajSonawane2415 <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
HID: plantronics: Workaround for an unexcepted opposite volume key [+ + +]
Author: Wade Wang <[email protected]>
Date:   Mon Sep 16 16:56:00 2024 +0800

    HID: plantronics: Workaround for an unexcepted opposite volume key
    
    commit 87b696209007b7c4ef7bdfe39ea0253404a43770 upstream.
    
    Some Plantronics headset as the below send an unexcept opposite
    volume key's HID report for each volume key press after 200ms, like
    unecepted Volume Up Key following Volume Down key pressed by user.
    This patch adds a quirk to hid-plantronics for these devices, which
    will ignore the second unexcepted opposite volume key if it happens
    within 220ms from the last one that was handled.
        Plantronics EncorePro 500 Series  (047f:431e)
        Plantronics Blackwire_3325 Series (047f:430c)
    
    The patch was tested on the mentioned model, it shouldn't affect
    other models, however, this quirk might be needed for them too.
    Auto-repeat (when a key is held pressed) is not affected per test
    result.
    
    Cc: [email protected]
    Signed-off-by: Wade Wang <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event [+ + +]
Author: Haiyang Zhang <[email protected]>
Date:   Fri Oct 18 11:25:22 2024 -0700

    hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event
    
    commit 4c262801ea60c518b5bebc22a09f5b78b3147da2 upstream.
    
    The existing code moves VF to the same namespace as the synthetic NIC
    during netvsc_register_vf(). But, if the synthetic device is moved to a
    new namespace after the VF registration, the VF won't be moved together.
    
    To make the behavior more consistent, add a namespace check for synthetic
    NIC's NETDEV_REGISTER event (generated during its move), and move the VF
    if it is not in the same namespace.
    
    Cc: [email protected]
    Fixes: c0a41b887ce6 ("hv_netvsc: move VF to same namespace as netvsc device")
    Suggested-by: Stephen Hemminger <[email protected]>
    Signed-off-by: Haiyang Zhang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hwmon: (max16065) Fix overflows seen when writing limits [+ + +]
Author: Guenter Roeck <[email protected]>
Date:   Thu Jul 18 09:52:01 2024 -0700

    hwmon: (max16065) Fix overflows seen when writing limits
    
    [ Upstream commit 744ec4477b11c42e2c8de9eb8364675ae7a0bd81 ]
    
    Writing large limits resulted in overflows as reported by module tests.
    
    in0_lcrit: Suspected overflow: [max=5538, read 0, written 2147483647]
    in0_crit: Suspected overflow: [max=5538, read 0, written 2147483647]
    in0_min: Suspected overflow: [max=5538, read 0, written 2147483647]
    
    Fix the problem by clamping prior to multiplications and the use of
    DIV_ROUND_CLOSEST, and by using consistent variable types.
    
    Reviewed-by: Tzung-Bi Shih <[email protected]>
    Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles")
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwmon: (ntc_thermistor) fix module autoloading [+ + +]
Author: Yuntao Liu <[email protected]>
Date:   Thu Aug 15 08:30:21 2024 +0000

    hwmon: (ntc_thermistor) fix module autoloading
    
    [ Upstream commit b6964d66a07a9003868e428a956949e17ab44d7e ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
    based on the alias from of_device_id table.
    
    Fixes: 9e8269de100d ("hwmon: (ntc_thermistor) Add DT with IIO support to NTC thermistor driver")
    Signed-off-by: Yuntao Liu <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwrng: mtk - Use devm_pm_runtime_enable [+ + +]
Author: Guoqing Jiang <[email protected]>
Date:   Mon Aug 26 15:04:15 2024 +0800

    hwrng: mtk - Use devm_pm_runtime_enable
    
    commit 78cb66caa6ab5385ac2090f1aae5f3c19e08f522 upstream.
    
    Replace pm_runtime_enable with the devres-enabled version which
    can trigger pm_runtime_disable.
    
    Otherwise, the below appears during reload driver.
    
    mtk_rng 1020f000.rng: Unbalanced pm_runtime_enable!
    
    Fixes: 81d2b34508c6 ("hwrng: mtk - add runtime PM support")
    Cc: <[email protected]>
    Suggested-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Guoqing Jiang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i2c: aspeed: Update the stop sw state when the bus recovery occurs [+ + +]
Author: Tommy Huang <[email protected]>
Date:   Wed Sep 11 17:39:51 2024 +0800

    i2c: aspeed: Update the stop sw state when the bus recovery occurs
    
    commit 93701d3b84ac5f3ea07259d4ced405c53d757985 upstream.
    
    When the i2c bus recovery occurs, driver will send i2c stop command
    in the scl low condition. In this case the sw state will still keep
    original situation. Under multi-master usage, i2c bus recovery will
    be called when i2c transfer timeout occurs. Update the stop command
    calling with aspeed_i2c_do_stop function to update master_state.
    
    Fixes: f327c686d3ba ("i2c: aspeed: added driver for Aspeed I2C")
    Cc: [email protected] # v4.13+
    Signed-off-by: Tommy Huang <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: i801: Use a different adapter-name for IDF adapters [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Mon Aug 12 22:39:48 2024 +0200

    i2c: i801: Use a different adapter-name for IDF adapters
    
    [ Upstream commit 43457ada98c824f310adb7bd96bd5f2fcd9a3279 ]
    
    On chipsets with a second 'Integrated Device Function' SMBus controller use
    a different adapter-name for the second IDF adapter.
    
    This allows platform glue code which is looking for the primary i801
    adapter to manually instantiate i2c_clients on to differentiate
    between the 2.
    
    This allows such code to find the primary i801 adapter by name, without
    needing to duplicate the PCI-ids to feature-flags mapping from i2c-i801.c.
    
    Reviewed-by: Pali Rohár <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Acked-by: Wolfram Sang <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: isch: Add missed 'else' [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Wed Sep 11 18:39:14 2024 +0300

    i2c: isch: Add missed 'else'
    
    commit 1db4da55070d6a2754efeb3743f5312fc32f5961 upstream.
    
    In accordance with the existing comment and code analysis
    it is quite likely that there is a missed 'else' when adapter
    times out. Add it.
    
    Fixes: 5bc1200852c3 ("i2c: Add Intel SCH SMBus support")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Cc: <[email protected]> # v2.6.27+
    Signed-off-by: Andi Shyti <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: qcom-geni: Grow a dev pointer to simplify code [+ + +]
Author: Stephen Boyd <[email protected]>
Date:   Tue Mar 10 08:43:57 2020 -0700

    i2c: qcom-geni: Grow a dev pointer to simplify code
    
    [ Upstream commit 3b7d81f08a6a2bdd406df4355b08d39def8104aa ]
    
    Some lines are long here. Use a struct dev pointer to shorten lines and
    simplify code. The clk_get() call can fail because of EPROBE_DEFER
    problems too, so just remove the error print message because it isn't
    useful. Finally, platform_get_irq() already prints an error so just
    remove that error message.
    
    Reviewed-by: Douglas Anderson <[email protected]>
    Reviewed-by: Brendan Higgins <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Reviewed-by: Amit Kucheria <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Stable-dep-of: e2c85d85a05f ("i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()")
    Signed-off-by: Sasha Levin <[email protected]>

i2c: qcom-geni: Let firmware specify irq trigger flags [+ + +]
Author: Stephen Boyd <[email protected]>
Date:   Tue Mar 10 08:43:56 2020 -0700

    i2c: qcom-geni: Let firmware specify irq trigger flags
    
    [ Upstream commit b2ca8800621b95ecced081376de9fe256b1fa479 ]
    
    We don't need to force IRQF_TRIGGER_HIGH here as the DT or ACPI tables
    should take care of this for us. Just use 0 instead so that we use the
    flags from the firmware. Also, remove specify dev_name() for the irq
    name so that we can get better information in /proc/interrupts about
    which device is generating interrupts.
    
    Cc: Alok Chauhan <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Reviewed-by: Brendan Higgins <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Reviewed-by: Amit Kucheria <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Stable-dep-of: e2c85d85a05f ("i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()")
    Signed-off-by: Sasha Levin <[email protected]>

i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Thu Sep 12 11:34:59 2024 +0800

    i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit e2c85d85a05f16af2223fcc0195ff50a7938b372 ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Cc: <[email protected]> # v4.19+
    Acked-by: Mukesh Kumar Savaliya <[email protected]>
    Reviewed-by: Vladimir Zapolskiy <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume [+ + +]
Author: Marek Vasut <[email protected]>
Date:   Mon Sep 30 21:27:41 2024 +0200

    i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume
    
    commit 048bbbdbf85e5e00258dfb12f5e368f908801d7b upstream.
    
    In case there is any sort of clock controller attached to this I2C bus
    controller, for example Versaclock or even an AIC32x4 I2C codec, then
    an I2C transfer triggered from the clock controller clk_ops .prepare
    callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.
    
    This is because the clock controller first grabs the prepare_lock mutex
    and then performs the prepare operation, including its I2C access. The
    I2C access resumes this I2C bus controller via .runtime_resume callback,
    which calls clk_prepare_enable(), which attempts to grab the prepare_lock
    mutex again and deadlocks.
    
    Since the clock are already prepared since probe() and unprepared in
    remove(), use simple clk_enable()/clk_disable() calls to enable and
    disable the clock on runtime suspend and resume, to avoid hitting the
    prepare_lock mutex.
    
    Acked-by: Alain Volmat <[email protected]>
    Signed-off-by: Marek Vasut <[email protected]>
    Fixes: 4e7bca6fc07b ("i2c: i2c-stm32f7: add PM Runtime support")
    Cc: <[email protected]> # v5.0+
    Signed-off-by: Andi Shyti <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: xiic: Wait for TX empty to avoid missed TX NAKs [+ + +]
Author: Robert Hancock <[email protected]>
Date:   Tue Nov 21 18:11:16 2023 +0000

    i2c: xiic: Wait for TX empty to avoid missed TX NAKs
    
    commit 521da1e9225450bd323db5fa5bca942b1dc485b7 upstream.
    
    Frequently an I2C write will be followed by a read, such as a register
    address write followed by a read of the register value. In this driver,
    when the TX FIFO half empty interrupt was raised and it was determined
    that there was enough space in the TX FIFO to send the following read
    command, it would do so without waiting for the TX FIFO to actually
    empty.
    
    Unfortunately it appears that in some cases this can result in a NAK
    that was raised by the target device on the write, such as due to an
    unsupported register address, being ignored and the subsequent read
    being done anyway. This can potentially put the I2C bus into an
    invalid state and/or result in invalid read data being processed.
    
    To avoid this, once a message has been fully written to the TX FIFO,
    wait for the TX FIFO empty interrupt before moving on to the next
    message, to ensure NAKs are handled properly.
    
    Fixes: e1d5b6598cdc ("i2c: Add support for Xilinx XPS IIC Bus Interface")
    Signed-off-by: Robert Hancock <[email protected]>
    Cc: <[email protected]> # v2.6.34+
    Reviewed-by: Manikanta Guntupalli <[email protected]>
    Acked-by: Michal Simek <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ice: Adjust over allocation of memory in ice_sched_add_root_node() and ice_sched_add_node() [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Wed Jul 10 15:39:49 2024 +0300

    ice: Adjust over allocation of memory in ice_sched_add_root_node() and ice_sched_add_node()
    
    [ Upstream commit 62fdaf9e8056e9a9e6fe63aa9c816ec2122d60c6 ]
    
    In ice_sched_add_root_node() and ice_sched_add_node() there are calls to
    devm_kcalloc() in order to allocate memory for array of pointers to
    'ice_sched_node' structure. But incorrect types are used as sizeof()
    arguments in these calls (structures instead of pointers) which leads to
    over allocation of memory.
    
    Adjust over allocation of memory by correcting types in devm_kcalloc()
    sizeof() arguments.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Reviewed-by: Przemek Kitszel <[email protected]>
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ice: fix accounting for filters shared by multiple VSIs [+ + +]
Author: Jacob Keller <[email protected]>
Date:   Wed Jul 31 09:55:55 2024 -0700

    ice: fix accounting for filters shared by multiple VSIs
    
    [ Upstream commit e843cf7b34fe2e0c1afc55e1f3057375c9b77a14 ]
    
    When adding a switch filter (such as a MAC or VLAN filter), it is expected
    that the driver will detect the case where the filter already exists, and
    return -EEXIST. This is used by calling code such as ice_vc_add_mac_addr,
    and ice_vsi_add_vlan to avoid incrementing the accounting fields such as
    vsi->num_vlan or vf->num_mac.
    
    This logic works correctly for the case where only a single VSI has added a
    given switch filter.
    
    When a second VSI adds the same switch filter, the driver converts the
    existing filter from an ICE_FWD_TO_VSI filter into an ICE_FWD_TO_VSI_LIST
    filter. This saves switch resources, by ensuring that multiple VSIs can
    re-use the same filter.
    
    The ice_add_update_vsi_list() function is responsible for doing this
    conversion. When first converting a filter from the FWD_TO_VSI into
    FWD_TO_VSI_LIST, it checks if the VSI being added is the same as the
    existing rule's VSI. In such a case it returns -EEXIST.
    
    However, when the switch rule has already been converted to a
    FWD_TO_VSI_LIST, the logic is different. Adding a new VSI in this case just
    requires extending the VSI list entry. The logic for checking if the rule
    already exists in this case returns 0 instead of -EEXIST.
    
    This breaks the accounting logic mentioned above, so the counters for how
    many MAC and VLAN filters exist for a given VF or VSI no longer accurately
    reflect the actual count. This breaks other code which relies on these
    counts.
    
    In typical usage this primarily affects such filters generally shared by
    multiple VSIs such as VLAN 0, or broadcast and multicast MAC addresses.
    
    Fix this by correctly reporting -EEXIST in the case of adding the same VSI
    to a switch rule already converted to ICE_FWD_TO_VSI_LIST.
    
    Fixes: 9daf8208dd4d ("ice: Add support for switch filter programming")
    Signed-off-by: Jacob Keller <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ice: fix VLAN replay after reset [+ + +]
Author: Dave Ertman <[email protected]>
Date:   Wed Sep 18 14:02:56 2024 -0400

    ice: fix VLAN replay after reset
    
    [ Upstream commit 0eae2c136cb624e4050092feb59f18159b4f2512 ]
    
    There is a bug currently when there are more than one VLAN defined
    and any reset that affects the PF is initiated, after the reset rebuild
    no traffic will pass on any VLAN but the last one created.
    
    This is caused by the iteration though the VLANs during replay each
    clearing the vsi_map bitmap of the VSI that is being replayed.  The
    problem is that during rhe replay, the pointer to the vsi_map bitmap
    is used by each successive vlan to determine if it should be replayed
    on this VSI.
    
    The logic was that the replay of the VLAN would replace the bit in the map
    before the next VLAN would iterate through.  But, since the replay copies
    the old bitmap pointer to filt_replay_rules and creates a new one for the
    recreated VLANS, it does not do this, and leaves the old bitmap broken
    to be used to replay the remaining VLANs.
    
    Since the old bitmap will be cleaned up in post replay cleanup, there is
    no need to alter it and break following VLAN replay, so don't clear the
    bit.
    
    Fixes: 334cb0626de1 ("ice: Implement VSI replay framework")
    Reviewed-by: Przemek Kitszel <[email protected]>
    Signed-off-by: Dave Ertman <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ieee802154: Fix build error [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Mon Sep 9 21:17:40 2024 +0800

    ieee802154: Fix build error
    
    [ Upstream commit addf89774e48c992316449ffab4f29c2309ebefb ]
    
    If REGMAP_SPI is m and IEEE802154_MCR20A is y,
    
            mcr20a.c:(.text+0x3ed6c5b): undefined reference to `__devm_regmap_init_spi'
            ld: mcr20a.c:(.text+0x3ed6cb5): undefined reference to `__devm_regmap_init_spi'
    
    Select REGMAP_SPI for IEEE802154_MCR20A to fix it.
    
    Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver driver")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Stefan Schmidt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
igb: Do not bring the device up after non-fatal error [+ + +]
Author: Mohamed Khalfella <[email protected]>
Date:   Tue Sep 24 15:06:01 2024 -0600

    igb: Do not bring the device up after non-fatal error
    
    [ Upstream commit 330a699ecbfc9c26ec92c6310686da1230b4e7eb ]
    
    Commit 004d25060c78 ("igb: Fix igb_down hung on surprise removal")
    changed igb_io_error_detected() to ignore non-fatal pcie errors in order
    to avoid hung task that can happen when igb_down() is called multiple
    times. This caused an issue when processing transient non-fatal errors.
    igb_io_resume(), which is called after igb_io_error_detected(), assumes
    that device is brought down by igb_io_error_detected() if the interface
    is up. This resulted in panic with stacktrace below.
    
    [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down
    [  T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0
    [  T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
    [  T292] igb 0000:09:00.0:   device [8086:1537] error status/mask=00004000/00000000
    [  T292] igb 0000:09:00.0:    [14] CmpltTO [  200.105524,009][  T292] igb 0000:09:00.0: AER:   TLP Header: 00000000 00000000 00000000 00000000
    [  T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message
    [  T292] igb 0000:09:00.0: Non-correctable non-fatal error reported.
    [  T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message
    [  T292] pcieport 0000:00:1c.5: AER: broadcast resume message
    [  T292] ------------[ cut here ]------------
    [  T292] kernel BUG at net/core/dev.c:6539!
    [  T292] invalid opcode: 0000 [#1] PREEMPT SMP
    [  T292] RIP: 0010:napi_enable+0x37/0x40
    [  T292] Call Trace:
    [  T292]  <TASK>
    [  T292]  ? die+0x33/0x90
    [  T292]  ? do_trap+0xdc/0x110
    [  T292]  ? napi_enable+0x37/0x40
    [  T292]  ? do_error_trap+0x70/0xb0
    [  T292]  ? napi_enable+0x37/0x40
    [  T292]  ? napi_enable+0x37/0x40
    [  T292]  ? exc_invalid_op+0x4e/0x70
    [  T292]  ? napi_enable+0x37/0x40
    [  T292]  ? asm_exc_invalid_op+0x16/0x20
    [  T292]  ? napi_enable+0x37/0x40
    [  T292]  igb_up+0x41/0x150
    [  T292]  igb_io_resume+0x25/0x70
    [  T292]  report_resume+0x54/0x70
    [  T292]  ? report_frozen_detected+0x20/0x20
    [  T292]  pci_walk_bus+0x6c/0x90
    [  T292]  ? aer_print_port_info+0xa0/0xa0
    [  T292]  pcie_do_recovery+0x22f/0x380
    [  T292]  aer_process_err_devices+0x110/0x160
    [  T292]  aer_isr+0x1c1/0x1e0
    [  T292]  ? disable_irq_nosync+0x10/0x10
    [  T292]  irq_thread_fn+0x1a/0x60
    [  T292]  irq_thread+0xe3/0x1a0
    [  T292]  ? irq_set_affinity_notifier+0x120/0x120
    [  T292]  ? irq_affinity_notify+0x100/0x100
    [  T292]  kthread+0xe2/0x110
    [  T292]  ? kthread_complete_and_exit+0x20/0x20
    [  T292]  ret_from_fork+0x2d/0x50
    [  T292]  ? kthread_complete_and_exit+0x20/0x20
    [  T292]  ret_from_fork_asm+0x11/0x20
    [  T292]  </TASK>
    
    To fix this issue igb_io_resume() checks if the interface is running and
    the device is not down this means igb_io_error_detected() did not bring
    the device down and there is no need to bring it up.
    
    Signed-off-by: Mohamed Khalfella <[email protected]>
    Reviewed-by: Yuanyuan Zhong <[email protected]>
    Fixes: 004d25060c78 ("igb: Fix igb_down hung on surprise removal")
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iio: adc: ad7606: fix oversampling gpio array [+ + +]
Author: Guillaume Stols <[email protected]>
Date:   Tue Jul 2 17:34:10 2024 +0000

    iio: adc: ad7606: fix oversampling gpio array
    
    [ Upstream commit 8dc4594b54dbaaba40dc8884ad3d42083de39434 ]
    
    gpiod_set_array_value was misused here: the implementation relied on the
    assumption that an unsigned long was required for each gpio, while the
    function expects a bit array stored in "as much unsigned long as needed
    for storing one bit per GPIO", i.e it is using a bit field.
    
    This leaded to incorrect parameter passed to gpiod_set_array_value, that
    would set 1 value instead of 3.
    It also prevents to select the software mode correctly for the AD7606B.
    
    Fixes: d2a415c86c6b ("iio: adc: ad7606: Add support for AD7606B ADC")
    Fixes: 41f71e5e7daf ("staging: iio: adc: ad7606: Use find_closest() macro")
    Signed-off-by: Guillaume Stols <[email protected]>
    Reviewed-by: Nuno Sa <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: adc: ad7606: fix standby gpio state to match the documentation [+ + +]
Author: Guillaume Stols <[email protected]>
Date:   Tue Jul 2 17:34:11 2024 +0000

    iio: adc: ad7606: fix standby gpio state to match the documentation
    
    [ Upstream commit 059fe4f8bbdf5cad212e1aeeb3e8968c80b9ff3b ]
    
    The binding's documentation specifies that "As the line is active low, it
    should be marked GPIO_ACTIVE_LOW". However, in the driver, it was handled
    the opposite way. This commit sets the driver's behaviour in sync with the
    documentation
    
    Fixes: 722407a4e8c0 ("staging:iio:ad7606: Use GPIO descriptor API")
    Signed-off-by: Guillaume Stols <[email protected]>
    Reviewed-by: Nuno Sa <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 23:04:49 2024 +0200

    iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
    
    commit eb143d05def52bc6d193e813018e5fa1a0e47c77 upstream.
    
    This driver makes use of triggered buffers, but does not select the
    required modules.
    
    Add the missing 'select IIO_BUFFER' and 'select IIO_TRIGGERED_BUFFER'.
    
    Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 23:04:50 2024 +0200

    iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
    
    commit 4c4834fd8696a949d1b1f1c2c5b96e1ad2083b02 upstream.
    
    This driver makes use of triggered buffers, but does not select the
    required modules.
    
    Fixes: 2a86487786b5 ("iio: adc: ti-ads8688: add trigger and buffer support")
    Add the missing 'select IIO_BUFFER' and 'select IIO_TRIGGERED_BUFFER'.
    
    Signed-off-by: Javier Carrasco <[email protected]>
    Reviewed-by: Sean Nyekjaer <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 18:49:39 2024 +0200

    iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig
    
    commit 252ff06a4cb4e572cb3c7fcfa697db96b08a7781 upstream.
    
    This driver makes use of regmap_spi, but does not select the required
    module.
    Add the missing 'select REGMAP_SPI'.
    
    Fixes: 8316cebd1e59 ("iio: dac: add support for ltc1660")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 18:49:40 2024 +0200

    iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig
    
    commit 27b6aa68a68105086aef9f0cb541cd688e5edea8 upstream.
    
    This driver makes use of regmap_mmio, but does not select the required
    module.
    Add the missing 'select REGMAP_MMIO'.
    
    Fixes: 4d4b30526eb8 ("iio: dac: add support for stm32 DAC")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: hid-sensors: Fix an error handling path in _hid_sensor_set_report_latency() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Thu Oct 3 20:41:12 2024 +0200

    iio: hid-sensors: Fix an error handling path in _hid_sensor_set_report_latency()
    
    commit 3a29b84cf7fbf912a6ab1b9c886746f02b74ea25 upstream.
    
    If hid_sensor_set_report_latency() fails, the error code should be returned
    instead of a value likely to be interpreted as 'success'.
    
    Fixes: 138bc7969c24 ("iio: hid-sensor-hub: Implement batch mode")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Acked-by: Srinivas Pandruvada <[email protected]>
    Link: https://patch.msgid.link/c50640665f091a04086e5092cf50f73f2055107a.1727980825.git.christophe.jaillet@wanadoo.fr
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: light: opt3001: add missing full-scale range value [+ + +]
Author: Emil Gedenryd <[email protected]>
Date:   Fri Sep 13 11:57:02 2024 +0200

    iio: light: opt3001: add missing full-scale range value
    
    commit 530688e39c644543b71bdd9cb45fdfb458a28eaa upstream.
    
    The opt3001 driver uses predetermined full-scale range values to
    determine what exponent to use for event trigger threshold values.
    The problem is that one of the values specified in the datasheet is
    missing from the implementation. This causes larger values to be
    scaled down to an incorrect exponent, effectively reducing the
    maximum settable threshold value by a factor of 2.
    
    Add missing full-scale range array value.
    
    Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor")
    Signed-off-by: Emil Gedenryd <[email protected]>
    Cc: <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: magnetometer: ak8975: Fix reading for ak099xx sensors [+ + +]
Author: Barnabás Czémán <[email protected]>
Date:   Mon Aug 19 00:29:40 2024 +0200

    iio: magnetometer: ak8975: Fix reading for ak099xx sensors
    
    commit 129464e86c7445a858b790ac2d28d35f58256bbe upstream.
    
    Move ST2 reading with overflow handling after measurement data
    reading.
    ST2 register read have to be read after read measurment data,
    because it means end of the reading and realease the lock on the data.
    Remove ST2 read skip on interrupt based waiting because ST2 required to
    be read out at and of the axis read.
    
    Fixes: 57e73a423b1e ("iio: ak8975: add ak09911 and ak09912 support")
    Signed-off-by: Barnabás Czémán <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 23:04:59 2024 +0200

    iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
    
    commit 75461a0b15d7c026924d0001abce0476bbc7eda8 upstream.
    
    This driver makes use of triggered buffers, but does not select the
    required modules.
    
    Add the missing 'select IIO_BUFFER' and 'select IIO_TRIGGERED_BUFFER'.
    
    Fixes: 16b05261537e ("mb1232.c: add distance iio sensor with i2c")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
inet: inet_defrag: prevent sk release while still in use [+ + +]
Author: Florian Westphal <[email protected]>
Date:   Tue Mar 26 11:18:41 2024 +0100

    inet: inet_defrag: prevent sk release while still in use
    
    commit 18685451fc4e546fc0e718580d32df3c0e5c8272 upstream.
    
    ip_local_out() and other functions can pass skb->sk as function argument.
    
    If the skb is a fragment and reassembly happens before such function call
    returns, the sk must not be released.
    
    This affects skb fragments reassembled via netfilter or similar
    modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
    
    Eric Dumazet made an initial analysis of this bug.  Quoting Eric:
      Calling ip_defrag() in output path is also implying skb_orphan(),
      which is buggy because output path relies on sk not disappearing.
    
      A relevant old patch about the issue was :
      8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
    
      [..]
    
      net/ipv4/ip_output.c depends on skb->sk being set, and probably to an
      inet socket, not an arbitrary one.
    
      If we orphan the packet in ipvlan, then downstream things like FQ
      packet scheduler will not work properly.
    
      We need to change ip_defrag() to only use skb_orphan() when really
      needed, ie whenever frag_list is going to be used.
    
    Eric suggested to stash sk in fragment queue and made an initial patch.
    However there is a problem with this:
    
    If skb is refragmented again right after, ip_do_fragment() will copy
    head->sk to the new fragments, and sets up destructor to sock_wfree.
    IOW, we have no choice but to fix up sk_wmem accouting to reflect the
    fully reassembled skb, else wmem will underflow.
    
    This change moves the orphan down into the core, to last possible moment.
    As ip_defrag_offset is aliased with sk_buff->sk member, we must move the
    offset into the FRAG_CB, else skb->sk gets clobbered.
    
    This allows to delay the orphaning long enough to learn if the skb has
    to be queued or if the skb is completing the reasm queue.
    
    In the former case, things work as before, skb is orphaned.  This is
    safe because skb gets queued/stolen and won't continue past reasm engine.
    
    In the latter case, we will steal the skb->sk reference, reattach it to
    the head skb, and fix up wmem accouting when inet_frag inflates truesize.
    
    Fixes: 7026b1ddb6b8 ("netfilter: Pass socket pointer down through okfn().")
    Diagnosed-by: Eric Dumazet <[email protected]>
    Reported-by: xingwei lee <[email protected]>
    Reported-by: yue sun <[email protected]>
    Reported-by: [email protected]
    Signed-off-by: Florian Westphal <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Saeed Mirzamohammadi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Input: adp5589-keys - fix adp5589_gpio_get_value() [+ + +]
Author: Nuno Sa <[email protected]>
Date:   Tue Oct 1 07:47:23 2024 -0700

    Input: adp5589-keys - fix adp5589_gpio_get_value()
    
    commit c684771630e64bc39bddffeb65dd8a6612a6b249 upstream.
    
    The adp5589 seems to have the same behavior as similar devices as
    explained in commit 910a9f5636f5 ("Input: adp5588-keys - get value from
    data out when dir is out").
    
    Basically, when the gpio is set as output we need to get the value from
    ADP5589_GPO_DATA_OUT_A register instead of ADP5589_GPI_STATUS_A.
    
    Fixes: 9d2e173644bb ("Input: ADP5589 - new driver for I2C Keypad Decoder and I/O Expander")
    Signed-off-by: Nuno Sa <[email protected]>
    Link: https://lore.kernel.org/r/20241001-b4-dev-adp5589-fw-conversion-v1-2-fca0149dfc47@analog.com
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: synaptics-rmi4 - fix UAF of IRQ domain on driver removal [+ + +]
Author: Mathias Krause <[email protected]>
Date:   Wed Oct 9 05:42:12 2024 +0000

    Input: synaptics-rmi4 - fix UAF of IRQ domain on driver removal
    
    commit fbf8d71742557abaf558d8efb96742d442720cc2 upstream.
    
    Calling irq_domain_remove() will lead to freeing the IRQ domain
    prematurely. The domain is still referenced and will be attempted to get
    used via rmi_free_function_list() -> rmi_unregister_function() ->
    irq_dispose_mapping() -> irq_get_irq_data()'s ->domain pointer.
    
    With PaX's MEMORY_SANITIZE this will lead to an access fault when
    attempting to dereference embedded pointers, as in Torsten's report that
    was faulting on the 'domain->ops->unmap' test.
    
    Fix this by releasing the IRQ domain only after all related IRQs have
    been deactivated.
    
    Fixes: 24d28e4f1271 ("Input: synaptics-rmi4 - convert irq distribution to irq_domain")
    Reported-by: Torsten Hilbrich <[email protected]>
    Signed-off-by: Mathias Krause <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Tzung-Bi Shih <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipmi: docs: don't advertise deprecated sysfs entries [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Sun Sep 1 11:02:11 2024 +0200

    ipmi: docs: don't advertise deprecated sysfs entries
    
    [ Upstream commit 64dce81f8c373c681e62d5ffe0397c45a35d48a2 ]
    
    "i2c-adapter" class entries are deprecated since 2009. Switch to the
    proper location.
    
    Reported-by: Heiner Kallweit <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Fixes: 259307074bfc ("ipmi: Add SMBus interface driver (SSIF)")
    Signed-off-by: Wolfram Sang <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Corey Minyard <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Fri Aug 9 16:54:02 2024 -0700

    ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR).
    
    [ Upstream commit e3af3d3c5b26c33a7950e34e137584f6056c4319 ]
    
    dev->ip_ptr could be NULL if we set an invalid MTU.
    
    Even then, if we issue ioctl(SIOCSIFADDR) for a new IPv4 address,
    devinet_ioctl() allocates struct in_ifaddr and fails later in
    inet_set_ifa() because in_dev is NULL.
    
    Let's move the check earlier.
    
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv4: give an IPv4 dev to blackhole_netdev [+ + +]
Author: Xin Long <[email protected]>
Date:   Wed Oct 9 14:47:13 2024 -0400

    ipv4: give an IPv4 dev to blackhole_netdev
    
    [ Upstream commit 22600596b6756b166fd052d5facb66287e6f0bad ]
    
    After commit 8d7017fd621d ("blackhole_netdev: use blackhole_netdev to
    invalidate dst entries"), blackhole_netdev was introduced to invalidate
    dst cache entries on the TX path whenever the cache times out or is
    flushed.
    
    When two UDP sockets (sk1 and sk2) send messages to the same destination
    simultaneously, they are using the same dst cache. If the dst cache is
    invalidated on one path (sk2) while the other (sk1) is still transmitting,
    sk1 may try to use the invalid dst entry.
    
             CPU1                   CPU2
    
          udp_sendmsg(sk1)       udp_sendmsg(sk2)
          udp_send_skb()
          ip_output()
                                                 <--- dst timeout or flushed
                                 dst_dev_put()
          ip_finish_output2()
          ip_neigh_for_gw()
    
    This results in a scenario where ip_neigh_for_gw() returns -EINVAL because
    blackhole_dev lacks an in_dev, which is needed to initialize the neigh in
    arp_constructor(). This error is then propagated back to userspace,
    breaking the UDP application.
    
    The patch fixes this issue by assigning an in_dev to blackhole_dev for
    IPv4, similar to what was done for IPv6 in commit e5f80fcf869a ("ipv6:
    give an IPv6 dev to blackhole_netdev"). This ensures that even when the
    dst entry is invalidated with blackhole_dev, it will not fail to create
    the neigh entry.
    
    As devinet_init() is called ealier than blackhole_netdev_init() in system
    booting, it can not assign the in_dev to blackhole_dev in devinet_init().
    As Paolo suggested, add a separate late_initcall() in devinet.c to ensure
    inet_blackhole_dev_init() is called after blackhole_netdev_init().
    
    Fixes: 8d7017fd621d ("blackhole_netdev: use blackhole_netdev to invalidate dst entries")
    Signed-off-by: Xin Long <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/3000792d45ca44e16c785ebe2b092e610e5b3df1.1728499633.git.lucien.xin@gmail.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv4: ip_gre: Fix drops of small packets in ipgre_xmit [+ + +]
Author: Anton Danilov <[email protected]>
Date:   Wed Sep 25 02:51:59 2024 +0300

    ipv4: ip_gre: Fix drops of small packets in ipgre_xmit
    
    [ Upstream commit c4a14f6d9d17ad1e41a36182dd3b8a5fd91efbd7 ]
    
    Regression Description:
    
    Depending on the options specified for the GRE tunnel device, small
    packets may be dropped. This occurs because the pskb_network_may_pull
    function fails due to the packet's insufficient length.
    
    For example, if only the okey option is specified for the tunnel device,
    original (before encapsulation) packets smaller than 28 bytes (including
    the IPv4 header) will be dropped. This happens because the required
    length is calculated relative to the network header, not the skb->head.
    
    Here is how the required length is computed and checked:
    
    * The pull_len variable is set to 28 bytes, consisting of:
      * IPv4 header: 20 bytes
      * GRE header with Key field: 8 bytes
    
    * The pskb_network_may_pull function adds the network offset, shifting
    the checkable space further to the beginning of the network header and
    extending it to the beginning of the packet. As a result, the end of
    the checkable space occurs beyond the actual end of the packet.
    
    Instead of ensuring that 28 bytes are present in skb->head, the function
    is requesting these 28 bytes starting from the network header. For small
    packets, this requested length exceeds the actual packet size, causing
    the check to fail and the packets to be dropped.
    
    This issue affects both locally originated and forwarded packets in
    DMVPN-like setups.
    
    How to reproduce (for local originated packets):
    
      ip link add dev gre1 type gre ikey 1.9.8.4 okey 1.9.8.4 \
              local <your-ip> remote 0.0.0.0
    
      ip link set mtu 1400 dev gre1
      ip link set up dev gre1
      ip address add 192.168.13.1/24 dev gre1
      ip neighbor add 192.168.13.2 lladdr <remote-ip> dev gre1
      ping -s 1374 -c 10 192.168.13.2
      tcpdump -vni gre1
      tcpdump -vni <your-ext-iface> 'ip proto 47'
      ip -s -s -d link show dev gre1
    
    Solution:
    
    Use the pskb_may_pull function instead the pskb_network_may_pull.
    
    Fixes: 80d875cfc9d3 ("ipv4: ip_gre: Avoid skb_pull() failure in ipgre_xmit()")
    Signed-off-by: Anton Danilov <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Wed Aug 14 15:52:22 2024 +0300

    ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family
    
    [ Upstream commit 8fed54758cd248cd311a2b5c1e180abef1866237 ]
    
    The NETLINK_FIB_LOOKUP netlink family can be used to perform a FIB
    lookup according to user provided parameters and communicate the result
    back to user space.
    
    However, unlike other users of the FIB lookup API, the upper DSCP bits
    and the ECN bits of the DS field are not masked, which can result in the
    wrong result being returned.
    
    Solve this by masking the upper DSCP bits and the ECN bits using
    IPTOS_RT_MASK.
    
    The structure that communicates the request and the response is not
    exported to user space, so it is unlikely that this netlink family is
    actually in use [1].
    
    [1] https://lore.kernel.org/netdev/ZpqpB8vJU%2FQ6LSqa@debian/
    
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: Guillaume Nault <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
jbd2: introduce/export functions jbd2_journal_submit|finish_inode_data_buffers() [+ + +]
Author: Mauricio Faria de Oliveira <[email protected]>
Date:   Mon Oct 5 21:48:38 2020 -0300

    jbd2: introduce/export functions jbd2_journal_submit|finish_inode_data_buffers()
    
    [ Upstream commit aa3c0c61f62d682259e3e66cdc01846290f9cd6c ]
    
    Export functions that implement the current behavior done
    for an inode in journal_submit|finish_inode_data_buffers().
    
    No functional change.
    
    Signed-off-by: Mauricio Faria de Oliveira <[email protected]>
    Suggested-by: Jan Kara <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Andreas Dilger <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 20cee68f5b44 ("ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard")
    Signed-off-by: Sasha Levin <[email protected]>

jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error [+ + +]
Author: Baokun Li <[email protected]>
Date:   Thu Jul 18 19:53:36 2024 +0800

    jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
    
    commit f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a upstream.
    
    In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()
    to recover some journal space. But if an error occurs while executing
    jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free
    space right away, we try other branches, and if j_committing_transaction
    is NULL (i.e., the tid is 0), we will get the following complain:
    
    ============================================
    JBD2: I/O error when updating journal superblock for sdd-8.
    __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available
    __jbd2_log_wait_for_space: no way to get more journal space in sdd-8
    ------------[ cut here ]------------
    WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0
    Modules linked in:
    CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1
    RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0
    Call Trace:
     <TASK>
     add_transaction_credits+0x5d1/0x5e0
     start_this_handle+0x1ef/0x6a0
     jbd2__journal_start+0x18b/0x340
     ext4_dirty_inode+0x5d/0xb0
     __mark_inode_dirty+0xe4/0x5d0
     generic_update_time+0x60/0x70
    [...]
    ============================================
    
    So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to
    clean up at the moment, continue to try to reclaim free space in other ways.
    
    Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt
    when updating journal superblock fails") to make jbd2_cleanup_journal_tail
    return the correct error code.
    
    Fixes: 8c3f25d8950c ("jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space")
    Cc: [email protected]
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
jfs: check if leafidx greater than num leaves per dmap tree [+ + +]
Author: Edward Adam Davis <[email protected]>
Date:   Sat Aug 24 09:25:23 2024 +0800

    jfs: check if leafidx greater than num leaves per dmap tree
    
    [ Upstream commit d64ff0d2306713ff084d4b09f84ed1a8c75ecc32 ]
    
    syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater
    than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.
    
    Shaggy:
    Modified sanity check to apply to control pages as well as leaf pages.
    
    Reported-and-tested-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=dca05492eff41f604890
    Signed-off-by: Edward Adam Davis <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

jfs: fix out-of-bounds in dbNextAG() and diAlloc() [+ + +]
Author: Jeongjun Park <[email protected]>
Date:   Mon Aug 19 13:05:46 2024 +0900

    jfs: fix out-of-bounds in dbNextAG() and diAlloc()
    
    [ Upstream commit e63866a475562810500ea7f784099bfe341e761a ]
    
    In dbNextAG() , there is no check for the case where bmp->db_numag is
    greater or same than MAXAG due to a polluted image, which causes an
    out-of-bounds. Therefore, a bounds check should be added in dbMount().
    
    And in dbNextAG(), a check for the case where agpref is greater than
    bmp->db_numag should be added, so an out-of-bounds exception should be
    prevented.
    
    Additionally, a check for the case where agno is greater or same than
    MAXAG should be added in diAlloc() to prevent out-of-bounds.
    
    Reported-by: Jeongjun Park <[email protected]>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Jeongjun Park <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

jfs: Fix sanity check in dbMount [+ + +]
Author: Dave Kleikamp <[email protected]>
Date:   Tue Oct 22 09:40:37 2024 -0500

    jfs: Fix sanity check in dbMount
    
    [ Upstream commit 67373ca8404fe57eb1bb4b57f314cff77ce54932 ]
    
    MAXAG is a legitimate value for bmp->db_numag
    
    Fixes: e63866a47556 ("jfs: fix out-of-bounds in dbNextAG() and diAlloc()")
    
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

jfs: Fix uaf in dbFreeBits [+ + +]
Author: Edward Adam Davis <[email protected]>
Date:   Sat Aug 24 10:50:48 2024 +0800

    jfs: Fix uaf in dbFreeBits
    
    [ Upstream commit d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234 ]
    
    [syzbot reported]
    ==================================================================
    BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline]
    BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752
    Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216
    
    CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/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
     __mutex_lock_common kernel/locking/mutex.c:587 [inline]
     __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752
     dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390
     dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]
     dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409
     dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650
     jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100
     jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:907 [inline]
     __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
    
    Freed by task 5218:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
     kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
     poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
     __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
     kasan_slab_free include/linux/kasan.h:184 [inline]
     slab_free_hook mm/slub.c:2252 [inline]
     slab_free mm/slub.c:4473 [inline]
     kfree+0x149/0x360 mm/slub.c:4594
     dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278
     jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247
     jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454
     reconfigure_super+0x445/0x880 fs/super.c:1083
     vfs_cmd_reconfigure fs/fsopen.c:263 [inline]
     vfs_fsconfig_locked fs/fsopen.c:292 [inline]
     __do_sys_fsconfig fs/fsopen.c:473 [inline]
     __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    [Analysis]
    There are two paths (dbUnmount and jfs_ioc_trim) that generate race
    condition when accessing bmap, which leads to the occurrence of uaf.
    
    Use the lock s_umount to synchronize them, in order to avoid uaf caused
    by race condition.
    
    Reported-and-tested-by: [email protected]
    Signed-off-by: Edward Adam Davis <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

jfs: Fix uninit-value access of new_ea in ea_buffer [+ + +]
Author: Zhao Mengmeng <[email protected]>
Date:   Wed Sep 4 09:07:58 2024 +0800

    jfs: Fix uninit-value access of new_ea in ea_buffer
    
    [ Upstream commit 2b59ffad47db1c46af25ccad157bb3b25147c35c ]
    
    syzbot reports that lzo1x_1_do_compress is using uninit-value:
    
    =====================================================
    BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178
    
    ...
    
    Uninit was stored to memory at:
     ea_put fs/jfs/xattr.c:639 [inline]
    
    ...
    
    Local variable ea_buf created at:
     __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662
     __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934
    
    =====================================================
    
    The reason is ea_buf->new_ea is not initialized properly.
    
    Fix this by using memset to empty its content at the beginning
    in ea_get().
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=02341e0daa42a15ce130
    Signed-off-by: Zhao Mengmeng <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

jfs: UBSAN: shift-out-of-bounds in dbFindBits [+ + +]
Author: Remington Brasga <[email protected]>
Date:   Wed Jul 10 00:12:44 2024 +0000

    jfs: UBSAN: shift-out-of-bounds in dbFindBits
    
    [ Upstream commit b0b2fc815e514221f01384f39fbfbff65d897e1c ]
    
    Fix issue with UBSAN throwing shift-out-of-bounds warning.
    
    Reported-by: [email protected]
    Signed-off-by: Remington Brasga <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ktest.pl: Avoid false positives with grub2 skip regex [+ + +]
Author: Daniel Jordan <[email protected]>
Date:   Wed Sep 4 13:55:30 2024 -0400

    ktest.pl: Avoid false positives with grub2 skip regex
    
    [ Upstream commit 2351e8c65404aabc433300b6bf90c7a37e8bbc4d ]
    
    Some distros have grub2 config files with the lines
    
        if [ x"${feature_menuentry_id}" = xy ]; then
          menuentry_id_option="--id"
        else
          menuentry_id_option=""
        fi
    
    which match the skip regex defined for grub2 in get_grub_index():
    
        $skip = '^\s*menuentry';
    
    These false positives cause the grub number to be higher than it
    should be, and the wrong kernel can end up booting.
    
    Grub documents the menuentry command with whitespace between it and the
    title, so make the skip regex reflect this.
    
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Daniel Jordan <[email protected]>
    Acked-by: John 'Warthog9' Hawley (Tenstorrent) <[email protected]>
    Signed-off-by: Steven Rostedt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kthread: add kthread_work tracepoints [+ + +]
Author: Rob Clark <[email protected]>
Date:   Mon Dec 14 19:03:14 2020 -0800

    kthread: add kthread_work tracepoints
    
    [ Upstream commit f630c7c6f10546ebff15c3a856e7949feb7a2372 ]
    
    While migrating some code from wq to kthread_worker, I found that I missed
    the execute_start/end tracepoints.  So add similar tracepoints for
    kthread_work.  And for completeness, queue_work tracepoint (although this
    one differs slightly from the matching workqueue tracepoint).
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Rob Clark <[email protected]>
    Cc: Rob Clark <[email protected]>
    Cc: Steven Rostedt <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: "Peter Zijlstra (Intel)" <[email protected]>
    Cc: Phil Auld <[email protected]>
    Cc: Valentin Schneider <[email protected]>
    Cc: Thara Gopinath <[email protected]>
    Cc: Randy Dunlap <[email protected]>
    Cc: Vincent Donnefort <[email protected]>
    Cc: Mel Gorman <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Marcelo Tosatti <[email protected]>
    Cc: Frederic Weisbecker <[email protected]>
    Cc: Ilias Stamatis <[email protected]>
    Cc: Liang Chen <[email protected]>
    Cc: Ben Dooks <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: "J. Bruce Fields" <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Stable-dep-of: e16c7b07784f ("kthread: fix task state in kthread worker if being frozen")
    Signed-off-by: Sasha Levin <[email protected]>

kthread: fix task state in kthread worker if being frozen [+ + +]
Author: Chen Yu <[email protected]>
Date:   Tue Aug 27 19:23:08 2024 +0800

    kthread: fix task state in kthread worker if being frozen
    
    [ Upstream commit e16c7b07784f3fb03025939c4590b9a7c64970a7 ]
    
    When analyzing a kernel waring message, Peter pointed out that there is a
    race condition when the kworker is being frozen and falls into
    try_to_freeze() with TASK_INTERRUPTIBLE, which could trigger a
    might_sleep() warning in try_to_freeze().  Although the root cause is not
    related to freeze()[1], it is still worthy to fix this issue ahead.
    
    One possible race scenario:
    
            CPU 0                                           CPU 1
            -----                                           -----
    
            // kthread_worker_fn
            set_current_state(TASK_INTERRUPTIBLE);
                                                           suspend_freeze_processes()
                                                             freeze_processes
                                                               static_branch_inc(&freezer_active);
                                                             freeze_kernel_threads
                                                               pm_nosig_freezing = true;
            if (work) { //false
              __set_current_state(TASK_RUNNING);
    
            } else if (!freezing(current)) //false, been frozen
    
                          freezing():
                          if (static_branch_unlikely(&freezer_active))
                            if (pm_nosig_freezing)
                              return true;
              schedule()
            }
    
            // state is still TASK_INTERRUPTIBLE
            try_to_freeze()
              might_sleep() <--- warning
    
    Fix this by explicitly set the TASK_RUNNING before entering
    try_to_freeze().
    
    Link: https://lore.kernel.org/lkml/Zs2ZoAcUsZMX2B%2FI@chenyu5-mobl2/ [1]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: b56c0d8937e6 ("kthread: implement kthread_worker")
    Signed-off-by: Chen Yu <[email protected]>
    Suggested-by: Peter Zijlstra <[email protected]>
    Suggested-by: Andrew Morton <[email protected]>
    Cc: Andreas Gruenbacher <[email protected]>
    Cc: David Gow <[email protected]>
    Cc: Mateusz Guzik <[email protected]>
    Cc: Mickaël Salaün <[email protected]>
    Cc: Tejun Heo <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin() [+ + +]
Author: Breno Leitao <[email protected]>
Date:   Fri May 10 02:23:52 2024 -0700

    KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
    
    commit 49f683b41f28918df3e51ddc0d928cb2e934ccdb upstream.
    
    Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the
    loads and stores are atomic.  In the extremely unlikely scenario the
    compiler tears the stores, it's theoretically possible for KVM to attempt
    to get a vCPU using an out-of-bounds index, e.g. if the write is split
    into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
    257 vCPUs:
    
      CPU0                              CPU1
      last_boosted_vcpu = 0xff;
    
                                        (last_boosted_vcpu = 0x100)
                                        last_boosted_vcpu[15:8] = 0x01;
      i = (last_boosted_vcpu = 0x1ff)
                                        last_boosted_vcpu[7:0] = 0x00;
    
      vcpu = kvm->vcpu_array[0x1ff];
    
    As detected by KCSAN:
    
      BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]
    
      write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
      kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
      handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
      vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
                     arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
      vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
      kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
      kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
      __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
      __x64_sys_ioctl (fs/ioctl.c:890)
      x64_sys_call (arch/x86/entry/syscall_64.c:33)
      do_syscall_64 (arch/x86/entry/common.c:?)
      entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
      read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:
      kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm
      handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
      vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
                            arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
      vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
      kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
      kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
      __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
      __x64_sys_ioctl (fs/ioctl.c:890)
      x64_sys_call (arch/x86/entry/syscall_64.c:33)
      do_syscall_64 (arch/x86/entry/common.c:?)
      entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
      value changed: 0x00000012 -> 0x00000000
    
    Fixes: 217ece6129f2 ("KVM: use yield_to instead of sleep in kvm_vcpu_on_spin")
    Cc: [email protected]
    Signed-off-by: Breno Leitao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Saeed Mirzamohammadi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: s390: Change virtual to physical address access in diag 0x258 handler [+ + +]
Author: Michael Mueller <[email protected]>
Date:   Tue Sep 17 17:18:34 2024 +0200

    KVM: s390: Change virtual to physical address access in diag 0x258 handler
    
    commit cad4b3d4ab1f062708fff33f44d246853f51e966 upstream.
    
    The parameters for the diag 0x258 are real addresses, not virtual, but
    KVM was using them as virtual addresses. This only happened to work, since
    the Linux kernel as a guest used to have a 1:1 mapping for physical vs
    virtual addresses.
    
    Fix KVM so that it correctly uses the addresses as real addresses.
    
    Cc: [email protected]
    Fixes: 8ae04b8f500b ("KVM: s390: Guest's memory access functions get access registers")
    Suggested-by: Vasily Gorbik <[email protected]>
    Signed-off-by: Michael Mueller <[email protected]>
    Signed-off-by: Nico Boehr <[email protected]>
    Reviewed-by: Christian Borntraeger <[email protected]>
    Reviewed-by: Heiko Carstens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Janosch Frank <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: s390: gaccess: Check if guest address is in memslot [+ + +]
Author: Nico Boehr <[email protected]>
Date:   Tue Sep 17 17:18:33 2024 +0200

    KVM: s390: gaccess: Check if guest address is in memslot
    
    [ Upstream commit e8061f06185be0a06a73760d6526b8b0feadfe52 ]
    
    Previously, access_guest_page() did not check whether the given guest
    address is inside of a memslot. This is not a problem, since
    kvm_write_guest_page/kvm_read_guest_page return -EFAULT in this case.
    
    However, -EFAULT is also returned when copy_to/from_user fails.
    
    When emulating a guest instruction, the address being outside a memslot
    usually means that an addressing exception should be injected into the
    guest.
    
    Failure in copy_to/from_user however indicates that something is wrong
    in userspace and hence should be handled there.
    
    To be able to distinguish these two cases, return PGM_ADDRESSING in
    access_guest_page() when the guest address is outside guest memory. In
    access_guest_real(), populate vcpu->arch.pgm.code such that
    kvm_s390_inject_prog_cond() can be used in the caller for injecting into
    the guest (if applicable).
    
    Since this adds a new return value to access_guest_page(), we need to make
    sure that other callers are not confused by the new positive return value.
    
    There are the following users of access_guest_page():
    - access_guest_with_key() does the checking itself (in
      guest_range_to_gpas()), so this case should never happen. Even if, the
      handling is set up properly.
    - access_guest_real() just passes the return code to its callers, which
      are:
        - read_guest_real() - see below
        - write_guest_real() - see below
    
    There are the following users of read_guest_real():
    - ar_translation() in gaccess.c which already returns PGM_*
    - setup_apcb10(), setup_apcb00(), setup_apcb11() in vsie.c which always
      return -EFAULT on read_guest_read() nonzero return - no change
    - shadow_crycb(), handle_stfle() always present this as validity, this
      could be handled better but doesn't change current behaviour - no change
    
    There are the following users of write_guest_real():
    - kvm_s390_store_status_unloaded() always returns -EFAULT on
      write_guest_real() failure.
    
    Fixes: 2293897805c2 ("KVM: s390: add architecture compliant guest access functions")
    Cc: [email protected]
    Signed-off-by: Nico Boehr <[email protected]>
    Reviewed-by: Heiko Carstens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Janosch Frank <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

KVM: s390: gaccess: Cleanup access to guest pages [+ + +]
Author: Janis Schoetterl-Glausch <[email protected]>
Date:   Fri Nov 26 17:45:49 2021 +0100

    KVM: s390: gaccess: Cleanup access to guest pages
    
    [ Upstream commit bad13799e0305deb258372b7298a86be4c78aaba ]
    
    Introduce a helper function for guest frame access.
    
    Signed-off-by: Janis Schoetterl-Glausch <[email protected]>
    Reviewed-by: Janosch Frank <[email protected]>
    Reviewed-by: David Hildenbrand <[email protected]>
    Reviewed-by: Claudio Imbrenda <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Janosch Frank <[email protected]>
    Stable-dep-of: e8061f06185b ("KVM: s390: gaccess: Check if guest address is in memslot")
    Signed-off-by: Sasha Levin <[email protected]>

KVM: s390: gaccess: Refactor access address range check [+ + +]
Author: Janis Schoetterl-Glausch <[email protected]>
Date:   Fri Nov 26 17:45:48 2021 +0100

    KVM: s390: gaccess: Refactor access address range check
    
    [ Upstream commit 7faa543df19bf62d4583a64d3902705747f2ad29 ]
    
    Do not round down the first address to the page boundary, just translate
    it normally, which gives the value we care about in the first place.
    Given this, translating a single address is just the special case of
    translating a range spanning a single page.
    
    Make the output optional, so the function can be used to just check a
    range.
    
    Signed-off-by: Janis Schoetterl-Glausch <[email protected]>
    Reviewed-by: Janosch Frank <[email protected]>
    Reviewed-by: Claudio Imbrenda <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Janosch Frank <[email protected]>
    Stable-dep-of: e8061f06185b ("KVM: s390: gaccess: Check if guest address is in memslot")
    Signed-off-by: Sasha Levin <[email protected]>

KVM: s390: gaccess: Refactor gpa and length calculation [+ + +]
Author: Janis Schoetterl-Glausch <[email protected]>
Date:   Fri Nov 26 17:45:47 2021 +0100

    KVM: s390: gaccess: Refactor gpa and length calculation
    
    [ Upstream commit 416e7f0c9d613bf84e182eba9547ae8f9f5bfa4c ]
    
    Improve readability by renaming the length variable and
    not calculating the offset manually.
    
    Signed-off-by: Janis Schoetterl-Glausch <[email protected]>
    Reviewed-by: Janosch Frank <[email protected]>
    Reviewed-by: David Hildenbrand <[email protected]>
    Reviewed-by: Claudio Imbrenda <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Janosch Frank <[email protected]>
    Stable-dep-of: e8061f06185b ("KVM: s390: gaccess: Check if guest address is in memslot")
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 5.4.285 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Nov 8 16:20:54 2024 +0100

    Linux 5.4.285
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Shuah Khan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: kernelci.org bot <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
lockdep: fix deadlock issue between lockdep and rcu [+ + +]
Author: Zhiguo Niu <[email protected]>
Date:   Sat Oct 12 23:22:44 2024 +0000

    lockdep: fix deadlock issue between lockdep and rcu
    
    commit a6f88ac32c6e63e69c595bfae220d8641704c9b7 upstream.
    
    There is a deadlock scenario between lockdep and rcu when
    rcu nocb feature is enabled, just as following call stack:
    
         rcuop/x
    -000|queued_spin_lock_slowpath(lock = 0xFFFFFF817F2A8A80, val = ?)
    -001|queued_spin_lock(inline) // try to hold nocb_gp_lock
    -001|do_raw_spin_lock(lock = 0xFFFFFF817F2A8A80)
    -002|__raw_spin_lock_irqsave(inline)
    -002|_raw_spin_lock_irqsave(lock = 0xFFFFFF817F2A8A80)
    -003|wake_nocb_gp_defer(inline)
    -003|__call_rcu_nocb_wake(rdp = 0xFFFFFF817F30B680)
    -004|__call_rcu_common(inline)
    -004|call_rcu(head = 0xFFFFFFC082EECC28, func = ?)
    -005|call_rcu_zapped(inline)
    -005|free_zapped_rcu(ch = ?)// hold graph lock
    -006|rcu_do_batch(rdp = 0xFFFFFF817F245680)
    -007|nocb_cb_wait(inline)
    -007|rcu_nocb_cb_kthread(arg = 0xFFFFFF817F245680)
    -008|kthread(_create = 0xFFFFFF80803122C0)
    -009|ret_from_fork(asm)
    
         rcuop/y
    -000|queued_spin_lock_slowpath(lock = 0xFFFFFFC08291BBC8, val = 0)
    -001|queued_spin_lock()
    -001|lockdep_lock()
    -001|graph_lock() // try to hold graph lock
    -002|lookup_chain_cache_add()
    -002|validate_chain()
    -003|lock_acquire
    -004|_raw_spin_lock_irqsave(lock = 0xFFFFFF817F211D80)
    -005|lock_timer_base(inline)
    -006|mod_timer(inline)
    -006|wake_nocb_gp_defer(inline)// hold nocb_gp_lock
    -006|__call_rcu_nocb_wake(rdp = 0xFFFFFF817F2A8680)
    -007|__call_rcu_common(inline)
    -007|call_rcu(head = 0xFFFFFFC0822E0B58, func = ?)
    -008|call_rcu_hurry(inline)
    -008|rcu_sync_call(inline)
    -008|rcu_sync_func(rhp = 0xFFFFFFC0822E0B58)
    -009|rcu_do_batch(rdp = 0xFFFFFF817F266680)
    -010|nocb_cb_wait(inline)
    -010|rcu_nocb_cb_kthread(arg = 0xFFFFFF817F266680)
    -011|kthread(_create = 0xFFFFFF8080363740)
    -012|ret_from_fork(asm)
    
    rcuop/x and rcuop/y are rcu nocb threads with the same nocb gp thread.
    This patch release the graph lock before lockdep call_rcu.
    
    Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use")
    Cc: [email protected]
    Cc: Boqun Feng <[email protected]>
    Cc: Waiman Long <[email protected]>
    Cc: Carlos Llamas <[email protected]>
    Cc: Bart Van Assche <[email protected]>
    Signed-off-by: Zhiguo Niu <[email protected]>
    Signed-off-by: Xuewen Yan <[email protected]>
    Reviewed-by: Waiman Long <[email protected]>
    Reviewed-by: Carlos Llamas <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Carlos Llamas <[email protected]>
    Acked-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Boqun Feng <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Carlos Llamas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
locking/lockdep: Avoid potential access of invalid memory in lock_class [+ + +]
Author: Waiman Long <[email protected]>
Date:   Sat Oct 12 23:22:43 2024 +0000

    locking/lockdep: Avoid potential access of invalid memory in lock_class
    
    commit 61cc4534b6550997c97a03759ab46b29d44c0017 upstream.
    
    It was found that reading /proc/lockdep after a lockdep splat may
    potentially cause an access to freed memory if lockdep_unregister_key()
    is called after the splat but before access to /proc/lockdep [1]. This
    is due to the fact that graph_lock() call in lockdep_unregister_key()
    fails after the clearing of debug_locks by the splat process.
    
    After lockdep_unregister_key() is called, the lock_name may be freed
    but the corresponding lock_class structure still have a reference to
    it. That invalid memory pointer will then be accessed when /proc/lockdep
    is read by a user and a use-after-free (UAF) error will be reported if
    KASAN is enabled.
    
    To fix this problem, lockdep_unregister_key() is now modified to always
    search for a matching key irrespective of the debug_locks state and
    zap the corresponding lock class if a matching one is found.
    
    [1] https://lore.kernel.org/lkml/[email protected]/
    
    Fixes: 8b39adbee805 ("locking/lockdep: Make lockdep_unregister_key() honor 'debug_locks' again")
    Reported-by: Tetsuo Handa <[email protected]>
    Signed-off-by: Waiman Long <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Carlos Llamas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

locking/lockdep: Fix bad recursion pattern [+ + +]
Author: Peter Zijlstra <[email protected]>
Date:   Sat Oct 12 23:22:41 2024 +0000

    locking/lockdep: Fix bad recursion pattern
    
    commit 10476e6304222ced7df9b3d5fb0a043b3c2a1ad8 upstream.
    
    There were two patterns for lockdep_recursion:
    
    Pattern-A:
            if (current->lockdep_recursion)
                    return
    
            current->lockdep_recursion = 1;
            /* do stuff */
            current->lockdep_recursion = 0;
    
    Pattern-B:
            current->lockdep_recursion++;
            /* do stuff */
            current->lockdep_recursion--;
    
    But a third pattern has emerged:
    
    Pattern-C:
            current->lockdep_recursion = 1;
            /* do stuff */
            current->lockdep_recursion = 0;
    
    And while this isn't broken per-se, it is highly dangerous because it
    doesn't nest properly.
    
    Get rid of all Pattern-C instances and shore up Pattern-A with a
    warning.
    
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Carlos Llamas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

locking/lockdep: Rework lockdep_lock [+ + +]
Author: Peter Zijlstra <[email protected]>
Date:   Sat Oct 12 23:22:42 2024 +0000

    locking/lockdep: Rework lockdep_lock
    
    commit 248efb2158f1e23750728e92ad9db3ab60c14485 upstream.
    
    A few sites want to assert we own the graph_lock/lockdep_lock, provide
    a more conventional lock interface for it with a number of trivial
    debug checks.
    
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Carlos Llamas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mac80211: Add support to trigger sta disconnect on hardware restart [+ + +]
Author: Youghandhar Chintala <[email protected]>
Date:   Tue Mar 8 17:23:24 2022 +0530

    mac80211: Add support to trigger sta disconnect on hardware restart
    
    [ Upstream commit 7d352ccf1e9935b5222ca84e8baeb07a0c8f94b9 ]
    
    Currently in case of target hardware restart, we just reconfig and
    re-enable the security keys and enable the network queues to start
    data traffic back from where it was interrupted.
    
    Many ath10k wifi chipsets have sequence numbers for the data
    packets assigned by firmware and the mac sequence number will
    restart from zero after target hardware restart leading to mismatch
    in the sequence number expected by the remote peer vs the sequence
    number of the frame sent by the target firmware.
    
    This mismatch in sequence number will cause out-of-order packets
    on the remote peer and all the frames sent by the device are dropped
    until we reach the sequence number which was sent before we restarted
    the target hardware
    
    In order to fix this, we trigger a sta disconnect, in case of target
    hw restart. After this there will be a fresh connection and thereby
    avoiding the dropping of frames by remote peer.
    
    The right fix would be to pull the entire data path into the host
    which is not feasible or would need lots of complex changes and
    will still be inefficient.
    
    Tested on ath10k using WCN3990, QCA6174
    
    Signed-off-by: Youghandhar Chintala <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Stable-dep-of: 07a6e3b78a65 ("wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()")
    Signed-off-by: Sasha Levin <[email protected]>

mac80211: always have ieee80211_sta_restart() [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Sat Mar 12 22:19:58 2022 +0100

    mac80211: always have ieee80211_sta_restart()
    
    commit 3fa5a0f5b0d69e31c6476cd81afeca3cc25a4927 upstream.
    
    When CONFIG_PM isn't defined we don't have the function
    ieee80211_sta_restart() compiled in, but we always need
    it now for firmware restart. Move it out of the ifdef.
    
    Fixes: 7d352ccf1e99 ("mac80211: Add support to trigger sta disconnect on hardware restart")
    Link: https://lore.kernel.org/r/20220312221957.1fa96c72db51.I8ecaa5f9402fede0272161e0531ab930b97fba3e@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mac80211: do drv_reconfig_complete() before restarting all [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Mon Nov 29 15:32:40 2021 +0200

    mac80211: do drv_reconfig_complete() before restarting all
    
    [ Upstream commit 13dee10b30c058ee2c58c5da00339cc0d4201aa6 ]
    
    When we reconfigure, the driver might do some things to complete
    the reconfiguration. It's strange and could be broken in some
    cases because we restart other works (e.g. remain-on-channel and
    TX) before this happens, yet only start queues later.
    
    Change this to do the reconfig complete when reconfiguration is
    actually complete, not when we've already started doing other
    things again.
    
    For iwlwifi, this should fix a race where the reconfig can race
    with TX, for ath10k and ath11k that also use this it won't make
    a difference because they just start queues there, and mac80211
    also stopped the queues and will restart them later as before.
    
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Luca Coelho <[email protected]>
    Link: https://lore.kernel.org/r/iwlwifi.20211129152938.cab99f22fe19.Iefe494687f15fd85f77c1b989d1149c8efdfdc36@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Stable-dep-of: 07a6e3b78a65 ("wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()")
    Signed-off-by: Sasha Levin <[email protected]>

mac80211: Fix NULL ptr deref for injected rate info [+ + +]
Author: Mathy Vanhoef <[email protected]>
Date:   Sun May 30 15:32:26 2021 +0200

    mac80211: Fix NULL ptr deref for injected rate info
    
    commit bddc0c411a45d3718ac535a070f349be8eca8d48 upstream.
    
    The commit cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx
    queue") moved the code to validate the radiotap header from
    ieee80211_monitor_start_xmit to ieee80211_parse_tx_radiotap. This made is
    possible to share more code with the new Tx queue selection code for
    injected frames. But at the same time, it now required the call of
    ieee80211_parse_tx_radiotap at the beginning of functions which wanted to
    handle the radiotap header. And this broke the rate parser for radiotap
    header parser.
    
    The radiotap parser for rates is operating most of the time only on the
    data in the actual radiotap header. But for the 802.11a/b/g rates, it must
    also know the selected band from the chandef information. But this
    information is only written to the ieee80211_tx_info at the end of the
    ieee80211_monitor_start_xmit - long after ieee80211_parse_tx_radiotap was
    already called. The info->band information was therefore always 0
    (NL80211_BAND_2GHZ) when the parser code tried to access it.
    
    For a 5GHz only device, injecting a frame with 802.11a rates would cause a
    NULL pointer dereference because local->hw.wiphy->bands[NL80211_BAND_2GHZ]
    would most likely have been NULL when the radiotap parser searched for the
    correct rate index of the driver.
    
    Cc: [email protected]
    Reported-by: Ben Greear <[email protected]>
    Fixes: cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx queue")
    Signed-off-by: Mathy Vanhoef <[email protected]>
    [[email protected]: added commit message]
    Signed-off-by: Sven Eckelmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mac80211: parse radiotap header when selecting Tx queue [+ + +]
Author: Mathy Vanhoef <[email protected]>
Date:   Thu Jul 23 14:01:53 2020 +0400

    mac80211: parse radiotap header when selecting Tx queue
    
    [ Upstream commit cb17ed29a7a5fea8c9bf70e8a05757d71650e025 ]
    
    Already parse the radiotap header in ieee80211_monitor_select_queue.
    In a subsequent commit this will allow us to add a radiotap flag that
    influences the queue on which injected packets will be sent.
    
    This also fixes the incomplete validation of the injected frame in
    ieee80211_monitor_select_queue: currently an out of bounds memory
    access may occur in in the called function ieee80211_select_queue_80211
    if the 802.11 header is too small.
    
    Note that in ieee80211_monitor_start_xmit the radiotap header is parsed
    again, which is necessairy because ieee80211_monitor_select_queue is not
    always called beforehand.
    
    Signed-off-by: Mathy Vanhoef <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Stable-dep-of: 9d301de12da6 ("wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()")
    Signed-off-by: Sasha Levin <[email protected]>

 
macsec: don't increment counters for an unrelated SA [+ + +]
Author: Sabrina Dubroca <[email protected]>
Date:   Fri Oct 11 17:16:37 2024 +0200

    macsec: don't increment counters for an unrelated SA
    
    [ Upstream commit cf58aefb1332db322060cad4a330d5f9292b0f41 ]
    
    On RX, we shouldn't be incrementing the stats for an arbitrary SA in
    case the actual SA hasn't been set up. Those counters are intended to
    track packets for their respective AN when the SA isn't currently
    configured. Due to the way MACsec is implemented, we don't keep
    counters unless the SA is configured, so we can't track those packets,
    and those counters will remain at 0.
    
    The RXSC's stats keeps track of those packets without telling us which
    AN they belonged to. We could add counters for non-existent SAs, and
    then find a way to integrate them in the dump to userspace, but I
    don't think it's worth the effort.
    
    Fixes: 91ec9bd57f35 ("macsec: Fix traffic counters/statistics")
    Reported-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Link: https://patch.msgid.link/f5ac92aaa5b89343232615f4c03f9f95042c6aa0.1728657709.git.sd@queasysnail.net
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mailbox: bcm2835: Fix timeout during suspend mode [+ + +]
Author: Stefan Wahren <[email protected]>
Date:   Wed Aug 21 23:40:44 2024 +0200

    mailbox: bcm2835: Fix timeout during suspend mode
    
    [ Upstream commit dc09f007caed3b2f6a3b6bd7e13777557ae22bfd ]
    
    During noirq suspend phase the Raspberry Pi power driver suffer of
    firmware property timeouts. The reason is that the IRQ of the underlying
    BCM2835 mailbox is disabled and rpi_firmware_property_list() will always
    run into a timeout [1].
    
    Since the VideoCore side isn't consider as a wakeup source, set the
    IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled
    during suspend-resume cycle.
    
    [1]
    PM: late suspend of devices complete after 1.754 msecs
    WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128
     rpi_firmware_property_list+0x204/0x22c
    Firmware transaction 0x00028001 timeout
    Modules linked in:
    CPU: 0 PID: 438 Comm: bash Tainted: G         C         6.9.3-dirty #17
    Hardware name: BCM2835
    Call trace:
    unwind_backtrace from show_stack+0x18/0x1c
    show_stack from dump_stack_lvl+0x34/0x44
    dump_stack_lvl from __warn+0x88/0xec
    __warn from warn_slowpath_fmt+0x7c/0xb0
    warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c
    rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c
    rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0
    rpi_firmware_set_power from _genpd_power_off+0xe4/0x148
    _genpd_power_off from genpd_sync_power_off+0x7c/0x11c
    genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0
    genpd_finish_suspend from dpm_run_callback+0x78/0xd0
    dpm_run_callback from device_suspend_noirq+0xc0/0x238
    device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168
    dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac
    suspend_devices_and_enter from pm_suspend+0x254/0x2e4
    pm_suspend from state_store+0xa8/0xd4
    state_store from kernfs_fop_write_iter+0x154/0x1a0
    kernfs_fop_write_iter from vfs_write+0x12c/0x184
    vfs_write from ksys_write+0x78/0xc0
    ksys_write from ret_fast_syscall+0x0/0x54
    Exception stack(0xcc93dfa8 to 0xcc93dff0)
    [...]
    PM: noirq suspend of devices complete after 3095.584 msecs
    
    Link: https://github.com/raspberrypi/firmware/issues/1894
    Fixes: 0bae6af6d704 ("mailbox: Enable BCM2835 mailbox support")
    Signed-off-by: Stefan Wahren <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: Jassi Brar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mailbox: rockchip: fix a typo in module autoloading [+ + +]
Author: Liao Chen <[email protected]>
Date:   Wed Aug 14 02:51:47 2024 +0000

    mailbox: rockchip: fix a typo in module autoloading
    
    [ Upstream commit e92d87c9c5d769e4cb1dd7c90faa38dddd7e52e3 ]
    
    MODULE_DEVICE_TABLE(of, rockchip_mbox_of_match) could let the module
    properly autoloaded based on the alias from of_device_id table. It
    should be 'rockchip_mbox_of_match' instead of 'rockchp_mbox_of_match',
    just fix it.
    
    Fixes: f70ed3b5dc8b ("mailbox: rockchip: Add Rockchip mailbox driver")
    Signed-off-by: Liao Chen <[email protected]>
    Reviewed-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Jassi Brar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
media: sun4i_csi: Implement link validate for sun4i_csi subdev [+ + +]
Author: Laurent Pinchart <[email protected]>
Date:   Wed Jun 19 02:46:16 2024 +0300

    media: sun4i_csi: Implement link validate for sun4i_csi subdev
    
    commit 2dc5d5d401f5c6cecd97800ffef82e8d17d228f0 upstream.
    
    The sun4i_csi driver doesn't implement link validation for the subdev it
    registers, leaving the link between the subdev and its source
    unvalidated. Fix it, using the v4l2_subdev_link_validate() helper.
    
    Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver")
    Cc: [email protected]
    Signed-off-by: Laurent Pinchart <[email protected]>
    Acked-by: Chen-Yu Tsai <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Acked-by: Sakari Ailus <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Wed Aug 7 09:22:10 2024 +0200

    media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags
    
    commit 599f6899051cb70c4e0aa9fd591b9ee220cb6f14 upstream.
    
    The cec_msg_set_reply_to() helper function never zeroed the
    struct cec_msg flags field, this can cause unexpected behavior
    if flags was uninitialized to begin with.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Fixes: 0dbacebede1e ("[media] cec: move the CEC framework out of staging and to media")
    Cc: <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

media: venus: fix use after free bug in venus_remove due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Tue Jun 18 14:55:59 2024 +0530

    media: venus: fix use after free bug in venus_remove due to race condition
    
    commit c5a85ed88e043474161bbfe54002c89c1cb50ee2 upstream.
    
    in venus_probe, core->work is bound with venus_sys_error_handler, which is
    used to handle error. The code use core->sys_err_done to make sync work.
    The core->work is started in venus_event_notify.
    
    If we call venus_remove, there might be an unfished work. The possible
    sequence is as follows:
    
    CPU0                  CPU1
    
                         |venus_sys_error_handler
    venus_remove         |
    hfi_destroy                      |
    venus_hfi_destroy        |
    kfree(hdev);         |
                         |hfi_reinit
                                             |venus_hfi_queues_reinit
                         |//use hdev
    
    Fix it by canceling the work in venus_remove.
    
    Cc: [email protected]
    Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions")
    Signed-off-by: Zheng Wang <[email protected]>
    Signed-off-by: Dikshita Agarwal <[email protected]>
    Signed-off-by: Stanimir Varbanov <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

media: videobuf2-core: clear memory related fields in __vb2_plane_dmabuf_put() [+ + +]
Author: Yunke Cao <[email protected]>
Date:   Wed Aug 14 11:06:40 2024 +0900

    media: videobuf2-core: clear memory related fields in __vb2_plane_dmabuf_put()
    
    [ Upstream commit 6a9c97ab6b7e85697e0b74e86062192a5ffffd99 ]
    
    Clear vb2_plane's memory related fields in __vb2_plane_dmabuf_put(),
    including bytesused, length, fd and data_offset.
    
    Remove the duplicated code in __prepare_dmabuf().
    
    Signed-off-by: Yunke Cao <[email protected]>
    Acked-by: Tomasz Figa <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
microblaze: don't treat zero reserved memory regions as error [+ + +]
Author: Mike Rapoport <[email protected]>
Date:   Mon Jul 29 08:33:27 2024 +0300

    microblaze: don't treat zero reserved memory regions as error
    
    [ Upstream commit 0075df288dd8a7abfe03b3766176c393063591dd ]
    
    Before commit 721f4a6526da ("mm/memblock: remove empty dummy entry") the
    check for non-zero of memblock.reserved.cnt in mmu_init() would always
    be true either because  memblock.reserved.cnt is initialized to 1 or
    because there were memory reservations earlier.
    
    The removal of dummy empty entry in memblock caused this check to fail
    because now memblock.reserved.cnt is initialized to 0.
    
    Remove the check for non-zero of memblock.reserved.cnt because it's
    perfectly fine to have an empty memblock.reserved array that early in
    boot.
    
    Reported-by: Guenter Roeck <[email protected]>
    Signed-off-by: Mike Rapoport <[email protected]>
    Reviewed-by: Wei Yang <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Minor fixes to the CAIF Transport drivers Kconfig file [+ + +]
Author: [email protected] <[email protected]>
Date:   Tue Oct 1 16:04:01 2019 -0700

    Minor fixes to the CAIF Transport drivers Kconfig file
    
    [ Upstream commit 0f04f8ea62ce79f5a8bb1a7c2d92513799532239 ]
    
    Minor fixes to the CAIF Transport drivers Kconfig file:
    
    - end sentence with period
    - capitalize CAIF acronym
    
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Randy Dunlap <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: addf89774e48 ("ieee802154: Fix build error")
    Signed-off-by: Sasha Levin <[email protected]>

 
misc: sgi-gru: Don't disable preemption in GRU driver [+ + +]
Author: Dimitri Sivanich <[email protected]>
Date:   Thu Sep 19 07:34:50 2024 -0500

    misc: sgi-gru: Don't disable preemption in GRU driver
    
    [ Upstream commit b983b271662bd6104d429b0fd97af3333ba760bf ]
    
    Disabling preemption in the GRU driver is unnecessary, and clashes with
    sleeping locks in several code paths.  Remove preempt_disable and
    preempt_enable from the GRU driver.
    
    Signed-off-by: Dimitri Sivanich <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/swapfile: skip HugeTLB pages for unuse_vma [+ + +]
Author: Liu Shixin <[email protected]>
Date:   Tue Oct 15 09:45:21 2024 +0800

    mm/swapfile: skip HugeTLB pages for unuse_vma
    
    commit 7528c4fb1237512ee18049f852f014eba80bbe8d upstream.
    
    I got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The
    problem can be reproduced by the following steps:
    
     1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.
     2. Swapout the above anonymous memory.
     3. run swapoff and we will get a bad pud error in kernel message:
    
      mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)
    
    We can tell that pud_clear_bad is called by pud_none_or_clear_bad in
    unuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never
    be freed because we lost it from page table.  We can skip HugeTLB pages
    for unuse_vma to fix it.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 0fe6e20b9c4c ("hugetlb, rmap: add reverse mapping for hugepage")
    Signed-off-by: Liu Shixin <[email protected]>
    Acked-by: Muchun Song <[email protected]>
    Cc: Naoya Horiguchi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: krealloc: consider spare memory for __GFP_ZERO [+ + +]
Author: Danilo Krummrich <[email protected]>
Date:   Tue Aug 13 00:34:34 2024 +0200

    mm: krealloc: consider spare memory for __GFP_ZERO
    
    commit 1a83a716ec233990e1fd5b6fbb1200ade63bf450 upstream.
    
    As long as krealloc() is called with __GFP_ZERO consistently, starting
    with the initial memory allocation, __GFP_ZERO should be fully honored.
    
    However, if for an existing allocation krealloc() is called with a
    decreased size, it is not ensured that the spare portion the allocation is
    zeroed.  Thus, if krealloc() is subsequently called with a larger size
    again, __GFP_ZERO can't be fully honored, since we don't know the previous
    size, but only the bucket size.
    
    Example:
    
            buf = kzalloc(64, GFP_KERNEL);
            memset(buf, 0xff, 64);
    
            buf = krealloc(buf, 48, GFP_KERNEL | __GFP_ZERO);
    
            /* After this call the last 16 bytes are still 0xff. */
            buf = krealloc(buf, 64, GFP_KERNEL | __GFP_ZERO);
    
    Fix this, by explicitly setting spare memory to zero, when shrinking an
    allocation with __GFP_ZERO flag set or init_on_alloc enabled.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Danilo Krummrich <[email protected]>
    Acked-by: Vlastimil Babka <[email protected]>
    Acked-by: David Rientjes <[email protected]>
    Cc: Christoph Lameter <[email protected]>
    Cc: Hyeonggon Yoo <[email protected]>
    Cc: Joonsoo Kim <[email protected]>
    Cc: Pekka Enberg <[email protected]>
    Cc: Roman Gushchin <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mm: krealloc: Fix MTE false alarm in __do_krealloc [+ + +]
Author: Qun-Wei Lin <[email protected]>
Date:   Fri Oct 25 16:58:11 2024 +0800

    mm: krealloc: Fix MTE false alarm in __do_krealloc
    
    commit 704573851b51808b45dae2d62059d1d8189138a2 upstream.
    
    This patch addresses an issue introduced by commit 1a83a716ec233 ("mm:
    krealloc: consider spare memory for __GFP_ZERO") which causes MTE
    (Memory Tagging Extension) to falsely report a slab-out-of-bounds error.
    
    The problem occurs when zeroing out spare memory in __do_krealloc. The
    original code only considered software-based KASAN and did not account
    for MTE. It does not reset the KASAN tag before calling memset, leading
    to a mismatch between the pointer tag and the memory tag, resulting
    in a false positive.
    
    Example of the error:
    ==================================================================
    swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188
    swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1
    swapper/0: Pointer tag: [f4], memory tag: [fe]
    swapper/0:
    swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.
    swapper/0: Hardware name: MT6991(ENG) (DT)
    swapper/0: Call trace:
    swapper/0:  dump_backtrace+0xfc/0x17c
    swapper/0:  show_stack+0x18/0x28
    swapper/0:  dump_stack_lvl+0x40/0xa0
    swapper/0:  print_report+0x1b8/0x71c
    swapper/0:  kasan_report+0xec/0x14c
    swapper/0:  __do_kernel_fault+0x60/0x29c
    swapper/0:  do_bad_area+0x30/0xdc
    swapper/0:  do_tag_check_fault+0x20/0x34
    swapper/0:  do_mem_abort+0x58/0x104
    swapper/0:  el1_abort+0x3c/0x5c
    swapper/0:  el1h_64_sync_handler+0x80/0xcc
    swapper/0:  el1h_64_sync+0x68/0x6c
    swapper/0:  __memset+0x84/0x188
    swapper/0:  btf_populate_kfunc_set+0x280/0x3d8
    swapper/0:  __register_btf_kfunc_id_set+0x43c/0x468
    swapper/0:  register_btf_kfunc_id_set+0x48/0x60
    swapper/0:  register_nf_nat_bpf+0x1c/0x40
    swapper/0:  nf_nat_init+0xc0/0x128
    swapper/0:  do_one_initcall+0x184/0x464
    swapper/0:  do_initcall_level+0xdc/0x1b0
    swapper/0:  do_initcalls+0x70/0xc0
    swapper/0:  do_basic_setup+0x1c/0x28
    swapper/0:  kernel_init_freeable+0x144/0x1b8
    swapper/0:  kernel_init+0x20/0x1a8
    swapper/0:  ret_from_fork+0x10/0x20
    ==================================================================
    
    Fixes: 1a83a716ec233 ("mm: krealloc: consider spare memory for __GFP_ZERO")
    Signed-off-by: Qun-Wei Lin <[email protected]>
    Acked-by: David Rientjes <[email protected]>
    Signed-off-by: Vlastimil Babka <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mm: only enforce minimum stack gap size if it's sensible [+ + +]
Author: David Gow <[email protected]>
Date:   Sat Aug 3 15:46:41 2024 +0800

    mm: only enforce minimum stack gap size if it's sensible
    
    commit 69b50d4351ed924f29e3d46b159e28f70dfc707f upstream.
    
    The generic mmap_base code tries to leave a gap between the top of the
    stack and the mmap base address, but enforces a minimum gap size (MIN_GAP)
    of 128MB, which is too large on some setups.  In particular, on arm tasks
    without ADDR_LIMIT_32BIT, the STACK_TOP value is less than 128MB, so it's
    impossible to fit such a gap in.
    
    Only enforce this minimum if MIN_GAP < MAX_GAP, as we'd prefer to honour
    MAX_GAP, which is defined proportionally, so scales better and always
    leaves us with both _some_ stack space and some room for mmap.
    
    This fixes the usercopy KUnit test suite on 32-bit arm, as it doesn't set
    any personality flags so gets the default (in this case 26-bit) task size.
    This test can be run with: ./tools/testing/kunit/kunit.py run --arch arm
    usercopy --make_options LLVM=1
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: dba79c3df4a2 ("arm: use generic mmap top-down layout and brk randomization")
    Signed-off-by: David Gow <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Cc: Alexandre Ghiti <[email protected]>
    Cc: Linus Walleij <[email protected]>
    Cc: Luis Chamberlain <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Russell King <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mm: shmem: fix data-race in shmem_getattr() [+ + +]
Author: Jeongjun Park <[email protected]>
Date:   Mon Sep 9 21:35:58 2024 +0900

    mm: shmem: fix data-race in shmem_getattr()
    
    commit d949d1d14fa281ace388b1de978e8f2cd52875cf upstream.
    
    I got the following KCSAN report during syzbot testing:
    
    ==================================================================
    BUG: KCSAN: data-race in generic_fillattr / inode_set_ctime_current
    
    write to 0xffff888102eb3260 of 4 bytes by task 6565 on cpu 1:
     inode_set_ctime_to_ts include/linux/fs.h:1638 [inline]
     inode_set_ctime_current+0x169/0x1d0 fs/inode.c:2626
     shmem_mknod+0x117/0x180 mm/shmem.c:3443
     shmem_create+0x34/0x40 mm/shmem.c:3497
     lookup_open fs/namei.c:3578 [inline]
     open_last_lookups fs/namei.c:3647 [inline]
     path_openat+0xdbc/0x1f00 fs/namei.c:3883
     do_filp_open+0xf7/0x200 fs/namei.c:3913
     do_sys_openat2+0xab/0x120 fs/open.c:1416
     do_sys_open fs/open.c:1431 [inline]
     __do_sys_openat fs/open.c:1447 [inline]
     __se_sys_openat fs/open.c:1442 [inline]
     __x64_sys_openat+0xf3/0x120 fs/open.c:1442
     x64_sys_call+0x1025/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:258
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    read to 0xffff888102eb3260 of 4 bytes by task 3498 on cpu 0:
     inode_get_ctime_nsec include/linux/fs.h:1623 [inline]
     inode_get_ctime include/linux/fs.h:1629 [inline]
     generic_fillattr+0x1dd/0x2f0 fs/stat.c:62
     shmem_getattr+0x17b/0x200 mm/shmem.c:1157
     vfs_getattr_nosec fs/stat.c:166 [inline]
     vfs_getattr+0x19b/0x1e0 fs/stat.c:207
     vfs_statx_path fs/stat.c:251 [inline]
     vfs_statx+0x134/0x2f0 fs/stat.c:315
     vfs_fstatat+0xec/0x110 fs/stat.c:341
     __do_sys_newfstatat fs/stat.c:505 [inline]
     __se_sys_newfstatat+0x58/0x260 fs/stat.c:499
     __x64_sys_newfstatat+0x55/0x70 fs/stat.c:499
     x64_sys_call+0x141f/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:263
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    value changed: 0x2755ae53 -> 0x27ee44d3
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 UID: 0 PID: 3498 Comm: udevd Not tainted 6.11.0-rc6-syzkaller-00326-gd1f2d51b711a-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
    ==================================================================
    
    When calling generic_fillattr(), if you don't hold read lock, data-race
    will occur in inode member variables, which can cause unexpected
    behavior.
    
    Since there is no special protection when shmem_getattr() calls
    generic_fillattr(), data-race occurs by functions such as shmem_unlink()
    or shmem_mknod(). This can cause unexpected results, so commenting it out
    is not enough.
    
    Therefore, when calling generic_fillattr() from shmem_getattr(), it is
    appropriate to protect the inode using inode_lock_shared() and
    inode_unlock_shared() to prevent data-race.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 44a30220bc0a ("shmem: recalculate file inode when fstat")
    Signed-off-by: Jeongjun Park <[email protected]>
    Reported-by: syzbot <[email protected]>
    Cc: Hugh Dickins <[email protected]>
    Cc: Yu Zhao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mount: handle OOM on mnt_warn_timestamp_expiry [+ + +]
Author: Olaf Hering <[email protected]>
Date:   Tue Jul 30 10:58:13 2024 +0200

    mount: handle OOM on mnt_warn_timestamp_expiry
    
    [ Upstream commit 4bcda1eaf184e308f07f9c61d3a535f9ce477ce8 ]
    
    If no page could be allocated, an error pointer was used as format
    string in pr_warn.
    
    Rearrange the code to return early in case of OOM. Also add a check
    for the return value of d_path.
    
    Fixes: f8b92ba67c5d ("mount: Add mount warning for impending timestamp expiry")
    Signed-off-by: Olaf Hering <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [brauner: rewrite commit and commit message]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mount: warn only once about timestamp range expiration [+ + +]
Author: Anthony Iliopoulos <[email protected]>
Date:   Tue Mar 22 14:39:22 2022 -0700

    mount: warn only once about timestamp range expiration
    
    [ Upstream commit a128b054ce029554a4a52fc3abb8c1df8bafcaef ]
    
    Commit f8b92ba67c5d ("mount: Add mount warning for impending timestamp
    expiry") introduced a mount warning regarding filesystem timestamp
    limits, that is printed upon each writable mount or remount.
    
    This can result in a lot of unnecessary messages in the kernel log in
    setups where filesystems are being frequently remounted (or mounted
    multiple times).
    
    Avoid this by setting a superblock flag which indicates that the warning
    has been emitted at least once for any particular mount, as suggested in
    [1].
    
    Link: https://lore.kernel.org/CAHk-=wim6VGnxQmjfK_tDg6fbHYKL4EFkmnTjVr9QnRqjDBAeA@mail.gmail.com/ [1]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Anthony Iliopoulos <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Reviewed-by: Darrick J. Wong <[email protected]>
    Cc: Alexander Viro <[email protected]>
    Cc: Deepa Dinamani <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Stable-dep-of: 4bcda1eaf184 ("mount: handle OOM on mnt_warn_timestamp_expiry")
    Signed-off-by: Sasha Levin <[email protected]>

 
mtd: powernv: Add check devm_kasprintf() returned value [+ + +]
Author: Charles Han <[email protected]>
Date:   Wed Aug 28 17:24:27 2024 +0800

    mtd: powernv: Add check devm_kasprintf() returned value
    
    [ Upstream commit 395999829880a106bb95f0ce34e6e4c2b43c6a5d ]
    
    devm_kasprintf() can return a NULL pointer on failure but this
    returned value is not checked.
    
    Fixes: acfe63ec1c59 ("mtd: Convert to using %pOFn instead of device_node.name")
    Signed-off-by: Charles Han <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

mtd: slram: insert break after errors in parsing the map [+ + +]
Author: Mirsad Todorovac <[email protected]>
Date:   Fri Jul 12 01:43:20 2024 +0200

    mtd: slram: insert break after errors in parsing the map
    
    [ Upstream commit 336c218dd7f0588ed8a7345f367975a00a4f003f ]
    
    GCC 12.3.0 compiler on linux-next next-20240709 tree found the execution
    path in which, due to lazy evaluation, devlength isn't initialised with the
    parsed string:
    
       289          while (map) {
       290                  devname = devstart = devlength = NULL;
       291
       292                  if (!(devname = strsep(&map, ","))) {
       293                          E("slram: No devicename specified.\n");
       294                          break;
       295                  }
       296                  T("slram: devname = %s\n", devname);
       297                  if ((!map) || (!(devstart = strsep(&map, ",")))) {
       298                          E("slram: No devicestart specified.\n");
       299                  }
       300                  T("slram: devstart = %s\n", devstart);
     → 301                  if ((!map) || (!(devlength = strsep(&map, ",")))) {
       302                          E("slram: No devicelength / -end specified.\n");
       303                  }
     → 304                  T("slram: devlength = %s\n", devlength);
       305                  if (parse_cmdline(devname, devstart, devlength) != 0) {
       306                          return(-EINVAL);
       307                  }
    
    Parsing should be finished after map == NULL, so a break is best inserted after
    each E("slram: ... \n") error message.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: Miquel Raynal <[email protected]>
    Cc: Richard Weinberger <[email protected]>
    Cc: Vignesh Raghavendra <[email protected]>
    Cc: [email protected]
    Signed-off-by: Mirsad Todorovac <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
net/mlx5: Added cond_resched() to crdump collection [+ + +]
Author: Mohamed Khalfella <[email protected]>
Date:   Wed Sep 4 22:02:48 2024 -0600

    net/mlx5: Added cond_resched() to crdump collection
    
    [ Upstream commit ec793155894140df7421d25903de2e6bc12c695b ]
    
    Collecting crdump involves reading vsc registers from pci config space
    of mlx device, which can take long time to complete. This might result
    in starving other threads waiting to run on the cpu.
    
    Numbers I got from testing ConnectX-5 Ex MCX516A-CDAT in the lab:
    
    - mlx5_vsc_gw_read_block_fast() was called with length = 1310716.
    - mlx5_vsc_gw_read_fast() reads 4 bytes at a time. It was not used to
      read the entire 1310716 bytes. It was called 53813 times because
      there are jumps in read_addr.
    - On average mlx5_vsc_gw_read_fast() took 35284.4ns.
    - In total mlx5_vsc_wait_on_flag() called vsc_read() 54707 times.
      The average time for each call was 17548.3ns. In some instances
      vsc_read() was called more than one time when the flag was not set.
      As expected the thread released the cpu after 16 iterations in
      mlx5_vsc_wait_on_flag().
    - Total time to read crdump was 35284.4ns * 53813 ~= 1.898s.
    
    It was seen in the field that crdump can take more than 5 seconds to
    complete. During that time mlx5_vsc_wait_on_flag() did not release the
    cpu because it did not complete 16 iterations. It is believed that pci
    config reads were slow. Adding cond_resched() every 128 register read
    improves the situation. In the common case the, crdump takes ~1.8989s,
    the thread yields the cpu every ~4.51ms. If crdump takes ~5s, the thread
    yields the cpu every ~18.0ms.
    
    Fixes: 8b9d8baae1de ("net/mlx5: Add Crdump support")
    Reviewed-by: Yuanyuan Zhong <[email protected]>
    Signed-off-by: Mohamed Khalfella <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/mlx5e: Add missing link modes to ptys2ethtool_map [+ + +]
Author: Shahar Shitrit <[email protected]>
Date:   Sun Aug 11 13:56:13 2024 +0300

    net/mlx5e: Add missing link modes to ptys2ethtool_map
    
    [ Upstream commit 7617d62cba4a8a3ff3ed3fda0171c43f135c142e ]
    
    Add MLX5E_1000BASE_T and MLX5E_100BASE_TX to the legacy
    modes in ptys2legacy_ethtool_table, since they were missing.
    
    Fixes: 665bc53969d7 ("net/mlx5e: Use new ethtool get/set link ksettings API")
    Signed-off-by: Shahar Shitrit <[email protected]>
    Reviewed-by: Tariq Toukan <[email protected]>
    Reviewed-by: Carolina Jubran <[email protected]>
    Signed-off-by: Saeed Mahameed <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/sched: accept TCA_STAB only for root qdisc [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon Oct 7 18:41:30 2024 +0000

    net/sched: accept TCA_STAB only for root qdisc
    
    [ Upstream commit 3cb7cf1540ddff5473d6baeb530228d19bc97b8a ]
    
    Most qdiscs maintain their backlog using qdisc_pkt_len(skb)
    on the assumption it is invariant between the enqueue()
    and dequeue() handlers.
    
    Unfortunately syzbot can crash a host rather easily using
    a TBF + SFQ combination, with an STAB on SFQ [1]
    
    We can't support TCA_STAB on arbitrary level, this would
    require to maintain per-qdisc storage.
    
    [1]
    [   88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000
    [   88.798611] #PF: supervisor read access in kernel mode
    [   88.799014] #PF: error_code(0x0000) - not-present page
    [   88.799506] PGD 0 P4D 0
    [   88.799829] Oops: Oops: 0000 [#1] SMP NOPTI
    [   88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117
    [   88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    [   88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq
    [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00
    All code
    ========
       0:   0f b7 50 12             movzwl 0x12(%rax),%edx
       4:   48 8d 04 d5 00 00 00    lea    0x0(,%rdx,8),%rax
       b:   00
       c:   48 89 d6                mov    %rdx,%rsi
       f:   48 29 d0                sub    %rdx,%rax
      12:   48 8b 91 c0 01 00 00    mov    0x1c0(%rcx),%rdx
      19:   48 c1 e0 03             shl    $0x3,%rax
      1d:   48 01 c2                add    %rax,%rdx
      20:   66 83 7a 1a 00          cmpw   $0x0,0x1a(%rdx)
      25:   7e c0                   jle    0xffffffffffffffe7
      27:   48 8b 3a                mov    (%rdx),%rdi
      2a:*  4c 8b 07                mov    (%rdi),%r8               <-- trapping instruction
      2d:   4c 89 02                mov    %r8,(%rdx)
      30:   49 89 50 08             mov    %rdx,0x8(%r8)
      34:   48 c7 47 08 00 00 00    movq   $0x0,0x8(%rdi)
      3b:   00
      3c:   48                      rex.W
      3d:   c7                      .byte 0xc7
      3e:   07                      (bad)
            ...
    
    Code starting with the faulting instruction
    ===========================================
       0:   4c 8b 07                mov    (%rdi),%r8
       3:   4c 89 02                mov    %r8,(%rdx)
       6:   49 89 50 08             mov    %rdx,0x8(%r8)
       a:   48 c7 47 08 00 00 00    movq   $0x0,0x8(%rdi)
      11:   00
      12:   48                      rex.W
      13:   c7                      .byte 0xc7
      14:   07                      (bad)
            ...
    [   88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206
    [   88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800
    [   88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000
    [   88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f
    [   88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140
    [   88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac
    [   88.806734] FS:  00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000
    [   88.807225] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0
    [   88.808165] Call Trace:
    [   88.808459]  <TASK>
    [   88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)
    [   88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)
    [   88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)
    [   88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
    [   88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq
    [   88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq
    [   88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_generic.c:1036)
    [   88.810950] tbf_reset (./include/linux/timekeeping.h:169 net/sched/sch_tbf.c:334) sch_tbf
    [   88.811208] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_generic.c:1036)
    [   88.811484] netif_set_real_num_tx_queues (./include/linux/spinlock.h:396 ./include/net/sch_generic.h:768 net/core/dev.c:2958)
    [   88.811870] __tun_detach (drivers/net/tun.c:590 drivers/net/tun.c:673)
    [   88.812271] tun_chr_close (drivers/net/tun.c:702 drivers/net/tun.c:3517)
    [   88.812505] __fput (fs/file_table.c:432 (discriminator 1))
    [   88.812735] task_work_run (kernel/task_work.c:230)
    [   88.813016] do_exit (kernel/exit.c:940)
    [   88.813372] ? trace_hardirqs_on (kernel/trace/trace_preemptirq.c:58 (discriminator 4))
    [   88.813639] ? handle_mm_fault (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/memcontrol.h:1022 ./include/linux/memcontrol.h:1045 ./include/linux/memcontrol.h:1052 mm/memory.c:5928 mm/memory.c:6088)
    [   88.813867] do_group_exit (kernel/exit.c:1070)
    [   88.814138] __x64_sys_exit_group (kernel/exit.c:1099)
    [   88.814490] x64_sys_call (??:?)
    [   88.814791] do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
    [   88.815012] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    [   88.815495] RIP: 0033:0x7f44560f1975
    
    Fixes: 175f9c1bba9b ("net_sched: Add size table for qdiscs")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Daniel Borkmann <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT [+ + +]
Author: Pedro Tammela <[email protected]>
Date:   Thu Oct 24 12:55:47 2024 -0400

    net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT
    
    [ Upstream commit 2e95c4384438adeaa772caa560244b1a2efef816 ]
    
    In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed
    to be either root or ingress. This assumption is bogus since it's valid
    to create egress qdiscs with major handle ffff:
    Budimir Markovic found that for qdiscs like DRR that maintain an active
    class list, it will cause a UAF with a dangling class pointer.
    
    In 066a3b5b2346, the concern was to avoid iterating over the ingress
    qdisc since its parent is itself. The proper fix is to stop when parent
    TC_H_ROOT is reached because the only way to retrieve ingress is when a
    hierarchy which does not contain a ffff: major handle call into
    qdisc_lookup with TC_H_MAJ(TC_H_ROOT).
    
    In the scenario where major ffff: is an egress qdisc in any of the tree
    levels, the updates will also propagate to TC_H_ROOT, which then the
    iteration must stop.
    
    Fixes: 066a3b5b2346 ("[NET_SCHED] sch_api: fix qdisc_tree_decrease_qlen() loop")
    Reported-by: Budimir Markovic <[email protected]>
    Suggested-by: Jamal Hadi Salim <[email protected]>
    Tested-by: Victor Nogueira <[email protected]>
    Signed-off-by: Pedro Tammela <[email protected]>
    Signed-off-by: Jamal Hadi Salim <[email protected]>
    
     net/sched/sch_api.c | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    Reviewed-by: Simon Horman <[email protected]>
    
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() [+ + +]
Author: Wang Hai <[email protected]>
Date:   Tue Oct 15 22:41:48 2024 +0800

    net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()
    
    [ Upstream commit 2cb3f56e827abb22c4168ad0c1bbbf401bb2f3b8 ]
    
    The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb
    in case of skb->len being too long, add dev_kfree_skb() to fix it.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Wang Hai <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Andrew Lunn <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: add more sanity checks to qdisc_pkt_len_init() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Sep 24 15:02:57 2024 +0000

    net: add more sanity checks to qdisc_pkt_len_init()
    
    [ Upstream commit ab9a9a9e9647392a19e7a885b08000e89c86b535 ]
    
    One path takes care of SKB_GSO_DODGY, assuming
    skb->len is bigger than hdr_len.
    
    virtio_net_hdr_to_skb() does not fully dissect TCP headers,
    it only make sure it is at least 20 bytes.
    
    It is possible for an user to provide a malicious 'GSO' packet,
    total length of 80 bytes.
    
    - 20 bytes of IPv4 header
    - 60 bytes TCP header
    - a small gso_size like 8
    
    virtio_net_hdr_to_skb() would declare this packet as a normal
    GSO packet, because it would see 40 bytes of payload,
    bigger than gso_size.
    
    We need to make detect this case to not underflow
    qdisc_skb_cb(skb)->pkt_len.
    
    Fixes: 1def9238d4aa ("net_sched: more precise pkt_len computation")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: amd: mvme147: Fix probe banner message [+ + +]
Author: Daniel Palmer <[email protected]>
Date:   Mon Oct 7 19:43:17 2024 +0900

    net: amd: mvme147: Fix probe banner message
    
    [ Upstream commit 82c5b53140faf89c31ea2b3a0985a2f291694169 ]
    
    Currently this driver prints this line with what looks like
    a rogue format specifier when the device is probed:
    [    2.840000] eth%d: MVME147 at 0xfffe1800, irq 12, Hardware Address xx:xx:xx:xx:xx:xx
    
    Change the printk() for netdev_info() and move it after the
    registration has completed so it prints out the name of the
    interface properly.
    
    Signed-off-by: Daniel Palmer <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: annotate lockless accesses to sk->sk_ack_backlog [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Nov 5 14:11:53 2019 -0800

    net: annotate lockless accesses to sk->sk_ack_backlog
    
    [ Upstream commit 288efe8606b62d0753ba6722b36ef241877251fd ]
    
    sk->sk_ack_backlog can be read without any lock being held.
    We need to use READ_ONCE()/WRITE_ONCE() to avoid load/store tearing
    and/or potential KCSAN warnings.
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 4d5c70e6155d ("sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start")
    Signed-off-by: Sasha Levin <[email protected]>

net: annotate lockless accesses to sk->sk_max_ack_backlog [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Nov 5 14:11:54 2019 -0800

    net: annotate lockless accesses to sk->sk_max_ack_backlog
    
    [ Upstream commit 099ecf59f05b5f30f42ebac0ab8cb94f9b18c90c ]
    
    sk->sk_max_ack_backlog can be read without any lock being held
    at least in TCP/DCCP cases.
    
    We need to use READ_ONCE()/WRITE_ONCE() to avoid load/store tearing
    and/or potential KCSAN warnings.
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 4d5c70e6155d ("sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start")
    Signed-off-by: Sasha Levin <[email protected]>

net: avoid potential underflow in qdisc_pkt_len_init() with UFO [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Sep 24 15:02:56 2024 +0000

    net: avoid potential underflow in qdisc_pkt_len_init() with UFO
    
    [ Upstream commit c20029db28399ecc50e556964eaba75c43b1e2f1 ]
    
    After commit 7c6d2ecbda83 ("net: be more gentle about silly gso
    requests coming from user") virtio_net_hdr_to_skb() had sanity check
    to detect malicious attempts from user space to cook a bad GSO packet.
    
    Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count
    transport header in UFO") while fixing one issue, allowed user space
    to cook a GSO packet with the following characteristic :
    
    IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.
    
    When this packet arrives in qdisc_pkt_len_init(), we end up
    with hdr_len = 28 (IPv4 header + UDP header), matching skb->len
    
    Then the following sets gso_segs to 0 :
    
    gso_segs = DIV_ROUND_UP(skb->len - hdr_len,
                            shinfo->gso_size);
    
    Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/
    
    qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;
    
    This leads to the following crash in fq_codel [1]
    
    qdisc_pkt_len_init() is best effort, we only want an estimation
    of the bytes sent on the wire, not crashing the kernel.
    
    This patch is fixing this particular issue, a following one
    adds more sanity checks for another potential bug.
    
    [1]
    [   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
    [   70.724561] #PF: supervisor read access in kernel mode
    [   70.724561] #PF: error_code(0x0000) - not-present page
    [   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
    [   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI
    [   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991
    [   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    [   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel
    [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49
    All code
    ========
       0:   24 08                   and    $0x8,%al
       2:   49 c1 e1 06             shl    $0x6,%r9
       6:   44 89 7c 24 18          mov    %r15d,0x18(%rsp)
       b:   45 31 ed                xor    %r13d,%r13d
       e:   45 31 c0                xor    %r8d,%r8d
      11:   31 ff                   xor    %edi,%edi
      13:   89 44 24 14             mov    %eax,0x14(%rsp)
      17:   4c 03 8b 90 01 00 00    add    0x190(%rbx),%r9
      1e:   eb 04                   jmp    0x24
      20:   39 ca                   cmp    %ecx,%edx
      22:   73 37                   jae    0x5b
      24:   4d 8b 39                mov    (%r9),%r15
      27:   83 c7 01                add    $0x1,%edi
      2a:*  49 8b 17                mov    (%r15),%rdx              <-- trapping instruction
      2d:   49 89 11                mov    %rdx,(%r9)
      30:   41 8b 57 28             mov    0x28(%r15),%edx
      34:   45 8b 5f 34             mov    0x34(%r15),%r11d
      38:   49 c7 07 00 00 00 00    movq   $0x0,(%r15)
      3f:   49                      rex.WB
    
    Code starting with the faulting instruction
    ===========================================
       0:   49 8b 17                mov    (%r15),%rdx
       3:   49 89 11                mov    %rdx,(%r9)
       6:   41 8b 57 28             mov    0x28(%r15),%edx
       a:   45 8b 5f 34             mov    0x34(%r15),%r11d
       e:   49 c7 07 00 00 00 00    movq   $0x0,(%r15)
      15:   49                      rex.WB
    [   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202
    [   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000
    [   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
    [   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000
    [   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58
    [   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000
    [   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000
    [   70.724561] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   70.724561] CR2: 0000000000000000 CR3: 000000010c568000 CR4: 00000000000006f0
    [   70.724561] Call Trace:
    [   70.724561]  <TASK>
    [   70.724561] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)
    [   70.724561] ? page_fault_oops (arch/x86/mm/fault.c:715)
    [   70.724561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)
    [   70.724561] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
    [   70.724561] ? fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel
    [   70.724561] dev_qdisc_enqueue (net/core/dev.c:3784)
    [   70.724561] __dev_queue_xmit (net/core/dev.c:3880 (discriminator 2) net/core/dev.c:4390 (discriminator 2))
    [   70.724561] ? irqentry_enter (kernel/entry/common.c:237)
    [   70.724561] ? sysvec_apic_timer_interrupt (./arch/x86/include/asm/hardirq.h:74 (discriminator 2) arch/x86/kernel/apic/apic.c:1043 (discriminator 2) arch/x86/kernel/apic/apic.c:1043 (discriminator 2))
    [   70.724561] ? trace_hardirqs_on (kernel/trace/trace_preemptirq.c:58 (discriminator 4))
    [   70.724561] ? asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)
    [   70.724561] ? virtio_net_hdr_to_skb.constprop.0 (./include/linux/virtio_net.h:129 (discriminator 1))
    [   70.724561] packet_sendmsg (net/packet/af_packet.c:3145 (discriminator 1) net/packet/af_packet.c:3177 (discriminator 1))
    [   70.724561] ? _raw_spin_lock_bh (./arch/x86/include/asm/atomic.h:107 (discriminator 4) ./include/linux/atomic/atomic-arch-fallback.h:2170 (discriminator 4) ./include/linux/atomic/atomic-instrumented.h:1302 (discriminator 4) ./include/asm-generic/qspinlock.h:111 (discriminator 4) ./include/linux/spinlock.h:187 (discriminator 4) ./include/linux/spinlock_api_smp.h:127 (discriminator 4) kernel/locking/spinlock.c:178 (discriminator 4))
    [   70.724561] ? netdev_name_node_lookup_rcu (net/core/dev.c:325 (discriminator 1))
    [   70.724561] __sys_sendto (net/socket.c:730 (discriminator 1) net/socket.c:745 (discriminator 1) net/socket.c:2210 (discriminator 1))
    [   70.724561] ? __sys_setsockopt (./include/linux/file.h:34 net/socket.c:2355)
    [   70.724561] __x64_sys_sendto (net/socket.c:2222 (discriminator 1) net/socket.c:2218 (discriminator 1) net/socket.c:2218 (discriminator 1))
    [   70.724561] do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
    [   70.724561] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    [   70.724561] RIP: 0033:0x41ae09
    
    Fixes: cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Jonathan Davies <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Reviewed-by: Jonathan Davies <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dpaa: Pad packets to ETH_ZLEN [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Tue Sep 10 10:31:44 2024 -0400

    net: dpaa: Pad packets to ETH_ZLEN
    
    [ Upstream commit cbd7ec083413c6a2e0c326d49e24ec7d12c7a9e0 ]
    
    When sending packets under 60 bytes, up to three bytes of the buffer
    following the data may be leaked. Avoid this by extending all packets to
    ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be
    reproduced by running
    
            $ ping -s 11 destination
    
    Fixes: 9ad1a3749333 ("dpaa_eth: add support for DPAA Ethernet")
    Suggested-by: Eric Dumazet <[email protected]>
    Signed-off-by: Sean Anderson <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: aeroflex: fix potential memory leak in greth_start_xmit_gbit() [+ + +]
Author: Wang Hai <[email protected]>
Date:   Sat Oct 12 19:04:34 2024 +0800

    net: ethernet: aeroflex: fix potential memory leak in greth_start_xmit_gbit()
    
    [ Upstream commit cf57b5d7a2aad456719152ecd12007fe031628a3 ]
    
    The greth_start_xmit_gbit() returns NETDEV_TX_OK without freeing skb
    in case of skb->len being too long, add dev_kfree_skb() to fix it.
    
    Fixes: d4c41139df6e ("net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver")
    Signed-off-by: Wang Hai <[email protected]>
    Reviewed-by: Gerhard Engleder <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: cortina: Drop TSO support [+ + +]
Author: Linus Walleij <[email protected]>
Date:   Sat Jan 6 01:12:22 2024 +0100

    net: ethernet: cortina: Drop TSO support
    
    [ Upstream commit ac631873c9e7a50d2a8de457cfc4b9f86666403e ]
    
    The recent change to allow large frames without hardware checksumming
    slotted in software checksumming in the driver if hardware could not
    do it.
    
    This will however upset TSO (TCP Segment Offloading). Typical
    error dumps includes this:
    
    skb len=2961 headroom=222 headlen=66 tailroom=0
    (...)
    WARNING: CPU: 0 PID: 956 at net/core/dev.c:3259 skb_warn_bad_offload+0x7c/0x108
    gemini-ethernet-port: caps=(0x0000010000154813, 0x00002007ffdd7889)
    
    And the packets do not go through.
    
    The TSO implementation is bogus: a TSO enabled driver must propagate
    the skb_shinfo(skb)->gso_size value to the TSO engine on the NIC.
    
    Drop the size check and TSO offloading features for now: this
    needs to be fixed up properly.
    
    After this ethernet works fine on Gemini devices with a direct connected
    PHY such as D-Link DNS-313.
    
    Also tested to still be working with a DSA switch using the Gemini
    ethernet as conduit interface.
    
    Link: https://lore.kernel.org/netdev/CANn89iJLfxng1sYL5Zk0mknXpyYQPCp83m3KgD2KJ2_hKCpEUg@mail.gmail.com/
    Suggested-by: Eric Dumazet <[email protected]>
    Fixes: d4d0c5b4d279 ("net: ethernet: cortina: Handle large frames")
    Signed-off-by: Linus Walleij <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: lantiq_etop: fix memory disclosure [+ + +]
Author: Aleksander Jan Bajkowski <[email protected]>
Date:   Mon Sep 23 23:49:49 2024 +0200

    net: ethernet: lantiq_etop: fix memory disclosure
    
    [ Upstream commit 45c0de18ff2dc9af01236380404bbd6a46502c69 ]
    
    When applying padding, the buffer is not zeroed, which results in memory
    disclosure. The mentioned data is observed on the wire. This patch uses
    skb_put_padto() to pad Ethernet frames properly. The mentioned function
    zeroes the expanded buffer.
    
    In case the packet cannot be padded it is silently dropped. Statistics
    are also not incremented. This driver does not support statistics in the
    old 32-bit format or the new 64-bit format. These will be added in the
    future. In its current form, the patch should be easily backported to
    stable versions.
    
    Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets
    in hardware, so software padding must be applied.
    
    Fixes: 504d4721ee8e ("MIPS: Lantiq: Add ethernet driver")
    Signed-off-by: Aleksander Jan Bajkowski <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: use ip_hdrlen() instead of bit shift [+ + +]
Author: Moon Yeounsu <[email protected]>
Date:   Wed Aug 7 19:07:21 2024 +0900

    net: ethernet: use ip_hdrlen() instead of bit shift
    
    [ Upstream commit 9a039eeb71a42c8b13408a1976e300f3898e1be0 ]
    
    `ip_hdr(skb)->ihl << 2` is the same as `ip_hdrlen(skb)`
    Therefore, we should use a well-defined function not a bit shift
    to find the header length.
    
    It also compresses two lines to a single line.
    
    Signed-off-by: Moon Yeounsu <[email protected]>
    Reviewed-by: Christophe JAILLET <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: Fix an unsafe loop on the list [+ + +]
Author: Anastasia Kovaleva <[email protected]>
Date:   Thu Oct 3 13:44:31 2024 +0300

    net: Fix an unsafe loop on the list
    
    commit 1dae9f1187189bc09ff6d25ca97ead711f7e26f9 upstream.
    
    The kernel may crash when deleting a genetlink family if there are still
    listeners for that family:
    
    Oops: Kernel access of bad area, sig: 11 [#1]
      ...
      NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0
      LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0
      Call Trace:
    __netlink_clear_multicast_users+0x74/0xc0
    genl_unregister_family+0xd4/0x2d0
    
    Change the unsafe loop on the list to a safe one, because inside the
    loop there is an element removal from this list.
    
    Fixes: b8273570f802 ("genetlink: fix netns vs. netlink table locking (2)")
    Cc: [email protected]
    Signed-off-by: Anastasia Kovaleva <[email protected]>
    Reviewed-by: Dmitry Bogdanov <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: ftgmac100: Enable TX interrupt to avoid TX timeout [+ + +]
Author: Jacky Chou <[email protected]>
Date:   Fri Sep 6 14:28:31 2024 +0800

    net: ftgmac100: Enable TX interrupt to avoid TX timeout
    
    [ Upstream commit fef2843bb49f414d1523ca007d088071dee0e055 ]
    
    Currently, the driver only enables RX interrupt to handle RX
    packets and TX resources. Sometimes there is not RX traffic,
    so the TX resource needs to wait for RX interrupt to free.
    This situation will toggle the TX timeout watchdog when the MAC
    TX ring has no more resources to transmit packets.
    Therefore, enable TX interrupt to release TX resources at any time.
    
    When I am verifying iperf3 over UDP, the network hangs.
    Like the log below.
    
    root# iperf3 -c 192.168.100.100 -i1 -t10 -u -b0
    Connecting to host 192.168.100.100, port 5201
    [  4] local 192.168.100.101 port 35773 connected to 192.168.100.100 port 5201
    [ ID] Interval           Transfer     Bandwidth       Total Datagrams
    [  4]   0.00-20.42  sec   160 KBytes  64.2 Kbits/sec  20
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    [  4]  20.42-20.42  sec  0.00 Bytes  0.00 bits/sec  0
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval          Transfer    Bandwidth      Jitter   Lost/Total Datagrams
    [  4]   0.00-20.42  sec  160 KBytes 64.2 Kbits/sec 0.000 ms 0/20 (0%)
    [  4] Sent 20 datagrams
    iperf3: error - the server has terminated
    
    The network topology is FTGMAC connects directly to a PC.
    UDP does not need to wait for ACK, unlike TCP.
    Therefore, FTGMAC needs to enable TX interrupt to release TX resources instead
    of waiting for the RX interrupt.
    
    Fixes: 10cbd6407609 ("ftgmac100: Rework NAPI & interrupts handling")
    Signed-off-by: Jacky Chou <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ftgmac100: Ensure tx descriptor updates are visible [+ + +]
Author: Jacky Chou <[email protected]>
Date:   Thu Aug 22 15:30:06 2024 +0800

    net: ftgmac100: Ensure tx descriptor updates are visible
    
    [ Upstream commit 4186c8d9e6af57bab0687b299df10ebd47534a0a ]
    
    The driver must ensure TX descriptor updates are visible
    before updating TX pointer and TX clear pointer.
    
    This resolves TX hangs observed on AST2600 when running
    iperf3.
    
    Signed-off-by: Jacky Chou <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hisilicon: hip04: fix OF node leak in probe() [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Aug 27 16:44:19 2024 +0200

    net: hisilicon: hip04: fix OF node leak in probe()
    
    [ Upstream commit 17555297dbd5bccc93a01516117547e26a61caf1 ]
    
    Driver is leaking OF node reference from
    of_parse_phandle_with_fixed_args() in probe().
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info() [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Aug 27 16:44:20 2024 +0200

    net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info()
    
    [ Upstream commit 5680cf8d34e1552df987e2f4bb1bff0b2a8c8b11 ]
    
    Driver is leaking OF node reference from
    of_parse_phandle_with_fixed_args() in hns_mac_get_info().
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: hisilicon: hns_mdio: fix OF node leak in probe() [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Aug 27 16:44:21 2024 +0200

    net: hisilicon: hns_mdio: fix OF node leak in probe()
    
    [ Upstream commit e62beddc45f487b9969821fad3a0913d9bc18a2f ]
    
    Driver is leaking OF node reference from
    of_parse_phandle_with_fixed_args() in probe().
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ibm: emac: mal: fix wrong goto [+ + +]
Author: Rosen Penev <[email protected]>
Date:   Mon Oct 7 16:57:11 2024 -0700

    net: ibm: emac: mal: fix wrong goto
    
    [ Upstream commit 08c8acc9d8f3f70d62dd928571368d5018206490 ]
    
    dcr_map is called in the previous if and therefore needs to be unmapped.
    
    Fixes: 1ff0fcfcb1a6 ("ibm_newemac: Fix new MAL feature handling")
    Signed-off-by: Rosen Penev <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Wed Sep 11 17:42:34 2024 +0800

    net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit 09573b1cc76e7ff8f056ab29ea1cdc152ec8c653 ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver driver")
    Reviewed-by: Miquel Raynal <[email protected]>
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Stefan Schmidt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mvpp2: Increase size of queue_name buffer [+ + +]
Author: Simon Horman <[email protected]>
Date:   Tue Aug 6 12:28:24 2024 +0100

    net: mvpp2: Increase size of queue_name buffer
    
    [ Upstream commit 91d516d4de48532d967a77967834e00c8c53dfe6 ]
    
    Increase size of queue_name buffer from 30 to 31 to accommodate
    the largest string written to it. This avoids truncation in
    the possibly unlikely case where the string is name is the
    maximum size.
    
    Flagged by gcc-14:
    
      .../mvpp2_main.c: In function 'mvpp2_probe':
      .../mvpp2_main.c:7636:32: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
       7636 |                  "stats-wq-%s%s", netdev_name(priv->port_list[0]->dev),
            |                                ^
      .../mvpp2_main.c:7635:9: note: 'snprintf' output between 10 and 31 bytes into a destination of size 30
       7635 |         snprintf(priv->queue_name, sizeof(priv->queue_name),
            |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       7636 |                  "stats-wq-%s%s", netdev_name(priv->port_list[0]->dev),
            |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       7637 |                  priv->port_count > 1 ? "+" : "");
            |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Introduced by commit 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics").
    I am not flagging this as a bug as I am not aware that it is one.
    
    Compile tested only.
    
    Signed-off-by: Simon Horman <[email protected]>
    Reviewed-by: Marcin Wojtas <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: vitesse: repair vsc73xx autonegotiation [+ + +]
Author: Pawel Dembicki <[email protected]>
Date:   Fri Aug 9 21:38:06 2024 +0200

    net: phy: vitesse: repair vsc73xx autonegotiation
    
    [ Upstream commit de7a670f8defe4ed2115552ad23dea0f432f7be4 ]
    
    When the vsc73xx mdio bus work properly, the generic autonegotiation
    configuration works well.
    
    Reviewed-by: Linus Walleij <[email protected]>
    Signed-off-by: Pawel Dembicki <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: qrtr: Update packets cloning when broadcasting [+ + +]
Author: Youssef Samir <[email protected]>
Date:   Mon Sep 16 19:08:58 2024 +0200

    net: qrtr: Update packets cloning when broadcasting
    
    [ Upstream commit f011b313e8ebd5b7abd8521b5119aecef403de45 ]
    
    When broadcasting data to multiple nodes via MHI, using skb_clone()
    causes all nodes to receive the same header data. This can result in
    packets being discarded by endpoints, leading to lost data.
    
    This issue occurs when a socket is closed, and a QRTR_TYPE_DEL_CLIENT
    packet is broadcasted. All nodes receive the same destination node ID,
    causing the node connected to the client to discard the packet and
    remain unaware of the client's deletion.
    
    Replace skb_clone() with pskb_copy(), to create a separate copy of
    the header for each sk_buff.
    
    Fixes: bdabad3e363d ("net: Add Qualcomm IPC router")
    Signed-off-by: Youssef Samir <[email protected]>
    Reviewed-by: Jeffery Hugo <[email protected]>
    Reviewed-by: Carl Vanderlip <[email protected]>
    Reviewed-by: Chris Lew <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: sched: consistently use rcu_replace_pointer() in taprio_change() [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Wed Sep 4 14:54:01 2024 +0300

    net: sched: consistently use rcu_replace_pointer() in taprio_change()
    
    [ Upstream commit d5c4546062fd6f5dbce575c7ea52ad66d1968678 ]
    
    According to Vinicius (and carefully looking through the whole
    https://syzkaller.appspot.com/bug?extid=b65e0af58423fc8a73aa
    once again), txtime branch of 'taprio_change()' is not going to
    race against 'advance_sched()'. But using 'rcu_replace_pointer()'
    in the former may be a good idea as well.
    
    Suggested-by: Vinicius Costa Gomes <[email protected]>
    Signed-off-by: Dmitry Antipov <[email protected]>
    Acked-by: Vinicius Costa Gomes <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: sched: fix use-after-free in taprio_change() [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Fri Oct 18 08:13:38 2024 +0300

    net: sched: fix use-after-free in taprio_change()
    
    [ Upstream commit f504465970aebb2467da548f7c1efbbf36d0f44b ]
    
    In 'taprio_change()', 'admin' pointer may become dangling due to sched
    switch / removal caused by 'advance_sched()', and critical section
    protected by 'q->current_entry_lock' is too small to prevent from such
    a scenario (which causes use-after-free detected by KASAN). Fix this
    by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update
    'admin' immediately before an attempt to schedule freeing.
    
    Fixes: a3d43c0d56f1 ("taprio: Add support adding an admin schedule")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=b65e0af58423fc8a73aa
    Acked-by: Vinicius Costa Gomes <[email protected]>
    Signed-off-by: Dmitry Antipov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition [+ + +]
Author: Kaixin Wang <[email protected]>
Date:   Sun Sep 15 22:40:46 2024 +0800

    net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition
    
    [ Upstream commit b5109b60ee4fcb2f2bb24f589575e10cc5283ad4 ]
    
    In the ether3_probe function, a timer is initialized with a callback
    function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is
    started, there is a risk of a race condition if the module or device
    is removed, triggering the ether3_remove function to perform cleanup.
    The sequence of operations that may lead to a UAF bug is as follows:
    
    CPU0                                    CPU1
    
                          |  ether3_ledoff
    ether3_remove         |
      free_netdev(dev);   |
      put_devic           |
      kfree(dev);         |
     |  ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2);
                          | // use dev
    
    Fix it by ensuring that the timer is canceled before proceeding with
    the cleanup in ether3_remove.
    
    Fixes: 6fd9c53f7186 ("net: seeq: Convert timers to use timer_setup()")
    Signed-off-by: Kaixin Wang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension [+ + +]
Author: Benoît Monin <[email protected]>
Date:   Thu Oct 24 16:01:54 2024 +0200

    net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension
    
    [ Upstream commit 04c20a9356f283da623903e81e7c6d5df7e4dc3c ]
    
    As documented in skbuff.h, devices with NETIF_F_IPV6_CSUM capability
    can only checksum TCP and UDP over IPv6 if the IP header does not
    contains extension.
    
    This is enforced for UDP packets emitted from user-space to an IPv6
    address as they go through ip6_make_skb(), which calls
    __ip6_append_data() where a check is done on the header size before
    setting CHECKSUM_PARTIAL.
    
    But the introduction of UDP encapsulation with fou6 added a code-path
    where it is possible to get an skb with a partial UDP checksum and an
    IPv6 header with extension:
    * fou6 adds a UDP header with a partial checksum if the inner packet
    does not contains a valid checksum.
    * ip6_tunnel adds an IPv6 header with a destination option extension
    header if encap_limit is non-zero (the default value is 4).
    
    The thread linked below describes in more details how to reproduce the
    problem with GRE-in-UDP tunnel.
    
    Add a check on the network header size in skb_csum_hwoffload_help() to
    make sure no IPv6 packet with extension header is handed to a network
    device with NETIF_F_IPV6_CSUM capability.
    
    Link: https://lore.kernel.org/netdev/[email protected]/T/#u
    Fixes: aa3463d65e7b ("fou: Add encap ops for IPv6 tunnels")
    Signed-off-by: Benoît Monin <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://patch.msgid.link/5fbeecfc311ea182aa1d1c771725ab8b4cac515e.1729778144.git.benoit.monin@gmx.fr
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: support ip generic csum processing in skb_csum_hwoffload_help [+ + +]
Author: Xin Long <[email protected]>
Date:   Thu Jan 28 17:18:31 2021 +0800

    net: support ip generic csum processing in skb_csum_hwoffload_help
    
    [ Upstream commit 62fafcd63139920eb25b3fbf154177ce3e6f3232 ]
    
    NETIF_F_IP|IPV6_CSUM feature flag indicates UDP and TCP csum offload
    while NETIF_F_HW_CSUM feature flag indicates ip generic csum offload
    for HW, which includes not only for TCP/UDP csum, but also for other
    protocols' csum like GRE's.
    
    However, in skb_csum_hwoffload_help() it only checks features against
    NETIF_F_CSUM_MASK(NETIF_F_HW|IP|IPV6_CSUM). So if it's a non TCP/UDP
    packet and the features doesn't support NETIF_F_HW_CSUM, but supports
    NETIF_F_IP|IPV6_CSUM only, it would still return 0 and leave the HW
    to do csum.
    
    This patch is to support ip generic csum processing by checking
    NETIF_F_HW_CSUM for all protocols, and check (NETIF_F_IP_CSUM |
    NETIF_F_IPV6_CSUM) only for TCP and UDP.
    
    Note that we're using skb->csum_offset to check if it's a TCP/UDP
    proctol, this might be fragile. However, as Alex said, for now we
    only have a few L4 protocols that are requesting Tx csum offload,
    we'd better fix this until a new protocol comes with a same csum
    offset.
    
    v1->v2:
      - not extend skb->csum_not_inet, but use skb->csum_offset to tell
        if it's an UDP/TCP csum packet.
    v2->v3:
      - add a note in the changelog, as Willem suggested.
    
    Suggested-by: Alexander Duyck <[email protected]>
    Signed-off-by: Xin Long <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 04c20a9356f2 ("net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension")
    Signed-off-by: Sasha Levin <[email protected]>

net: systemport: fix potential memory leak in bcm_sysport_xmit() [+ + +]
Author: Wang Hai <[email protected]>
Date:   Mon Oct 14 22:51:15 2024 +0800

    net: systemport: fix potential memory leak in bcm_sysport_xmit()
    
    [ Upstream commit c401ed1c709948e57945485088413e1bb5e94bd1 ]
    
    The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb
    in case of dma_map_single() fails, add dev_kfree_skb() to fix it.
    
    Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
    Signed-off-by: Wang Hai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: tipc: avoid possible garbage value [+ + +]
Author: Su Hui <[email protected]>
Date:   Thu Sep 12 19:01:20 2024 +0800

    net: tipc: avoid possible garbage value
    
    [ Upstream commit 99655a304e450baaae6b396cb942b9e47659d644 ]
    
    Clang static checker (scan-build) warning:
    net/tipc/bcast.c:305:4:
    The expression is an uninitialized value. The computed value will also
    be garbage [core.uninitialized.Assign]
      305 |                         (*cong_link_cnt)++;
          |                         ^~~~~~~~~~~~~~~~~~
    
    tipc_rcast_xmit() will increase cong_link_cnt's value, but cong_link_cnt
    is uninitialized. Although it won't really cause a problem, it's better
    to fix it.
    
    Fixes: dca4a17d24ee ("tipc: fix potential hanging after b/rcast changing")
    Signed-off-by: Su Hui <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: usbnet: fix name regression [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Oct 17 09:18:37 2024 +0200

    net: usb: usbnet: fix name regression
    
    [ Upstream commit 8a7d12d674ac6f2147c18f36d1e15f1a48060edf ]
    
    The fix for MAC addresses broke detection of the naming convention
    because it gave network devices no random MAC before bind()
    was called. This means that the check for the local assignment bit
    was always negative as the address was zeroed from allocation,
    instead of from overwriting the MAC with a unique hardware address.
    
    The correct check for whether bind() has altered the MAC is
    done with is_zero_ether_addr
    
    Signed-off-by: Oliver Neukum <[email protected]>
    Reported-by: Greg Thelen <[email protected]>
    Diagnosed-by: John Sperbeck <[email protected]>
    Fixes: bab8eb0dd4cb9 ("usbnet: modern method to get random MAC")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: br_netfilter: fix panic with metadata_dst skb [+ + +]
Author: Andy Roulin <[email protected]>
Date:   Tue Oct 1 08:43:59 2024 -0700

    netfilter: br_netfilter: fix panic with metadata_dst skb
    
    [ Upstream commit f9ff7665cd128012868098bbd07e28993e314fdb ]
    
    Fix a kernel panic in the br_netfilter module when sending untagged
    traffic via a VxLAN device.
    This happens during the check for fragmentation in br_nf_dev_queue_xmit.
    
    It is dependent on:
    1) the br_netfilter module being loaded;
    2) net.bridge.bridge-nf-call-iptables set to 1;
    3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;
    4) untagged frames with size higher than the VxLAN MTU forwarded/flooded
    
    When forwarding the untagged packet to the VxLAN bridge port, before
    the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and
    changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type
    of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL.
    
    Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check
    for frames that needs to be fragmented: frames with higher MTU than the
    VxLAN device end up calling br_nf_ip_fragment, which in turns call
    ip_skb_dst_mtu.
    
    The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst
    with valid dst->dev, thus the crash.
    
    This case was never supported in the first place, so drop the packet
    instead.
    
    PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.
    [  176.291791] Unable to handle kernel NULL pointer dereference at
    virtual address 0000000000000110
    [  176.292101] Mem abort info:
    [  176.292184]   ESR = 0x0000000096000004
    [  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits
    [  176.292530]   SET = 0, FnV = 0
    [  176.292709]   EA = 0, S1PTW = 0
    [  176.292862]   FSC = 0x04: level 0 translation fault
    [  176.293013] Data abort info:
    [  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
    [  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    [  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    [  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000
    [  176.294166] [0000000000000110] pgd=0000000000000000,
    p4d=0000000000000000
    [  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
    [  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth
    br_netfilter bridge stp llc ipv6 crct10dif_ce
    [  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted
    6.8.0-rc3-g5b3fbd61b9d1 #2
    [  176.296314] Hardware name: linux,dummy-virt (DT)
    [  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
    BTYPE=--)
    [  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
    [  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]
    [  176.297636] sp : ffff800080003630
    [  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:
    ffff6828c49ad9f8
    [  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:
    00000000000003e8
    [  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:
    ffff6828c3b16d28
    [  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:
    0000000000000014
    [  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:
    0000000095744632
    [  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:
    ffffb7e137926a70
    [  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :
    0000000000000000
    [  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :
    f20e0100bebafeca
    [  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :
    0000000000000000
    [  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :
    ffff6828c7f918f0
    [  176.300889] Call trace:
    [  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
    [  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]
    [  176.301703]  nf_hook_slow+0x48/0x124
    [  176.302060]  br_forward_finish+0xc8/0xe8 [bridge]
    [  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]
    [  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter]
    [  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]
    [  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter]
    [  176.303359]  nf_hook_slow+0x48/0x124
    [  176.303803]  __br_forward+0xc4/0x194 [bridge]
    [  176.304013]  br_flood+0xd4/0x168 [bridge]
    [  176.304300]  br_handle_frame_finish+0x1d4/0x5c4 [bridge]
    [  176.304536]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]
    [  176.304978]  br_nf_pre_routing_finish+0x29c/0x494 [br_netfilter]
    [  176.305188]  br_nf_pre_routing+0x250/0x524 [br_netfilter]
    [  176.305428]  br_handle_frame+0x244/0x3cc [bridge]
    [  176.305695]  __netif_receive_skb_core.constprop.0+0x33c/0xecc
    [  176.306080]  __netif_receive_skb_one_core+0x40/0x8c
    [  176.306197]  __netif_receive_skb+0x18/0x64
    [  176.306369]  process_backlog+0x80/0x124
    [  176.306540]  __napi_poll+0x38/0x17c
    [  176.306636]  net_rx_action+0x124/0x26c
    [  176.306758]  __do_softirq+0x100/0x26c
    [  176.307051]  ____do_softirq+0x10/0x1c
    [  176.307162]  call_on_irq_stack+0x24/0x4c
    [  176.307289]  do_softirq_own_stack+0x1c/0x2c
    [  176.307396]  do_softirq+0x54/0x6c
    [  176.307485]  __local_bh_enable_ip+0x8c/0x98
    [  176.307637]  __dev_queue_xmit+0x22c/0xd28
    [  176.307775]  neigh_resolve_output+0xf4/0x1a0
    [  176.308018]  ip_finish_output2+0x1c8/0x628
    [  176.308137]  ip_do_fragment+0x5b4/0x658
    [  176.308279]  ip_fragment.constprop.0+0x48/0xec
    [  176.308420]  __ip_finish_output+0xa4/0x254
    [  176.308593]  ip_finish_output+0x34/0x130
    [  176.308814]  ip_output+0x6c/0x108
    [  176.308929]  ip_send_skb+0x50/0xf0
    [  176.309095]  ip_push_pending_frames+0x30/0x54
    [  176.309254]  raw_sendmsg+0x758/0xaec
    [  176.309568]  inet_sendmsg+0x44/0x70
    [  176.309667]  __sys_sendto+0x110/0x178
    [  176.309758]  __arm64_sys_sendto+0x28/0x38
    [  176.309918]  invoke_syscall+0x48/0x110
    [  176.310211]  el0_svc_common.constprop.0+0x40/0xe0
    [  176.310353]  do_el0_svc+0x1c/0x28
    [  176.310434]  el0_svc+0x34/0xb4
    [  176.310551]  el0t_64_sync_handler+0x120/0x12c
    [  176.310690]  el0t_64_sync+0x190/0x194
    [  176.311066] Code: f9402e61 79402aa2 927ff821 f9400023 (f9408860)
    [  176.315743] ---[ end trace 0000000000000000 ]---
    [  176.316060] Kernel panic - not syncing: Oops: Fatal exception in
    interrupt
    [  176.316371] Kernel Offset: 0x37e0e3000000 from 0xffff800080000000
    [  176.316564] PHYS_OFFSET: 0xffff97d780000000
    [  176.316782] CPU features: 0x0,88000203,3c020000,0100421b
    [  176.317210] Memory Limit: none
    [  176.317527] ---[ end Kernel panic - not syncing: Oops: Fatal
    Exception in interrupt ]---\
    
    Fixes: 11538d039ac6 ("bridge: vlan dst_metadata hooks in ingress and egress paths")
    Reviewed-by: Ido Schimmel <[email protected]>
    Signed-off-by: Andy Roulin <[email protected]>
    Acked-by: Nikolay Aleksandrov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: ctnetlink: compile ctnetlink_label_size with CONFIG_NF_CONNTRACK_EVENTS [+ + +]
Author: Simon Horman <[email protected]>
Date:   Mon Sep 16 16:14:41 2024 +0100

    netfilter: ctnetlink: compile ctnetlink_label_size with CONFIG_NF_CONNTRACK_EVENTS
    
    [ Upstream commit e1f1ee0e9ad8cbe660f5c104e791c5f1a7cf4c31 ]
    
    Only provide ctnetlink_label_size when it is used,
    which is when CONFIG_NF_CONNTRACK_EVENTS is configured.
    
    Flagged by clang-18 W=1 builds as:
    
    .../nf_conntrack_netlink.c:385:19: warning: unused function 'ctnetlink_label_size' [-Wunused-function]
      385 | static inline int ctnetlink_label_size(const struct nf_conn *ct)
          |                   ^~~~~~~~~~~~~~~~~~~~
    
    The condition on CONFIG_NF_CONNTRACK_LABELS being removed by
    this patch guards compilation of non-trivial implementations
    of ctnetlink_dump_labels() and ctnetlink_label_size().
    
    However, this is not necessary as each of these functions
    will always return 0 if CONFIG_NF_CONNTRACK_LABELS is not defined
    as each function starts with the equivalent of:
    
            struct nf_conn_labels *labels = nf_ct_labels_find(ct);
    
            if (!labels)
                    return 0;
    
    And nf_ct_labels_find always returns NULL if CONFIG_NF_CONNTRACK_LABELS
    is not enabled.  So I believe that the compiler optimises the code away
    in such cases anyway.
    
    Found by inspection.
    Compile tested only.
    
    Originally splitted in two patches, Pablo Neira Ayuso collapsed them and
    added Fixes: tag.
    
    Fixes: 0ceabd83875b ("netfilter: ctnetlink: deliver labels to userspace")
    Link: https://lore.kernel.org/netfilter-devel/[email protected]/
    Signed-off-by: Simon Horman <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Sep 13 17:06:15 2024 +0000

    netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()
    
    [ Upstream commit 9c778fe48d20ef362047e3376dee56d77f8500d4 ]
    
    syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending
    garbage on the four reserved tcp bits (th->res1)
    
    Use skb_put_zero() to clear the whole TCP header,
    as done in nf_reject_ip_tcphdr_put()
    
    BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
      nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
      nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
      nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
      expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
      nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
      nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      NF_HOOK include/linux/netfilter.h:312 [inline]
      ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
      __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
      process_backlog+0x4ad/0xa50 net/core/dev.c:6108
      __napi_poll+0xe7/0x980 net/core/dev.c:6772
      napi_poll net/core/dev.c:6841 [inline]
      net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
      handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
      __do_softirq+0x14/0x1a kernel/softirq.c:588
      do_softirq+0x9a/0x100 kernel/softirq.c:455
      __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382
      local_bh_enable include/linux/bottom_half.h:33 [inline]
      rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]
      __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450
      dev_queue_xmit include/linux/netdevice.h:3105 [inline]
      neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565
      neigh_output include/net/neighbour.h:542 [inline]
      ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141
      __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
      ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226
      NF_HOOK_COND include/linux/netfilter.h:303 [inline]
      ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247
      dst_output include/net/dst.h:450 [inline]
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366
      inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135
      __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466
      tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
      tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143
      tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333
      __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679
      inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750
      __sys_connect_file net/socket.c:2061 [inline]
      __sys_connect+0x606/0x690 net/socket.c:2078
      __do_sys_connect net/socket.c:2088 [inline]
      __se_sys_connect net/socket.c:2085 [inline]
      __x64_sys_connect+0x91/0xe0 net/socket.c:2085
      x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was stored to memory at:
      nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249
      nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
      nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
      expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
      nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
      nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      NF_HOOK include/linux/netfilter.h:312 [inline]
      ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
      __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
      process_backlog+0x4ad/0xa50 net/core/dev.c:6108
      __napi_poll+0xe7/0x980 net/core/dev.c:6772
      napi_poll net/core/dev.c:6841 [inline]
      net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
      handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
      __do_softirq+0x14/0x1a kernel/softirq.c:588
    
    Uninit was stored to memory at:
      nf_reject_ip6_tcphdr_put+0x2ca/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:231
      nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
      nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
      expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
      nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
      nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      NF_HOOK include/linux/netfilter.h:312 [inline]
      ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
      __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
      process_backlog+0x4ad/0xa50 net/core/dev.c:6108
      __napi_poll+0xe7/0x980 net/core/dev.c:6772
      napi_poll net/core/dev.c:6841 [inline]
      net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
      handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
      __do_softirq+0x14/0x1a kernel/softirq.c:588
    
    Uninit was created at:
      slab_post_alloc_hook mm/slub.c:3998 [inline]
      slab_alloc_node mm/slub.c:4041 [inline]
      kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4084
      kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583
      __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674
      alloc_skb include/linux/skbuff.h:1320 [inline]
      nf_send_reset6+0x98d/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:327
      nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
      expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
      nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
      nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      NF_HOOK include/linux/netfilter.h:312 [inline]
      ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
      __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
      process_backlog+0x4ad/0xa50 net/core/dev.c:6108
      __napi_poll+0xe7/0x980 net/core/dev.c:6772
      napi_poll net/core/dev.c:6841 [inline]
      net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
      handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
      __do_softirq+0x14/0x1a kernel/softirq.c:588
    
    Fixes: c8d7b98bec43 ("netfilter: move nf_send_resetX() code to nf_reject_ipvX modules")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Pablo Neira Ayuso <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Sep 3 01:06:41 2024 +0200

    netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire
    
    [ Upstream commit e0c47281723f301894c14e6f5cd5884fdfb813f9 ]
    
    Element timeout that is below CONFIG_HZ never expires because the
    timeout extension is not allocated given that nf_msecs_to_jiffies64()
    returns 0. Set timeout to the minimum value to honor timeout.
    
    Fixes: 8e1102d5a159 ("netfilter: nf_tables: support timeouts larger than 23 days")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: prevent nf_skb_duplicated corruption [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Sep 26 18:56:11 2024 +0000

    netfilter: nf_tables: prevent nf_skb_duplicated corruption
    
    [ Upstream commit 92ceba94de6fb4cee2bf40b485979c342f44a492 ]
    
    syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write
    per-cpu variable nf_skb_duplicated in an unsafe way [1].
    
    Disabling preemption as hinted by the splat is not enough,
    we have to disable soft interrupts as well.
    
    [1]
    BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316
     caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
    CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #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
      check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49
      nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
      nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30
      expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
      nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288
      nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
      nf_hook+0x2c4/0x450 include/linux/netfilter.h:269
      NF_HOOK_COND include/linux/netfilter.h:302 [inline]
      ip_output+0x185/0x230 net/ipv4/ip_output.c:433
      ip_local_out net/ipv4/ip_output.c:129 [inline]
      ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495
      udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981
      udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x1a6/0x270 net/socket.c:745
      ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
      ___sys_sendmsg net/socket.c:2651 [inline]
      __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737
      __do_sys_sendmmsg net/socket.c:2766 [inline]
      __se_sys_sendmmsg net/socket.c:2763 [inline]
      __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f4ce4f7def9
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
    RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9
    RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006
    RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
     </TASK>
    
    Fixes: d877f07112f1 ("netfilter: nf_tables: add nft_dup expression")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: reject element expiration with no timeout [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Sep 3 01:06:49 2024 +0200

    netfilter: nf_tables: reject element expiration with no timeout
    
    [ Upstream commit d2dc429ecb4e79ad164028d965c00f689e6f6d06 ]
    
    If element timeout is unset and set provides no default timeout, the
    element expiration is silently ignored, reject this instead to let user
    know this is unsupported.
    
    Also prepare for supporting timeout that never expire, where zero
    timeout and expiration must be also rejected.
    
    Fixes: 8e1102d5a159 ("netfilter: nf_tables: support timeouts larger than 23 days")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: reject expiration higher than timeout [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Sep 3 01:06:58 2024 +0200

    netfilter: nf_tables: reject expiration higher than timeout
    
    [ Upstream commit c0f38a8c60174368aed1d0f9965d733195f15033 ]
    
    Report ERANGE to userspace if user specifies an expiration larger than
    the timeout.
    
    Fixes: 8e1102d5a159 ("netfilter: nf_tables: support timeouts larger than 23 days")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_payload: sanitize offset and length before calling skb_checksum() [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Wed Oct 30 23:13:48 2024 +0100

    netfilter: nft_payload: sanitize offset and length before calling skb_checksum()
    
    [ Upstream commit d5953d680f7e96208c29ce4139a0e38de87a57fe ]
    
    If access to offset + length is larger than the skbuff length, then
    skb_checksum() triggers BUG_ON().
    
    skb_checksum() internally subtracts the length parameter while iterating
    over skbuff, BUG_ON(len) at the end of it checks that the expected
    length to be included in the checksum calculation is fully consumed.
    
    Fixes: 7ec3f7b47b8d ("netfilter: nft_payload: add packet mangling support")
    Reported-by: Slavin Liu <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED [+ + +]
Author: Phil Sutter <[email protected]>
Date:   Wed Sep 25 20:01:20 2024 +0200

    netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED
    
    [ Upstream commit 76f1ed087b562a469f2153076f179854b749c09a ]
    
    Fix the comment which incorrectly defines it as NLA_U32.
    
    Fixes: 3b49e2e94e6e ("netfilter: nf_tables: add flow table netlink frontend")
    Signed-off-by: Phil Sutter <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfp: Use IRQF_NO_AUTOEN flag in request_irq() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Wed Sep 11 17:44:45 2024 +0800

    nfp: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit daaba19d357f0900b303a530ced96c78086267ea ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Reviewed-by: Louis Peens <[email protected]>
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfs: fix memory leak in error path of nfs4_do_reclaim [+ + +]
Author: Li Lingfeng <[email protected]>
Date:   Wed Sep 4 20:34:57 2024 +0800

    nfs: fix memory leak in error path of nfs4_do_reclaim
    
    commit 8f6a7c9467eaf39da4c14e5474e46190ab3fb529 upstream.
    
    Commit c77e22834ae9 ("NFSv4: Fix a potential sleep while atomic in
    nfs4_do_reclaim()") separate out the freeing of the state owners from
    nfs4_purge_state_owners() and finish it outside the rcu lock.
    However, the error path is omitted. As a result, the state owners in
    "freeme" will not be released.
    Fix it by adding freeing in the error path.
    
    Fixes: c77e22834ae9 ("NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()")
    Signed-off-by: Li Lingfeng <[email protected]>
    Cc: [email protected] # v5.3+
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nfsd: call cache_put if xdr_reserve_space returns NULL [+ + +]
Author: Guoqing Jiang <[email protected]>
Date:   Wed Aug 21 22:03:18 2024 +0800

    nfsd: call cache_put if xdr_reserve_space returns NULL
    
    [ Upstream commit d078cbf5c38de83bc31f83c47dcd2184c04a50c7 ]
    
    If not enough buffer space available, but idmap_lookup has triggered
    lookup_fn which calls cache_get and returns successfully. Then we
    missed to call cache_put here which pairs with cache_get.
    
    Fixes: ddd1ea563672 ("nfsd4: use xdr_reserve_space in attribute encoding")
    Signed-off-by: Guoqing Jiang <[email protected]>
    Reviwed-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nfsd: fix delegation_blocked() to block correctly for at least 30 seconds [+ + +]
Author: NeilBrown <[email protected]>
Date:   Mon Sep 9 15:06:36 2024 +1000

    nfsd: fix delegation_blocked() to block correctly for at least 30 seconds
    
    [ Upstream commit 45bb63ed20e02ae146336412889fe5450316a84f ]
    
    The pair of bloom filtered used by delegation_blocked() was intended to
    block delegations on given filehandles for between 30 and 60 seconds.  A
    new filehandle would be recorded in the "new" bit set.  That would then
    be switch to the "old" bit set between 0 and 30 seconds later, and it
    would remain as the "old" bit set for 30 seconds.
    
    Unfortunately the code intended to clear the old bit set once it reached
    30 seconds old, preparing it to be the next new bit set, instead cleared
    the *new* bit set before switching it to be the old bit set.  This means
    that the "old" bit set is always empty and delegations are blocked
    between 0 and 30 seconds.
    
    This patch updates bd->new before clearing the set with that index,
    instead of afterwards.
    
    Reported-by: Olga Kornievskaia <[email protected]>
    Cc: [email protected]
    Fixes: 6282cd565553 ("NFSD: Don't hand out delegations for 30 seconds after recalling them.")
    Signed-off-by: NeilBrown <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nfsd: return -EINVAL when namelen is 0 [+ + +]
Author: Li Lingfeng <[email protected]>
Date:   Tue Sep 3 19:14:46 2024 +0800

    nfsd: return -EINVAL when namelen is 0
    
    [ Upstream commit 22451a16b7ab7debefce660672566be887db1637 ]
    
    When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may
    result in namelen being 0, which will cause memdup_user() to return
    ZERO_SIZE_PTR.
    When we access the name.data that has been assigned the value of
    ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is
    triggered.
    
    [ T1205] ==================================================================
    [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260
    [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205
    [ T1205]
    [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406
    [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
    [ T1205] Call Trace:
    [ T1205]  dump_stack+0x9a/0xd0
    [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
    [ T1205]  __kasan_report.cold+0x34/0x84
    [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
    [ T1205]  kasan_report+0x3a/0x50
    [ T1205]  nfs4_client_to_reclaim+0xe9/0x260
    [ T1205]  ? nfsd4_release_lockowner+0x410/0x410
    [ T1205]  cld_pipe_downcall+0x5ca/0x760
    [ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0
    [ T1205]  ? down_write_killable_nested+0x170/0x170
    [ T1205]  ? avc_policy_seqno+0x28/0x40
    [ T1205]  ? selinux_file_permission+0x1b4/0x1e0
    [ T1205]  rpc_pipe_write+0x84/0xb0
    [ T1205]  vfs_write+0x143/0x520
    [ T1205]  ksys_write+0xc9/0x170
    [ T1205]  ? __ia32_sys_read+0x50/0x50
    [ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110
    [ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110
    [ T1205]  do_syscall_64+0x33/0x40
    [ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1
    [ T1205] RIP: 0033:0x7fdbdb761bc7
    [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514
    [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7
    [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008
    [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001
    [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b
    [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000
    [ T1205] ==================================================================
    
    Fix it by checking namelen.
    
    Signed-off-by: Li Lingfeng <[email protected]>
    Fixes: 74725959c33c ("nfsd: un-deprecate nfsdcld")
    Reviewed-by: Jeff Layton <[email protected]>
    Reviewed-by: Scott Mayhew <[email protected]>
    Tested-by: Scott Mayhew <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nfsd: use ktime_get_seconds() for timestamps [+ + +]
Author: Arnd Bergmann <[email protected]>
Date:   Fri Oct 20 11:25:34 2017 +0200

    nfsd: use ktime_get_seconds() for timestamps
    
    [ Upstream commit b3f255ef6bffc18a28c3b6295357f2a3380c033f ]
    
    The delegation logic in nfsd uses the somewhat inefficient
    seconds_since_boot() function to record time intervals.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: J. Bruce Fields <[email protected]>
    Stable-dep-of: 45bb63ed20e0 ("nfsd: fix delegation_blocked() to block correctly for at least 30 seconds")
    Signed-off-by: Sasha Levin <[email protected]>

 
nilfs2: determine empty node blocks as corrupted [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Wed Sep 4 17:13:08 2024 +0900

    nilfs2: determine empty node blocks as corrupted
    
    [ Upstream commit 111b812d3662f3a1b831d19208f83aa711583fe6 ]
    
    Due to the nature of b-trees, nilfs2 itself and admin tools such as
    mkfs.nilfs2 will never create an intermediate b-tree node block with 0
    child nodes, nor will they delete (key, pointer)-entries that would result
    in such a state.  However, it is possible that a b-tree node block is
    corrupted on the backing device and is read with 0 child nodes.
    
    Because operation is not guaranteed if the number of child nodes is 0 for
    intermediate node blocks other than the root node, modify
    nilfs_btree_node_broken(), which performs sanity checks when reading a
    b-tree node block, so that such cases will be judged as metadata
    corruption.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 17c76b0104e4 ("nilfs2: B-tree based block mapping")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Cc: Lizhi Xu <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nilfs2: fix kernel bug due to missing clearing of buffer delay flag [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Wed Oct 16 06:32:07 2024 +0900

    nilfs2: fix kernel bug due to missing clearing of buffer delay flag
    
    commit 6ed469df0bfbef3e4b44fca954a781919db9f7ab upstream.
    
    Syzbot reported that after nilfs2 reads a corrupted file system image
    and degrades to read-only, the BUG_ON check for the buffer delay flag
    in submit_bh_wbc() may fail, causing a kernel bug.
    
    This is because the buffer delay flag is not cleared when clearing the
    buffer state flags to discard a page/folio or a buffer head. So, fix
    this.
    
    This became necessary when the use of nilfs2's own page clear routine
    was expanded.  This state inconsistency does not occur if the buffer
    is written normally by log writing.
    
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=985ada84bf055a575c07
    Cc: [email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nilfs2: fix kernel bug due to missing clearing of checked flag [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Fri Oct 18 04:33:10 2024 +0900

    nilfs2: fix kernel bug due to missing clearing of checked flag
    
    commit 41e192ad2779cae0102879612dfe46726e4396aa upstream.
    
    Syzbot reported that in directory operations after nilfs2 detects
    filesystem corruption and degrades to read-only,
    __block_write_begin_int(), which is called to prepare block writes, may
    fail the BUG_ON check for accesses exceeding the folio/page size,
    triggering a kernel bug.
    
    This was found to be because the "checked" flag of a page/folio was not
    cleared when it was discarded by nilfs2's own routine, which causes the
    sanity check of directory entries to be skipped when the directory
    page/folio is reloaded.  So, fix that.
    
    This was necessary when the use of nilfs2's own page discard routine was
    applied to more than just metadata files.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=d6ca2daf692c7a82f959
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nilfs2: fix potential deadlock with newly created symlinks [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Sun Oct 20 13:51:28 2024 +0900

    nilfs2: fix potential deadlock with newly created symlinks
    
    commit b3a033e3ecd3471248d474ef263aadc0059e516a upstream.
    
    Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers
    memory reclamation involving the filesystem layer, which can result in
    circular lock dependencies among the reader/writer semaphore
    nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the
    fs_reclaim pseudo lock.
    
    This is because after commit 21fc61c73c39 ("don't put symlink bodies in
    pagecache into highmem"), the gfp flags of the page cache for symbolic
    links are overwritten to GFP_KERNEL via inode_nohighmem().
    
    This is not a problem for symlinks read from the backing device, because
    the __GFP_FS flag is dropped after inode_nohighmem() is called.  However,
    when a new symlink is created with nilfs_symlink(), the gfp flags remain
    overwritten to GFP_KERNEL.  Then, memory allocation called from
    page_symlink() etc.  triggers memory reclamation including the FS layer,
    which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can
    cause a deadlock if they are called while nilfs->ns_segctor_sem is held:
    
    Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags
    of newly created symlinks in the same way that nilfs_new_inode() and
    __nilfs_read_inode() do, as a workaround until we adopt nofs allocation
    scope consistently or improve the locking constraints.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=9ef37ac20608f4836256
    Tested-by: [email protected]
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Wed Sep 4 17:13:07 2024 +0900

    nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()
    
    [ Upstream commit 9403001ad65ae4f4c5de368bdda3a0636b51d51a ]
    
    Patch series "nilfs2: fix potential issues with empty b-tree nodes".
    
    This series addresses three potential issues with empty b-tree nodes that
    can occur with corrupted filesystem images, including one recently
    discovered by syzbot.
    
    This patch (of 3):
    
    If a b-tree is broken on the device, and the b-tree height is greater than
    2 (the level of the root node is greater than 1) even if the number of
    child nodes of the b-tree root is 0, a NULL pointer dereference occurs in
    nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().
    
    This is because, when the number of child nodes of the b-tree root is 0,
    nilfs_btree_do_lookup() does not set the block buffer head in any of
    path[x].bp_bh, leaving it as the initial value of NULL, but if the level
    of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(),
    which accesses the buffer memory of path[x].bp_bh, is called.
    
    Fix this issue by adding a check to nilfs_btree_root_broken(), which
    performs sanity checks when reading the root node from the device, to
    detect this inconsistency.
    
    Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause
    early on.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 17c76b0104e4 ("nilfs2: B-tree based block mapping")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=9bff4c7b992038a7409f
    Cc: Lizhi Xu <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nilfs2: fix potential oob read in nilfs_btree_check_delete() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Wed Sep 4 17:13:09 2024 +0900

    nilfs2: fix potential oob read in nilfs_btree_check_delete()
    
    [ Upstream commit f9c96351aa6718b42a9f42eaf7adce0356bdb5e8 ]
    
    The function nilfs_btree_check_delete(), which checks whether degeneration
    to direct mapping occurs before deleting a b-tree entry, causes memory
    access outside the block buffer when retrieving the maximum key if the
    root node has no entries.
    
    This does not usually happen because b-tree mappings with 0 child nodes
    are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen
    if the b-tree root node read from a device is configured that way, so fix
    this potential issue by adding a check for that case.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 17c76b0104e4 ("nilfs2: B-tree based block mapping")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Cc: Lizhi Xu <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nilfs2: propagate directory read errors from nilfs_find_entry() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Fri Oct 4 12:35:31 2024 +0900

    nilfs2: propagate directory read errors from nilfs_find_entry()
    
    commit 08cfa12adf888db98879dbd735bc741360a34168 upstream.
    
    Syzbot reported that a task hang occurs in vcs_open() during a fuzzing
    test for nilfs2.
    
    The root cause of this problem is that in nilfs_find_entry(), which
    searches for directory entries, ignores errors when loading a directory
    page/folio via nilfs_get_folio() fails.
    
    If the filesystem images is corrupted, and the i_size of the directory
    inode is large, and the directory page/folio is successfully read but
    fails the sanity check, for example when it is zero-filled,
    nilfs_check_folio() may continue to spit out error messages in bursts.
    
    Fix this issue by propagating the error to the callers when loading a
    page/folio fails in nilfs_find_entry().
    
    The current interface of nilfs_find_entry() and its callers is outdated
    and cannot propagate error codes such as -EIO and -ENOMEM returned via
    nilfs_find_entry(), so fix it together.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: Lizhi Xu <[email protected]>
    Closes: https://lkml.kernel.org/r/[email protected]
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=8a192e8d090fa9a31135
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error [+ + +]
Author: Yonatan Maman <[email protected]>
Date:   Tue Oct 8 14:59:43 2024 +0300

    nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error
    
    commit 835745a377a4519decd1a36d6b926e369b3033e2 upstream.
    
    The `nouveau_dmem_copy_one` function ensures that the copy push command is
    sent to the device firmware but does not track whether it was executed
    successfully.
    
    In the case of a copy error (e.g., firmware or hardware failure), the
    copy push command will be sent via the firmware channel, and
    `nouveau_dmem_copy_one` will likely report success, leading to the
    `migrate_to_ram` function returning a dirty HIGH_USER page to the user.
    
    This can result in a security vulnerability, as a HIGH_USER page that may
    contain sensitive or corrupted data could be returned to the user.
    
    To prevent this vulnerability, we allocate a zero page. Thus, in case of
    an error, a non-dirty (zero) page will be returned to the user.
    
    Fixes: 5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM")
    Signed-off-by: Yonatan Maman <[email protected]>
    Co-developed-by: Gal Shalom <[email protected]>
    Signed-off-by: Gal Shalom <[email protected]>
    Reviewed-by: Ben Skeggs <[email protected]>
    Cc: [email protected]
    Signed-off-by: Danilo Krummrich <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Thu Aug 31 20:39:27 2023 +0800

    ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()
    
    [ Upstream commit e229897d373a87ee09ec5cc4ecd4bb2f895fc16b ]
    
    The debugfs_create_dir() function returns error pointers.
    It never returns NULL. So use IS_ERR() to check it.
    
    Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Signed-off-by: Jon Mason <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition [+ + +]
Author: Kaixin Wang <[email protected]>
Date:   Tue Sep 10 01:20:07 2024 +0800

    ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition
    
    [ Upstream commit e51aded92d42784313ba16c12f4f88cc4f973bbb ]
    
    In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev
    function, then &sndev->check_link_status_work is bound with
    check_link_status_work. switchtec_ntb_link_notification may be called
    to start the work.
    
    If we remove the module which will call switchtec_ntb_remove to make
    cleanup, it will free sndev through kfree(sndev), while the work
    mentioned above will be used. The sequence of operations that may lead
    to a UAF bug is as follows:
    
    CPU0                                 CPU1
    
                            | check_link_status_work
    switchtec_ntb_remove    |
    kfree(sndev);           |
                            | if (sndev->link_force_down)
                            | // use sndev
    
    Fix it by ensuring that the work is canceled before proceeding with
    the cleanup in switchtec_ntb_remove.
    
    Signed-off-by: Kaixin Wang <[email protected]>
    Reviewed-by: Logan Gunthorpe <[email protected]>
    Signed-off-by: Jon Mason <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ocfs2: add bounds checking to ocfs2_xattr_find_entry() [+ + +]
Author: Ferry Meng <[email protected]>
Date:   Mon May 20 10:40:23 2024 +0800

    ocfs2: add bounds checking to ocfs2_xattr_find_entry()
    
    [ Upstream commit 9e3041fecdc8f78a5900c3aa51d3d756e73264d6 ]
    
    Add a paranoia check to make sure it doesn't stray beyond valid memory
    region containing ocfs2 xattr entries when scanning for a match.  It will
    prevent out-of-bound access in case of crafted images.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ferry Meng <[email protected]>
    Signed-off-by: Joseph Qi <[email protected]>
    Reported-by: lei lu <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Stable-dep-of: af77c4fc1871 ("ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()")
    Signed-off-by: Sasha Levin <[email protected]>

ocfs2: cancel dqi_sync_work before freeing oinfo [+ + +]
Author: Joseph Qi <[email protected]>
Date:   Wed Sep 4 15:10:03 2024 +0800

    ocfs2: cancel dqi_sync_work before freeing oinfo
    
    commit 35fccce29feb3706f649726d410122dd81b92c18 upstream.
    
    ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the
    end, if error occurs after successfully reading global quota, it will
    trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:
    
    ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c
    
    This reports that there is an active delayed work when freeing oinfo in
    error handling, so cancel dqi_sync_work first.  BTW, return status instead
    of -1 when .read_file_info fails.
    
    Link: https://syzkaller.appspot.com/bug?extid=f7af59df5d6b25f0febd
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 171bf93ce11f ("ocfs2: Periodic quota syncing")
    Signed-off-by: Joseph Qi <[email protected]>
    Reviewed-by: Heming Zhao <[email protected]>
    Reported-by: [email protected]
    Tested-by: [email protected]
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ocfs2: fix null-ptr-deref when journal load failed. [+ + +]
Author: Julian Sun <[email protected]>
Date:   Mon Sep 2 11:08:44 2024 +0800

    ocfs2: fix null-ptr-deref when journal load failed.
    
    commit 5784d9fcfd43bd853654bb80c87ef293b9e8e80a upstream.
    
    During the mounting process, if journal_reset() fails because of too short
    journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer.
    Subsequently, ocfs2_journal_shutdown() calls
    jbd2_journal_flush()->jbd2_cleanup_journal_tail()->
    __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()
    ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer
    dereference error.
    
    To resolve this issue, we should check the JBD2_LOADED flag to ensure the
    journal was properly loaded.  Additionally, use journal instead of
    osb->journal directly to simplify the code.
    
    Link: https://syzkaller.appspot.com/bug?extid=05b9b39d8bdfe1a0861f
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: f6f50e28f0cb ("jbd2: Fail to load a journal if it is too short")
    Signed-off-by: Julian Sun <[email protected]>
    Reported-by: [email protected]
    Suggested-by: Joseph Qi <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate [+ + +]
Author: Lizhi Xu <[email protected]>
Date:   Mon Sep 2 10:36:36 2024 +0800

    ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate
    
    commit 33b525cef4cff49e216e4133cc48452e11c0391e upstream.
    
    When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger
    NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if
    bh is NULL.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: cf76c78595ca ("ocfs2: don't put and assigning null to bh allocated outside")
    Signed-off-by: Lizhi Xu <[email protected]>
    Signed-off-by: Joseph Qi <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Reported-by: Heming Zhao <[email protected]>
    Suggested-by: Heming Zhao <[email protected]>
    Cc: <[email protected]>    [4.20+]
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ocfs2: fix the la space leak when unmounting an ocfs2 volume [+ + +]
Author: Heming Zhao <[email protected]>
Date:   Fri Jul 19 19:43:10 2024 +0800

    ocfs2: fix the la space leak when unmounting an ocfs2 volume
    
    commit dfe6c5692fb525e5e90cefe306ee0dffae13d35f upstream.
    
    This bug has existed since the initial OCFS2 code.  The code logic in
    ocfs2_sync_local_to_main() is wrong, as it ignores the last contiguous
    free bits, which causes an OCFS2 volume to lose the last free clusters of
    LA window on each umount command.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Heming Zhao <[email protected]>
    Reviewed-by: Su Yue <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: Heming Zhao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ocfs2: fix uninit-value in ocfs2_get_block() [+ + +]
Author: Joseph Qi <[email protected]>
Date:   Wed Sep 25 17:06:00 2024 +0800

    ocfs2: fix uninit-value in ocfs2_get_block()
    
    commit 2af148ef8549a12f8025286b8825c2833ee6bcb8 upstream.
    
    syzbot reported an uninit-value BUG:
    
    BUG: KMSAN: uninit-value in ocfs2_get_block+0xed2/0x2710 fs/ocfs2/aops.c:159
    ocfs2_get_block+0xed2/0x2710 fs/ocfs2/aops.c:159
    do_mpage_readpage+0xc45/0x2780 fs/mpage.c:225
    mpage_readahead+0x43f/0x840 fs/mpage.c:374
    ocfs2_readahead+0x269/0x320 fs/ocfs2/aops.c:381
    read_pages+0x193/0x1110 mm/readahead.c:160
    page_cache_ra_unbounded+0x901/0x9f0 mm/readahead.c:273
    do_page_cache_ra mm/readahead.c:303 [inline]
    force_page_cache_ra+0x3b1/0x4b0 mm/readahead.c:332
    force_page_cache_readahead mm/internal.h:347 [inline]
    generic_fadvise+0x6b0/0xa90 mm/fadvise.c:106
    vfs_fadvise mm/fadvise.c:185 [inline]
    ksys_fadvise64_64 mm/fadvise.c:199 [inline]
    __do_sys_fadvise64 mm/fadvise.c:214 [inline]
    __se_sys_fadvise64 mm/fadvise.c:212 [inline]
    __x64_sys_fadvise64+0x1fb/0x3a0 mm/fadvise.c:212
    x64_sys_call+0xe11/0x3ba0
    arch/x86/include/generated/asm/syscalls_64.h:222
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    This is because when ocfs2_extent_map_get_blocks() fails, p_blkno is
    uninitialized.  So the error log will trigger the above uninit-value
    access.
    
    The error log is out-of-date since get_blocks() was removed long time ago.
    And the error code will be logged in ocfs2_extent_map_get_blocks() once
    ocfs2_get_cluster() fails, so fix this by only logging inode and block.
    
    Link: https://syzkaller.appspot.com/bug?extid=9709e73bae885b05314b
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
    Signed-off-by: Joseph Qi <[email protected]>
    Reported-by: [email protected]
    Tested-by: [email protected]
    Cc: Heming Zhao <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow [+ + +]
Author: Edward Adam Davis <[email protected]>
Date:   Wed Oct 16 19:43:47 2024 +0800

    ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
    
    [ Upstream commit bc0a2f3a73fcdac651fca64df39306d1e5ebe3b0 ]
    
    Syzbot reported a kernel BUG in ocfs2_truncate_inline.  There are two
    reasons for this: first, the parameter value passed is greater than
    ocfs2_max_inline_data_with_xattr, second, the start and end parameters of
    ocfs2_truncate_inline are "unsigned int".
    
    So, we need to add a sanity check for byte_start and byte_len right before
    ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater
    than ocfs2_max_inline_data_with_xattr return -EINVAL.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 1afc32b95233 ("ocfs2: Write support for inline data")
    Signed-off-by: Edward Adam Davis <[email protected]>
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=81092778aac03460d6b7
    Reviewed-by: Joseph Qi <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Joseph Qi <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ocfs2: remove unreasonable unlock in ocfs2_read_blocks [+ + +]
Author: Lizhi Xu <[email protected]>
Date:   Mon Sep 2 10:36:35 2024 +0800

    ocfs2: remove unreasonable unlock in ocfs2_read_blocks
    
    commit c03a82b4a0c935774afa01fd6d128b444fd930a1 upstream.
    
    Patch series "Misc fixes for ocfs2_read_blocks", v5.
    
    This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix
    the issue reported by syzbot, which detects bad unlock balance in
    ocfs2_read_blocks().  The second patch fixes an issue reported by Heming
    Zhao when reviewing above fix.
    
    
    This patch (of 2):
    
    There was a lock release before exiting, so remove the unreasonable unlock.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: cf76c78595ca ("ocfs2: don't put and assigning null to bh allocated outside")
    Signed-off-by: Lizhi Xu <[email protected]>
    Signed-off-by: Joseph Qi <[email protected]>
    Reviewed-by: Heming Zhao <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=ab134185af9ef88dfed5
    Tested-by: [email protected]
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: <[email protected]>    [4.20+]
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ocfs2: reserve space for inline xattr before attaching reflink tree [+ + +]
Author: Gautham Ananthakrishna <[email protected]>
Date:   Wed Sep 18 06:38:44 2024 +0000

    ocfs2: reserve space for inline xattr before attaching reflink tree
    
    commit 5ca60b86f57a4d9648f68418a725b3a7de2816b0 upstream.
    
    One of our customers reported a crash and a corrupted ocfs2 filesystem.
    The crash was due to the detection of corruption.  Upon troubleshooting,
    the fsck -fn output showed the below corruption
    
    [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,
    but fsck believes the largest valid value is 227.  Clamp the next record value? n
    
    The stat output from the debugfs.ocfs2 showed the following corruption
    where the "Next Free Rec:" had overshot the "Count:" in the root metadata
    block.
    
            Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)
            FS Generation: 904309833 (0x35e6ac49)
            CRC32: 00000000   ECC: 0000
            Type: Regular   Attr: 0x0   Flags: Valid
            Dynamic Features: (0x16) HasXattr InlineXattr Refcounted
            Extended Attributes Block: 0  Extended Attributes Inline Size: 256
            User: 0 (root)   Group: 0 (root)   Size: 281320357888
            Links: 1   Clusters: 141738
            ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024
            atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024
            mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024
            dtime: 0x0 -- Wed Dec 31 17:00:00 1969
            Refcount Block: 2777346
            Last Extblk: 2886943   Orphan Slot: 0
            Sub Alloc Slot: 0   Sub Alloc Bit: 14
            Tree Depth: 1   Count: 227   Next Free Rec: 230
            ## Offset        Clusters       Block#
            0  0             2310           2776351
            1  2310          2139           2777375
            2  4449          1221           2778399
            3  5670          731            2779423
            4  6401          566            2780447
            .......          ....           .......
            .......          ....           .......
    
    The issue was in the reflink workfow while reserving space for inline
    xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the
    time this function is called the reflink tree is already recreated at the
    destination inode from the source inode.  At this point, this function
    reserves space for inline xattrs at the destination inode without even
    checking if there is space at the root metadata block.  It simply reduces
    the l_count from 243 to 227 thereby making space of 256 bytes for inline
    xattr whereas the inode already has extents beyond this index (in this
    case up to 230), thereby causing corruption.
    
    The fix for this is to reserve space for inline metadata at the destination
    inode before the reflink tree gets recreated. The customer has verified the
    fix.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: ef962df057aa ("ocfs2: xattr: fix inlined xattr reflink")
    Signed-off-by: Gautham Ananthakrishna <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry() [+ + +]
Author: Ferry Meng <[email protected]>
Date:   Mon May 20 10:40:24 2024 +0800

    ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
    
    [ Upstream commit af77c4fc1871847b528d58b7fdafb4aa1f6a9262 ]
    
    xattr in ocfs2 maybe 'non-indexed', which saved with additional space
    requested.  It's better to check if the memory is out of bound before
    memcmp, although this possibility mainly comes from crafted poisonous
    images.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ferry Meng <[email protected]>
    Signed-off-by: Joseph Qi <[email protected]>
    Reported-by: lei lu <[email protected]>
    Reviewed-by: Joseph Qi <[email protected]>
    Cc: Changwei Ge <[email protected]>
    Cc: Gang He <[email protected]>
    Cc: Joel Becker <[email protected]>
    Cc: Jun Piao <[email protected]>
    Cc: Junxiao Bi <[email protected]>
    Cc: Mark Fasheh <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
of/irq: Refer to actual buffer size in of_irq_parse_one() [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Tue Aug 20 14:16:53 2024 +0200

    of/irq: Refer to actual buffer size in of_irq_parse_one()
    
    [ Upstream commit 39ab331ab5d377a18fbf5a0e0b228205edfcc7f4 ]
    
    Replace two open-coded calculations of the buffer size by invocations of
    sizeof() on the buffer itself, to make sure the code will always use the
    actual buffer size.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/817c0b9626fd30790fc488c472a3398324cfcc0c.1724156125.git.geert+renesas@glider.be
    Signed-off-by: Rob Herring (Arm) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

of/irq: Support #msi-cells=<0> in of_msi_get_domain [+ + +]
Author: Andrew Jones <[email protected]>
Date:   Sat Aug 17 09:41:08 2024 +0200

    of/irq: Support #msi-cells=<0> in of_msi_get_domain
    
    commit db8e81132cf051843c9a59b46fa5a071c45baeb3 upstream.
    
    An 'msi-parent' property with a single entry and no accompanying
    '#msi-cells' property is considered the legacy definition as opposed
    to its definition after being expanded with commit 126b16e2ad98
    ("Docs: dt: add generic MSI bindings"). However, the legacy
    definition is completely compatible with the current definition and,
    since of_phandle_iterator_next() tolerates missing and present-but-
    zero *cells properties since commit e42ee61017f5 ("of: Let
    of_for_each_phandle fallback to non-negative cell_count"), there's no
    need anymore to special case the legacy definition in
    of_msi_get_domain().
    
    Indeed, special casing has turned out to be harmful, because, as of
    commit 7c025238b47a ("dt-bindings: irqchip: Describe the IMX MU block
    as a MSI controller"), MSI controller DT bindings have started
    specifying '#msi-cells' as a required property (even when the value
    must be zero) as an effort to make the bindings more explicit. But,
    since the special casing of 'msi-parent' only uses the existence of
    '#msi-cells' for its heuristic, and not whether or not it's also
    nonzero, the legacy path is not taken. Furthermore, the path to
    support the new, broader definition isn't taken either since that
    path has been restricted to the platform-msi bus.
    
    But, neither the definition of 'msi-parent' nor the definition of
    '#msi-cells' is platform-msi-specific (the platform-msi bus was just
    the first bus that needed '#msi-cells'), so remove both the special
    casing and the restriction. The code removal also requires changing
    to of_parse_phandle_with_optional_args() in order to ensure the
    legacy (but compatible) use of 'msi-parent' remains supported. This
    not only simplifies the code but also resolves an issue with PCI
    devices finding their MSI controllers on riscv, as the riscv,imsics
    binding requires '#msi-cells=<0>'.
    
    Signed-off-by: Andrew Jones <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Rob Herring (Arm) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
parisc: Fix 64-bit userspace syscall path [+ + +]
Author: Helge Deller <[email protected]>
Date:   Sun Sep 8 00:40:38 2024 +0200

    parisc: Fix 64-bit userspace syscall path
    
    commit d24449864da5838936669618356b0e30ca2999c3 upstream.
    
    Currently the glibc isn't yet ported to 64-bit for hppa, so
    there is no usable userspace available yet.
    But it's possible to manually build a static 64-bit binary
    and run that for testing. One such 64-bit test program is
    available at http://ftp.parisc-linux.org/src/64bit.tar.gz
    and it shows various issues with the existing 64-bit syscall
    path in the kernel.
    This patch fixes those issues.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]      # v4.19+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Fix itlb miss handler for 64-bit programs [+ + +]
Author: Helge Deller <[email protected]>
Date:   Tue Sep 10 18:32:24 2024 +0200

    parisc: Fix itlb miss handler for 64-bit programs
    
    commit 9542130937e9dc707dd7c6b7af73326437da2d50 upstream.
    
    For an itlb miss when executing code above 4 Gb on ILP64 adjust the
    iasq/iaoq in the same way isr/ior was adjusted.  This fixes signal
    delivery for the 64-bit static test program from
    http://ftp.parisc-linux.org/src/64bit.tar.gz.  Note that signals are
    handled by the signal trampoline code in the 64-bit VDSO which is mapped
    into high userspace memory region above 4GB for 64-bit processes.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]      # v4.19+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Fix stack start for ADDR_NO_RANDOMIZE personality [+ + +]
Author: Helge Deller <[email protected]>
Date:   Sat Sep 7 18:28:11 2024 +0200

    parisc: Fix stack start for ADDR_NO_RANDOMIZE personality
    
    commit f31b256994acec6929306dfa86ac29716e7503d6 upstream.
    
    Fix the stack start address calculation for the parisc architecture in
    setup_arg_pages() when address randomization is disabled. When the
    ADDR_NO_RANDOMIZE process personality is disabled there is no need to add
    additional space for the stack.
    Note that this patch touches code inside an #ifdef CONFIG_STACK_GROWSUP hunk,
    which is why only the parisc architecture is affected since it's the
    only Linux architecture where the stack grows upwards.
    
    Without this patch you will find the stack in the middle of some
    mapped libaries and suddenly limited to 6MB instead of 8MB:
    
    root@parisc:~# setarch -R /bin/bash -c "cat /proc/self/maps"
    00010000-00019000 r-xp 00000000 08:05 1182034           /usr/bin/cat
    00019000-0001a000 rwxp 00009000 08:05 1182034           /usr/bin/cat
    0001a000-0003b000 rwxp 00000000 00:00 0                 [heap]
    f90c4000-f9283000 r-xp 00000000 08:05 1573004           /usr/lib/hppa-linux-gnu/libc.so.6
    f9283000-f9285000 r--p 001bf000 08:05 1573004           /usr/lib/hppa-linux-gnu/libc.so.6
    f9285000-f928a000 rwxp 001c1000 08:05 1573004           /usr/lib/hppa-linux-gnu/libc.so.6
    f928a000-f9294000 rwxp 00000000 00:00 0
    f9301000-f9323000 rwxp 00000000 00:00 0                 [stack]
    f98b4000-f98e4000 r-xp 00000000 08:05 1572869           /usr/lib/hppa-linux-gnu/ld.so.1
    f98e4000-f98e5000 r--p 00030000 08:05 1572869           /usr/lib/hppa-linux-gnu/ld.so.1
    f98e5000-f98e9000 rwxp 00031000 08:05 1572869           /usr/lib/hppa-linux-gnu/ld.so.1
    f9ad8000-f9b00000 rw-p 00000000 00:00 0
    f9b00000-f9b01000 r-xp 00000000 00:00 0                 [vdso]
    
    With the patch the stack gets correctly mapped at the end
    of the process memory map:
    
    root@panama:~# setarch -R /bin/bash -c "cat /proc/self/maps"
    00010000-00019000 r-xp 00000000 08:13 16385582          /usr/bin/cat
    00019000-0001a000 rwxp 00009000 08:13 16385582          /usr/bin/cat
    0001a000-0003b000 rwxp 00000000 00:00 0                 [heap]
    fef29000-ff0eb000 r-xp 00000000 08:13 16122400          /usr/lib/hppa-linux-gnu/libc.so.6
    ff0eb000-ff0ed000 r--p 001c2000 08:13 16122400          /usr/lib/hppa-linux-gnu/libc.so.6
    ff0ed000-ff0f2000 rwxp 001c4000 08:13 16122400          /usr/lib/hppa-linux-gnu/libc.so.6
    ff0f2000-ff0fc000 rwxp 00000000 00:00 0
    ff4b4000-ff4e4000 r-xp 00000000 08:13 16121913          /usr/lib/hppa-linux-gnu/ld.so.1
    ff4e4000-ff4e6000 r--p 00030000 08:13 16121913          /usr/lib/hppa-linux-gnu/ld.so.1
    ff4e6000-ff4ea000 rwxp 00032000 08:13 16121913          /usr/lib/hppa-linux-gnu/ld.so.1
    ff6d7000-ff6ff000 rw-p 00000000 00:00 0
    ff6ff000-ff700000 r-xp 00000000 00:00 0                 [vdso]
    ff700000-ff722000 rwxp 00000000 00:00 0                 [stack]
    
    Reported-by: Camm Maguire <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Fixes: d045c77c1a69 ("parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures")
    Fixes: 17d9822d4b4c ("parisc: Consider stack randomization for mmap base only when necessary")
    Cc: [email protected]      # v5.2+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
parport: Proper fix for array out-of-bounds access [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Fri Sep 20 12:32:19 2024 +0200

    parport: Proper fix for array out-of-bounds access
    
    commit 02ac3a9ef3a18b58d8f3ea2b6e46de657bf6c4f9 upstream.
    
    The recent fix for array out-of-bounds accesses replaced sprintf()
    calls blindly with snprintf().  However, since snprintf() returns the
    would-be-printed size, not the actually output size, the length
    calculation can still go over the given limit.
    
    Use scnprintf() instead of snprintf(), which returns the actually
    output letters, for addressing the potential out-of-bounds access
    properly.
    
    Fixes: ab11dac93d2d ("dev/parport: fix the array out-of-bounds risk")
    Cc: [email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PCI: Add ACS quirk for Qualcomm SA8775P [+ + +]
Author: Subramanian Ananthanarayanan <[email protected]>
Date:   Fri Sep 6 10:52:27 2024 +0530

    PCI: Add ACS quirk for Qualcomm SA8775P
    
    [ Upstream commit 026f84d3fa62d215b11cbeb5a5d97df941e93b5c ]
    
    The Qualcomm SA8775P root ports don't advertise an ACS capability, but they
    do provide ACS-like features to disable peer transactions and validate bus
    numbers in requests.
    
    Thus, add an ACS quirk for the SA8775P.
    
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Signed-off-by: Subramanian Ananthanarayanan <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: Add function 0 DMA alias quirk for Glenfly Arise chip [+ + +]
Author: WangYuli <[email protected]>
Date:   Fri Aug 23 17:57:08 2024 +0800

    PCI: Add function 0 DMA alias quirk for Glenfly Arise chip
    
    commit 9246b487ab3c3b5993aae7552b7a4c541cc14a49 upstream.
    
    Add DMA support for audio function of Glenfly Arise chip, which uses
    Requester ID of function 0.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: SiyuLi <[email protected]>
    Signed-off-by: WangYuli <[email protected]>
    [bhelgaas: lower-case hex to match local code, drop unused Device IDs]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: keystone: Fix if-statement expression in ks_pcie_quirk() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Jul 19 18:53:26 2024 -0500

    PCI: keystone: Fix if-statement expression in ks_pcie_quirk()
    
    [ Upstream commit 6188a1c762eb9bbd444f47696eda77a5eae6207a ]
    
    This code accidentally uses && where || was intended.  It potentially
    results in a NULL dereference.
    
    Thus, fix the if-statement expression to use the correct condition.
    
    Fixes: 86f271f22bbb ("PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)")
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Signed-off-by: Dan Carpenter <[email protected]>
    [kwilczynski: commit log]
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Siddharth Vadapalli <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: Mark Creative Labs EMU20k2 INTx masking as broken [+ + +]
Author: Alex Williamson <[email protected]>
Date:   Thu Sep 12 15:53:27 2024 -0600

    PCI: Mark Creative Labs EMU20k2 INTx masking as broken
    
    [ Upstream commit 2910306655a7072640021563ec9501bfa67f0cb1 ]
    
    Per user reports, the Creative Labs EMU20k2 (Sound Blaster X-Fi
    Titanium Series) generates spurious interrupts when used with
    vfio-pci unless DisINTx masking support is disabled.
    
    Thus, quirk the device to mark INTx masking as broken.
    
    Closes: https://lore.kernel.org/all/VI1PR10MB8207C507DB5420AB4C7281E0DB9A2@VI1PR10MB8207.EURPRD10.PROD.OUTLOOK.COM
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Reported-by: zdravko delineshev <[email protected]>
    Signed-off-by: Alex Williamson <[email protected]>
    [kwilczynski: commit log]
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Fri May 31 12:13:32 2024 -0400

    PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler
    
    [ Upstream commit 0199d2f2bd8cd97b310f7ed82a067247d7456029 ]
    
    MSGF_LEG_MASK is laid out with INTA in bit 0, INTB in bit 1, INTC in bit 2,
    and INTD in bit 3. Hardware IRQ numbers start at 0, and we register
    PCI_NUM_INTX IRQs. So to enable INTA (aka hwirq 0) we should set bit 0.
    Remove the subtraction of one.
    
    This bug would cause INTx interrupts not to be delivered, as enabling INTB
    would actually enable INTA, and enabling INTA wouldn't enable anything at
    all. It is likely that this got overlooked for so long since most PCIe
    hardware uses MSIs. This fixes the following UBSAN error:
    
      UBSAN: shift-out-of-bounds in ../drivers/pci/controller/pcie-xilinx-nwl.c:389:11
      shift exponent 18446744073709551615 is too large for 32-bit type 'int'
      CPU: 1 PID: 61 Comm: kworker/u10:1 Not tainted 6.6.20+ #268
      Hardware name: xlnx,zynqmp (DT)
      Workqueue: events_unbound deferred_probe_work_func
      Call trace:
      dump_backtrace (arch/arm64/kernel/stacktrace.c:235)
      show_stack (arch/arm64/kernel/stacktrace.c:242)
      dump_stack_lvl (lib/dump_stack.c:107)
      dump_stack (lib/dump_stack.c:114)
      __ubsan_handle_shift_out_of_bounds (lib/ubsan.c:218 lib/ubsan.c:387)
      nwl_unmask_leg_irq (drivers/pci/controller/pcie-xilinx-nwl.c:389 (discriminator 1))
      irq_enable (kernel/irq/internals.h:234 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)
      __irq_startup (kernel/irq/internals.h:239 kernel/irq/chip.c:180 kernel/irq/chip.c:250)
      irq_startup (kernel/irq/chip.c:270)
      __setup_irq (kernel/irq/manage.c:1800)
      request_threaded_irq (kernel/irq/manage.c:2206)
      pcie_pme_probe (include/linux/interrupt.h:168 drivers/pci/pcie/pme.c:348)
    
    Fixes: 9a181e1093af ("PCI: xilinx-nwl: Modify IRQ chip for legacy interrupts")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Anderson <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>

PCI: xilinx-nwl: Fix register misspelling [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Fri May 31 12:13:33 2024 -0400

    PCI: xilinx-nwl: Fix register misspelling
    
    [ Upstream commit a437027ae1730b8dc379c75fa0dd7d3036917400 ]
    
    MSIC -> MISC
    
    Fixes: c2a7ff18edcd ("PCI: xilinx-nwl: Expand error logging")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Anderson <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: xilinx-nwl: Use irq_data_get_irq_chip_data() [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Thu Dec 10 20:25:54 2020 +0100

    PCI: xilinx-nwl: Use irq_data_get_irq_chip_data()
    
    [ Upstream commit e56427068a8d796bb7b8e297f2b6e947380e383f ]
    
    Going through a full irq descriptor lookup instead of just using the proper
    helper function which provides direct access is suboptimal.
    
    In fact it _is_ wrong because the chip callback needs to get the chip data
    which is relevant for the chip while using the irq descriptor variant
    returns the irq chip data of the top level chip of a hierarchy. It does not
    matter in this case because the chip is the top level chip, but that
    doesn't make it more correct.
    
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Rob Herring <[email protected]>
    Cc: Bjorn Helgaas <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 0199d2f2bd8c ("PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler")
    Signed-off-by: Sasha Levin <[email protected]>

 
perf sched timehist: Fix missing free of session in perf_sched__timehist() [+ + +]
Author: Yang Jihong <[email protected]>
Date:   Tue Aug 6 10:35:33 2024 +0800

    perf sched timehist: Fix missing free of session in perf_sched__timehist()
    
    [ Upstream commit 6bdf5168b6fb19541b0c1862bdaa596d116c7bfb ]
    
    When perf_time__parse_str() fails in perf_sched__timehist(),
    need to free session that was previously created, fix it.
    
    Fixes: 853b74071110bed3 ("perf sched timehist: Add option to specify time window of interest")
    Signed-off-by: Yang Jihong <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: David Ahern <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf sched timehist: Fixed timestamp error when unable to confirm event sched_in time [+ + +]
Author: Yang Jihong <[email protected]>
Date:   Mon Aug 19 10:47:20 2024 +0800

    perf sched timehist: Fixed timestamp error when unable to confirm event sched_in time
    
    [ Upstream commit 39c243411bdb8fb35777adf49ee32549633c4e12 ]
    
    If sched_in event for current task is not recorded, sched_in timestamp
    will be set to end_time of time window interest, causing an error in
    timestamp show. In this case, we choose to ignore this event.
    
    Test scenario:
    
      perf[1229608] does not record the first sched_in event, run time and sch delay are both 0
    
      # perf sched timehist
      Samples of sched_switch event do not have callchains.
                 time    cpu  task name                       wait time  sch delay   run time
                              [tid/pid]                          (msec)     (msec)     (msec)
      --------------- ------  ------------------------------  ---------  ---------  ---------
       2090450.763231 [0000]  perf[1229608]                       0.000      0.000      0.000
       2090450.763235 [0000]  migration/0[15]                     0.000      0.001      0.003
       2090450.763263 [0001]  perf[1229608]                       0.000      0.000      0.000
       2090450.763268 [0001]  migration/1[21]                     0.000      0.001      0.004
       2090450.763302 [0002]  perf[1229608]                       0.000      0.000      0.000
       2090450.763309 [0002]  migration/2[27]                     0.000      0.001      0.007
       2090450.763338 [0003]  perf[1229608]                       0.000      0.000      0.000
       2090450.763343 [0003]  migration/3[33]                     0.000      0.001      0.004
    
    Before:
    
      arbitrarily specify a time window of interest, timestamp will be set to an incorrect value
    
      # perf sched timehist --time 100,200
      Samples of sched_switch event do not have callchains.
                 time    cpu  task name                       wait time  sch delay   run time
                              [tid/pid]                          (msec)     (msec)     (msec)
      --------------- ------  ------------------------------  ---------  ---------  ---------
           200.000000 [0000]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0001]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0002]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0003]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0004]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0005]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0006]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0007]  perf[1229608]                       0.000      0.000      0.000
    
     After:
    
      # perf sched timehist --time 100,200
      Samples of sched_switch event do not have callchains.
                 time    cpu  task name                       wait time  sch delay   run time
                              [tid/pid]                          (msec)     (msec)     (msec)
      --------------- ------  ------------------------------  ---------  ---------  ---------
    
    Fixes: 853b74071110bed3 ("perf sched timehist: Add option to specify time window of interest")
    Signed-off-by: Yang Jihong <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: David Ahern <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf time-utils: Fix 32-bit nsec parsing [+ + +]
Author: Ian Rogers <[email protected]>
Date:   Sat Aug 31 00:04:11 2024 -0700

    perf time-utils: Fix 32-bit nsec parsing
    
    [ Upstream commit 38e2648a81204c9fc5b4c87a8ffce93a6ed91b65 ]
    
    The "time utils" test fails in 32-bit builds:
      ...
      parse_nsec_time("18446744073.709551615")
      Failed. ptime 4294967295709551615 expected 18446744073709551615
      ...
    
    Switch strtoul to strtoull as an unsigned long in 32-bit build isn't
    64-bits.
    
    Fixes: c284d669a20d408b ("perf tools: Move parse_nsec_time to time-utils.c")
    Signed-off-by: Ian Rogers <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Athira Rajeev <[email protected]>
    Cc: Chaitanya S Prakash <[email protected]>
    Cc: Colin Ian King <[email protected]>
    Cc: David Ahern <[email protected]>
    Cc: Dominique Martinet <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: John Garry <[email protected]>
    Cc: Junhao He <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Yang Jihong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/core: Fix small negative period being ignored [+ + +]
Author: Luo Gengkun <[email protected]>
Date:   Sat Aug 31 07:43:15 2024 +0000

    perf/core: Fix small negative period being ignored
    
    commit 62c0b1061593d7012292f781f11145b2d46f43ab upstream.
    
    In perf_adjust_period, we will first calculate period, and then use
    this period to calculate delta. However, when delta is less than 0,
    there will be a deviation compared to when delta is greater than or
    equal to 0. For example, when delta is in the range of [-14,-1], the
    range of delta = delta + 7 is between [-7,6], so the final value of
    delta/8 is 0. Therefore, the impact of -1 and -2 will be ignored.
    This is unacceptable when the target period is very short, because
    we will lose a lot of samples.
    
    Here are some tests and analyzes:
    before:
      # perf record -e cs -F 1000  ./a.out
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.022 MB perf.data (518 samples) ]
    
      # perf script
      ...
      a.out     396   257.956048:         23 cs:  ffffffff81f4eeec schedul>
      a.out     396   257.957891:         23 cs:  ffffffff81f4eeec schedul>
      a.out     396   257.959730:         23 cs:  ffffffff81f4eeec schedul>
      a.out     396   257.961545:         23 cs:  ffffffff81f4eeec schedul>
      a.out     396   257.963355:         23 cs:  ffffffff81f4eeec schedul>
      a.out     396   257.965163:         23 cs:  ffffffff81f4eeec schedul>
      a.out     396   257.966973:         23 cs:  ffffffff81f4eeec schedul>
      a.out     396   257.968785:         23 cs:  ffffffff81f4eeec schedul>
      a.out     396   257.970593:         23 cs:  ffffffff81f4eeec schedul>
      ...
    
    after:
      # perf record -e cs -F 1000  ./a.out
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.058 MB perf.data (1466 samples) ]
    
      # perf script
      ...
      a.out     395    59.338813:         11 cs:  ffffffff81f4eeec schedul>
      a.out     395    59.339707:         12 cs:  ffffffff81f4eeec schedul>
      a.out     395    59.340682:         13 cs:  ffffffff81f4eeec schedul>
      a.out     395    59.341751:         13 cs:  ffffffff81f4eeec schedul>
      a.out     395    59.342799:         12 cs:  ffffffff81f4eeec schedul>
      a.out     395    59.343765:         11 cs:  ffffffff81f4eeec schedul>
      a.out     395    59.344651:         11 cs:  ffffffff81f4eeec schedul>
      a.out     395    59.345539:         12 cs:  ffffffff81f4eeec schedul>
      a.out     395    59.346502:         13 cs:  ffffffff81f4eeec schedul>
      ...
    
    test.c
    
    int main() {
            for (int i = 0; i < 20000; i++)
                    usleep(10);
    
            return 0;
    }
    
      # time ./a.out
      real    0m1.583s
      user    0m0.040s
      sys     0m0.298s
    
    The above results were tested on x86-64 qemu with KVM enabled using
    test.c as test program. Ideally, we should have around 1500 samples,
    but the previous algorithm had only about 500, whereas the modified
    algorithm now has about 1400. Further more, the new version shows 1
    sample per 0.001s, while the previous one is 1 sample per 0.002s.This
    indicates that the new algorithm is more sensitive to small negative
    values compared to old algorithm.
    
    Fixes: bd2b5b12849a ("perf_counter: More aggressive frequency adjustment")
    Signed-off-by: Luo Gengkun <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Adrian Hunter <[email protected]>
    Reviewed-by: Kan Liang <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
pinctrl: at91: make it work with current gpiolib [+ + +]
Author: Thomas Blocher <[email protected]>
Date:   Wed Jul 31 01:16:26 2024 +0200

    pinctrl: at91: make it work with current gpiolib
    
    [ Upstream commit 752f387faaae0ae2e84d3f496922524785e77d60 ]
    
    pinctrl-at91 currently does not support the gpio-groups devicetree
    property and has no pin-range.
    Because of this at91 gpios stopped working since patch
    commit 2ab73c6d8323fa1e ("gpio: Support GPIO controllers without pin-ranges")
    This was discussed in the patches
    commit fc328a7d1fcce263 ("gpio: Revert regression in sysfs-gpio (gpiolib.c)")
    commit 56e337f2cf132632 ("Revert "gpio: Revert regression in sysfs-gpio (gpiolib.c)"")
    
    As a workaround manually set pin-range via gpiochip_add_pin_range() until
    a) pinctrl-at91 is reworked to support devicetree gpio-groups
    b) another solution as mentioned in
    commit 56e337f2cf132632 ("Revert "gpio: Revert regression in sysfs-gpio (gpiolib.c)"")
    is found
    
    Signed-off-by: Thomas Blocher <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function [+ + +]
Author: Wang Jianzheng <[email protected]>
Date:   Thu Aug 29 14:48:23 2024 +0800

    pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function
    
    [ Upstream commit c25478419f6fd3f74c324a21ec007cf14f2688d7 ]
    
    When an error occurs during the execution of the function
    __devinit_dove_pinctrl_probe, the clk is not properly disabled.
    
    Fix this by calling clk_disable_unprepare before return.
    
    Fixes: ba607b6238a1 ("pinctrl: mvebu: make pdma clock on dove mandatory")
    Signed-off-by: Wang Jianzheng <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: single: fix missing error code in pcs_probe() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Mon Aug 19 10:46:25 2024 +0800

    pinctrl: single: fix missing error code in pcs_probe()
    
    [ Upstream commit cacd8cf79d7823b07619865e994a7916fcc8ae91 ]
    
    If pinctrl_enable() fails in pcs_probe(), it should return the error code.
    
    Fixes: 8f773bfbdd42 ("pinctrl: single: fix possible memory leak when pinctrl_enable() fails")
    Signed-off-by: Yang Yingliang <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
posix-clock: Fix missing timespec64 check in pc_clock_settime() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Wed Oct 9 15:23:01 2024 +0800

    posix-clock: Fix missing timespec64 check in pc_clock_settime()
    
    commit d8794ac20a299b647ba9958f6d657051fc51a540 upstream.
    
    As Andrew pointed out, it will make sense that the PTP core
    checked timespec64 struct's tv_sec and tv_nsec range before calling
    ptp->info->settime64().
    
    As the man manual of clock_settime() said, if tp.tv_sec is negative or
    tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
    which include dynamic clocks which handles PTP clock, and the condition is
    consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
    only check the timespec is valid, but not ensure that the time is
    in a valid range, so check it ahead using timespec64_valid_strict()
    in pc_clock_settime() and return -EINVAL if not valid.
    
    There are some drivers that use tp->tv_sec and tp->tv_nsec directly to
    write registers without validity checks and assume that the higher layer
    has checked it, which is dangerous and will benefit from this, such as
    hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
    and some drivers can remove the checks of itself.
    
    Cc: [email protected]
    Fixes: 0606f422b453 ("posix clocks: Introduce dynamic clocks")
    Acked-by: Richard Cochran <[email protected]>
    Suggested-by: Andrew Lunn <[email protected]>
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Fri Oct 18 18:07:48 2024 +0800

    posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()
    
    [ Upstream commit 6e62807c7fbb3c758d233018caf94dfea9c65dbd ]
    
    If get_clock_desc() succeeds, it calls fget() for the clockid's fd,
    and get the clk->rwsem read lock, so the error path should release
    the lock to make the lock balance and fput the clockid's fd to make
    the refcount balance and release the fd related resource.
    
    However the below commit left the error path locked behind resulting in
    unbalanced locking. Check timespec64_valid_strict() before
    get_clock_desc() to fix it, because the "ts" is not changed
    after that.
    
    Fixes: d8794ac20a29 ("posix-clock: Fix missing timespec64 check in pc_clock_settime()")
    Acked-by: Richard Cochran <[email protected]>
    Signed-off-by: Jinjie Ruan <[email protected]>
    Acked-by: Anna-Maria Behnsen <[email protected]>
    [[email protected]: fixed commit message typo]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
power: reset: brcmstb: Do not go into infinite loop if reset fails [+ + +]
Author: Andrew Davis <[email protected]>
Date:   Mon Jun 10 09:28:36 2024 -0500

    power: reset: brcmstb: Do not go into infinite loop if reset fails
    
    [ Upstream commit cf8c39b00e982fa506b16f9d76657838c09150cb ]
    
    There may be other backup reset methods available, do not halt
    here so that other reset methods can be tried.
    
    Signed-off-by: Andrew Davis <[email protected]>
    Reviewed-by: Dhruva Gole <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: axp20x_battery: allow disabling battery charging [+ + +]
Author: Hermann Lauer <[email protected]>
Date:   Wed May 12 12:58:56 2021 +0200

    power: supply: axp20x_battery: allow disabling battery charging
    
    [ Upstream commit 6a0fcc87c9e35191d37a8819fdab9d30e523515b ]
    
    Allow disabling and re-enabling battery charging of an axp209 PMIC
    through a writable status property. With the current driver code
    charging is always on.
    
    This works on the axp209 of Banana {Pi M1+,Pro} and should work on all
    AXP chips.
    
    Signed-off-by: [email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Stable-dep-of: 61978807b00f ("power: supply: axp20x_battery: Remove design from min and max voltage")
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: axp20x_battery: Remove design from min and max voltage [+ + +]
Author: Chris Morgan <[email protected]>
Date:   Wed Aug 21 16:54:43 2024 -0500

    power: supply: axp20x_battery: Remove design from min and max voltage
    
    [ Upstream commit 61978807b00f8a1817b0e5580981af1cd2f428a5 ]
    
    The POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN and
    POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN values should be immutable
    properties of the battery, but for this driver they are writable values
    and used as the minimum and maximum values for charging. Remove the
    DESIGN designation from these values.
    
    Fixes: 46c202b5f25f ("power: supply: add battery driver for AXP20X and AXP22X PMICs")
    Suggested-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Chris Morgan <[email protected]>
    Acked-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense [+ + +]
Author: Artur Weber <[email protected]>
Date:   Sat Aug 17 12:51:14 2024 +0200

    power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense
    
    [ Upstream commit 3a3acf839b2cedf092bdd1ff65b0e9895df1656b ]
    
    Commit 223a3b82834f ("power: supply: max17042_battery: use VFSOC for
    capacity when no rsns") made it so that capacity on systems without
    current sensing would be read from VFSOC instead of RepSOC. However,
    the SOC threshold calculation still read RepSOC to get the SOC
    regardless of the current sensing option state.
    
    Fix this by applying the same conditional to determine which register
    should be read.
    
    This also seems to be the intended behavior as per the datasheet - SOC
    alert config value in MiscCFG on setups without current sensing is set
    to a value of 0b11, indicating SOC alerts being generated based on
    VFSOC, instead of 0b00 which indicates SOC alerts being generated based
    on RepSOC.
    
    This fixes an issue on the Galaxy S3/Midas boards, where the alert
    interrupt would be constantly retriggered, causing high CPU usage
    on idle (around ~12%-15%).
    
    Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC")
    Signed-off-by: Artur Weber <[email protected]>
    Reviewed-by: Henrik Grimler <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ppp: fix ppp_async_encode() illegal access [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Oct 9 18:58:02 2024 +0000

    ppp: fix ppp_async_encode() illegal access
    
    [ Upstream commit 40dddd4b8bd08a69471efd96107a4e1c73fabefc ]
    
    syzbot reported an issue in ppp_async_encode() [1]
    
    In this case, pppoe_sendmsg() is called with a zero size.
    Then ppp_async_encode() is called with an empty skb.
    
    BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
     BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
      ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
      ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
      ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634
      ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]
      ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304
      pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
      sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
      __release_sock+0x1da/0x330 net/core/sock.c:3072
      release_sock+0x6b/0x250 net/core/sock.c:3626
      pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
      sock_sendmsg_nosec net/socket.c:729 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:744
      ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
      ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
      __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
      __do_sys_sendmmsg net/socket.c:2771 [inline]
      __se_sys_sendmmsg net/socket.c:2768 [inline]
      __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
      x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was created at:
      slab_post_alloc_hook mm/slub.c:4092 [inline]
      slab_alloc_node mm/slub.c:4135 [inline]
      kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187
      kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
      __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
      alloc_skb include/linux/skbuff.h:1322 [inline]
      sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
      pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
      sock_sendmsg_nosec net/socket.c:729 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:744
      ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
      ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
      __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
      __do_sys_sendmmsg net/socket.c:2771 [inline]
      __se_sys_sendmmsg net/socket.c:2768 [inline]
      __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
      x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: [email protected]
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pps: add an error check in parport_attach [+ + +]
Author: Ma Ke <[email protected]>
Date:   Wed Aug 28 21:18:14 2024 +0800

    pps: add an error check in parport_attach
    
    [ Upstream commit 62c5a01a5711c8e4be8ae7b6f0db663094615d48 ]
    
    In parport_attach, the return value of ida_alloc is unchecked, witch leads
    to the use of an invalid index value.
    
    To address this issue, index should be checked. When the index value is
    abnormal, the device should be freed.
    
    Found by code review, compile tested only.
    
    Cc: [email protected]
    Fixes: fb56d97df70e ("pps: client: use new parport device model")
    Signed-off-by: Ma Ke <[email protected]>
    Acked-by: Rodolfo Giometti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pps: remove usage of the deprecated ida_simple_xx() API [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Apr 14 12:10:17 2024 +0200

    pps: remove usage of the deprecated ida_simple_xx() API
    
    [ Upstream commit 55dbc5b5174d0e7d1fa397d05aa4cb145e8b887e ]
    
    ida_alloc() and ida_free() should be preferred to the deprecated
    ida_simple_get() and ida_simple_remove().
    
    This is less verbose.
    
    Link: https://lkml.kernel.org/r/9f681747d446b874952a892491387d79ffe565a9.1713089394.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Christophe JAILLET <[email protected]>
    Cc: Rodolfo Giometti <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Stable-dep-of: 62c5a01a5711 ("pps: add an error check in parport_attach")
    Signed-off-by: Sasha Levin <[email protected]>

 
proc: add config & param to block forcing mem writes [+ + +]
Author: Adrian Ratiu <[email protected]>
Date:   Fri Aug 2 11:02:25 2024 +0300

    proc: add config & param to block forcing mem writes
    
    [ Upstream commit 41e8149c8892ed1962bd15350b3c3e6e90cba7f4 ]
    
    This adds a Kconfig option and boot param to allow removing
    the FOLL_FORCE flag from /proc/pid/mem write calls because
    it can be abused.
    
    The traditional forcing behavior is kept as default because
    it can break GDB and some other use cases.
    
    Previously we tried a more sophisticated approach allowing
    distributions to fine-tune /proc/pid/mem behavior, however
    that got NAK-ed by Linus [1], who prefers this simpler
    approach with semantics also easier to understand for users.
    
    Link: https://lore.kernel.org/lkml/CAHk-=wiGWLChxYmUA5HrT5aopZrB7_2VTa0NLZcxORgkUe5tEQ@mail.gmail.com/ [1]
    Cc: Doug Anderson <[email protected]>
    Cc: Jeff Xu <[email protected]>
    Cc: Jann Horn <[email protected]>
    Cc: Kees Cook <[email protected]>
    Cc: Ard Biesheuvel <[email protected]>
    Cc: Christian Brauner <[email protected]>
    Suggested-by: Linus Torvalds <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Adrian Ratiu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
r8169: add tally counter fields added with RTL8125 [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Tue Sep 17 23:04:46 2024 +0200

    r8169: add tally counter fields added with RTL8125
    
    [ Upstream commit ced8e8b8f40accfcce4a2bbd8b150aa76d5eff9a ]
    
    RTL8125 added fields to the tally counter, what may result in the chip
    dma'ing these new fields to unallocated memory. Therefore make sure
    that the allocated memory area is big enough to hold all of the
    tally counter values, even if we use only parts of it.
    
    Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125")
    Cc: [email protected]
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

r8169: avoid unsolicited interrupts [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Fri Oct 18 11:08:16 2024 +0200

    r8169: avoid unsolicited interrupts
    
    [ Upstream commit 10ce0db787004875f4dba068ea952207d1d8abeb ]
    
    It was reported that after resume from suspend a PCI error is logged
    and connectivity is broken. Error message is:
    PCI error (cmd = 0x0407, status_errs = 0x0000)
    The message seems to be a red herring as none of the error bits is set,
    and the PCI command register value also is normal. Exception handling
    for a PCI error includes a chip reset what apparently brakes connectivity
    here. The interrupt status bit triggering the PCI error handling isn't
    actually used on PCIe chip versions, so it's not clear why this bit is
    set by the chip. Fix this by ignoring this bit on PCIe chip versions.
    
    Fixes: 0e4851502f84 ("r8169: merge with version 8.001.00 of Realtek's r8168 driver")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219388
    Tested-by: Atlas Yu <[email protected]>
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

r8169: Fix spelling mistake: "tx_underun" -> "tx_underrun" [+ + +]
Author: Colin Ian King <[email protected]>
Date:   Mon Sep 9 15:00:21 2024 +0100

    r8169: Fix spelling mistake: "tx_underun" -> "tx_underrun"
    
    [ Upstream commit 8df9439389a44fb2cc4ef695e08d6a8870b1616c ]
    
    There is a spelling mistake in the struct field tx_underun, rename
    it to tx_underrun.
    
    Signed-off-by: Colin Ian King <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Heiner Kallweit <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: ced8e8b8f40a ("r8169: add tally counter fields added with RTL8125")
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/bnxt_re: Fix incorrect AVID type in WQE structure [+ + +]
Author: Saravanan Vajravel <[email protected]>
Date:   Wed Sep 18 20:05:57 2024 -0700

    RDMA/bnxt_re: Fix incorrect AVID type in WQE structure
    
    [ Upstream commit 9ab20f76ae9fad55ebaf36bdff04aea1c2552374 ]
    
    Driver uses internal data structure to construct WQE frame.
    It used avid type as u16 which can accommodate up to 64K AVs.
    When outstanding AVID crosses 64K, driver truncates AVID and
    hence it uses incorrect AVID to WR. This leads to WR failure
    due to invalid AV ID and QP is moved to error state with reason
    set to 19 (INVALID AVID). When RDMA CM path is used, this issue
    hits QP1 and it is moved to error state
    
    Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver")
    Link: https://patch.msgid.link/r/[email protected]
    Reviewed-by: Selvin Xavier <[email protected]>
    Reviewed-by: Chandramohan Akula <[email protected]>
    Signed-off-by: Saravanan Vajravel <[email protected]>
    Signed-off-by: Kalesh AP <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/bnxt_re: Return more meaningful error [+ + +]
Author: Kalesh AP <[email protected]>
Date:   Tue Oct 8 00:41:36 2024 -0700

    RDMA/bnxt_re: Return more meaningful error
    
    [ Upstream commit 98647df0178df215b8239c5c365537283b2852a6 ]
    
    When the HWRM command fails, driver currently returns -EFAULT(Bad
    address). This does not look correct.
    
    Modified to return -EIO(I/O error).
    
    Fixes: cc1ec769b87c ("RDMA/bnxt_re: Fixing the Control path command and response handling")
    Fixes: 65288a22ddd8 ("RDMA/bnxt_re: use shadow qd while posting non blocking rcfw command")
    Link: https://patch.msgid.link/r/[email protected]
    Signed-off-by: Kalesh AP <[email protected]>
    Signed-off-by: Selvin Xavier <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/cxgb4: Added NULL check for lookup_atid [+ + +]
Author: Mikhail Lobanov <[email protected]>
Date:   Thu Sep 12 10:58:39 2024 -0400

    RDMA/cxgb4: Added NULL check for lookup_atid
    
    [ Upstream commit e766e6a92410ca269161de059fff0843b8ddd65f ]
    
    The lookup_atid() function can return NULL if the ATID is
    invalid or does not exist in the identifier table, which
    could lead to dereferencing a null pointer without a
    check in the `act_establish()` and `act_open_rpl()` functions.
    Add a NULL check to prevent null pointer dereferencing.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: cfdda9d76436 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC")
    Signed-off-by: Mikhail Lobanov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP [+ + +]
Author: Anumula Murali Mohan Reddy <[email protected]>
Date:   Mon Oct 7 18:53:11 2024 +0530

    RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP
    
    [ Upstream commit c659b405b82ead335bee6eb33f9691bf718e21e8 ]
    
    ip_dev_find() always returns real net_device address, whether traffic is
    running on a vlan or real device, if traffic is over vlan, filling
    endpoint struture with real ndev and an attempt to send a connect request
    will results in RDMA_CM_EVENT_UNREACHABLE error.  This patch fixes the
    issue by using vlan_dev_real_dev().
    
    Fixes: 830662f6f032 ("RDMA/cxgb4: Add support for active and passive open connection with IPv6 address")
    Link: https://patch.msgid.link/r/[email protected]
    Signed-off-by: Anumula Murali Mohan Reddy <[email protected]>
    Signed-off-by: Potnuri Bharat Teja <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/hns: Optimize hem allocation performance [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Fri Sep 6 17:34:43 2024 +0800

    RDMA/hns: Optimize hem allocation performance
    
    [ Upstream commit fe51f6254d81f5a69c31df16353d6539b2b51630 ]
    
    When allocating MTT hem, for each hop level of each hem that is being
    allocated, the driver iterates the hem list to find out whether the
    bt page has been allocated in this hop level. If not, allocate a new
    one and splice it to the list. The time complexity is O(n^2) in worst
    cases.
    
    Currently the allocation for-loop uses 'unit' as the step size. This
    actually has taken into account the reuse of last-hop-level MTT bt
    pages by multiple buffer pages. Thus pages of last hop level will
    never have been allocated, so there is no need to iterate the hem list
    in last hop level.
    
    Removing this unnecessary iteration can reduce the time complexity to
    O(n).
    
    Fixes: 38389eaa4db1 ("RDMA/hns: Add mtr support for mixed multihop addressing")
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency [+ + +]
Author: Zhu Yanjun <[email protected]>
Date:   Tue Aug 20 13:33:36 2024 +0200

    RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency
    
    [ Upstream commit 86dfdd8288907f03c18b7fb462e0e232c4f98d89 ]
    
    In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to
    destroying CM IDs"), the function flush_workqueue is invoked to flush the
    work queue iwcm_wq.
    
    But at that time, the work queue iwcm_wq was created via the function
    alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.
    
    Because the current process is trying to flush the whole iwcm_wq, if
    iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current
    process is not reclaiming memory or running on a workqueue which doesn't
    have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee
    leading to a deadlock.
    
    The call trace is as below:
    
    [  125.350876][ T1430] Call Trace:
    [  125.356281][ T1430]  <TASK>
    [ 125.361285][ T1430] ? __warn (kernel/panic.c:693)
    [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
    [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)
    [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)
    [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
    [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)
    [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
    [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
    [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)
    [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)
    [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm
    [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)
    [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
    [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)
    [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm
    [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma
    [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma
    [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)
    [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)
    [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)
    [ 125.531837][ T1430] kthread (kernel/kthread.c:389)
    [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
    [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)
    [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
    [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
    [  125.566487][ T1430]  </TASK>
    [  125.566488][ T1430] ---[ end trace 0000000000000000 ]---
    
    Fixes: aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs")
    Link: https://patch.msgid.link/r/[email protected]
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Tested-by: kernel test robot <[email protected]>
    Signed-off-by: Zhu Yanjun <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt [+ + +]
Author: Bob Pearson <[email protected]>
Date:   Fri Mar 29 09:55:04 2024 -0500

    RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
    
    commit 2b23b6097303ed0ba5f4bc036a1c07b6027af5c6 upstream.
    
    In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the
    resp_pkts queue and then a decision is made whether to run the completer
    task inline or schedule it. Finally the skb is dereferenced to bump a 'hw'
    performance counter. This is wrong because if the completer task is
    already running in a separate thread it may have already processed the skb
    and freed it which can cause a seg fault.  This has been observed
    infrequently in testing at high scale.
    
    This patch fixes this by changing the order of enqueuing the packet until
    after the counter is accessed.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bob Pearson <[email protected]>
    Fixes: 0b1e5b99a48b ("IB/rxe: Add port protocol stats")
    Signed-off-by: Jason Gunthorpe <[email protected]>
    [Sherry: bp to fix CVE-2024-38544. Fix conflict due to missing commit:
    dccb23f6c312 ("RDMA/rxe: Split rxe_run_task() into two subroutines")
    which is not necessary to backport]
    Signed-off-by: Sherry Yang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Remove *.orig pattern from .gitignore [+ + +]
Author: Laurent Pinchart <[email protected]>
Date:   Mon Jul 29 18:57:38 2024 +0300

    Remove *.orig pattern from .gitignore
    
    commit 76be4f5a784533c71afbbb1b8f2963ef9e2ee258 upstream.
    
    Commit 3f1b0e1f2875 (".gitignore update") added *.orig and *.rej
    patterns to .gitignore in v2.6.23. The commit message didn't give a
    rationale. Later on, commit 1f5d3a6b6532 ("Remove *.rej pattern from
    .gitignore") removed the *.rej pattern in v2.6.26, on the rationale that
    *.rej files indicated something went really wrong and should not be
    ignored.
    
    The *.rej files are now shown by `git status`, which helps located
    conflicts when applying patches and lowers the probability that they
    will go unnoticed. It is however still easy to overlook the *.orig files
    which slowly polute the source tree. That's not as big of a deal as not
    noticing a conflict, but it's still not nice.
    
    Drop the *.orig pattern from .gitignore to avoid this and help keep the
    source tree clean.
    
    Signed-off-by: Laurent Pinchart <[email protected]>
    [[email protected]:
    I do not have a strong opinion about this. Perhaps some people may have
    a different opinion.
    
    If you are someone who wants to ignore *.orig, it is likely you would
    want to do so across all projects. Then, $XDG_CONFIG_HOME/git/ignore
    would be more suitable for your needs. gitignore(5) suggests, "Patterns
    which a user wants Git to ignore in all situations generally go into a
    file specified by core.excludesFile in the user's ~/.gitconfig".
    
    Please note that you cannot do the opposite; if *.orig is ignored by
    the project's .gitignore, you cannot override the decision because
    $XDG_CONFIG_HOME/git/ignore has a lower priority.
    
    If *.orig is sitting on the fence, I'd leave it to the users. ]
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
reset: berlin: fix OF node leak in probe() error path [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 16:14:24 2024 +0200

    reset: berlin: fix OF node leak in probe() error path
    
    [ Upstream commit 5f58a88cc91075be38cec69b7cb70aaa4ba69e8b ]
    
    Driver is leaking OF node reference on memory allocation failure.
    Acquire the OF node reference after memory allocation to fix this and
    keep it simple.
    
    Fixes: aed6f3cadc86 ("reset: berlin: convert to a platform driver")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Philipp Zabel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
resource: fix region_intersects() vs add_memory_driver_managed() [+ + +]
Author: Huang Ying <[email protected]>
Date:   Fri Sep 6 11:07:11 2024 +0800

    resource: fix region_intersects() vs add_memory_driver_managed()
    
    commit b4afe4183ec77f230851ea139d91e5cf2644c68b upstream.
    
    On a system with CXL memory, the resource tree (/proc/iomem) related to
    CXL memory may look like something as follows.
    
    490000000-50fffffff : CXL Window 0
      490000000-50fffffff : region0
        490000000-50fffffff : dax0.0
          490000000-50fffffff : System RAM (kmem)
    
    Because drivers/dax/kmem.c calls add_memory_driver_managed() during
    onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL
    Window X".  This confuses region_intersects(), which expects all "System
    RAM" resources to be at the top level of iomem_resource.  This can lead to
    bugs.
    
    For example, when the following command line is executed to write some
    memory in CXL memory range via /dev/mem,
    
     $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1
     dd: error writing '/dev/mem': Bad address
     1+0 records in
     0+0 records out
     0 bytes copied, 0.0283507 s, 0.0 kB/s
    
    the command fails as expected.  However, the error code is wrong.  It
    should be "Operation not permitted" instead of "Bad address".  More
    seriously, the /dev/mem permission checking in devmem_is_allowed() passes
    incorrectly.  Although the accessing is prevented later because ioremap()
    isn't allowed to map system RAM, it is a potential security issue.  During
    command executing, the following warning is reported in the kernel log for
    calling ioremap() on system RAM.
    
     ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff
     WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d
     Call Trace:
      memremap+0xcb/0x184
      xlate_dev_mem_ptr+0x25/0x2f
      write_mem+0x94/0xfb
      vfs_write+0x128/0x26d
      ksys_write+0xac/0xfe
      do_syscall_64+0x9a/0xfd
      entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    The details of command execution process are as follows.  In the above
    resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a
    top level resource.  So, region_intersects() will report no System RAM
    resources in the CXL memory region incorrectly, because it only checks the
    top level resources.  Consequently, devmem_is_allowed() will return 1
    (allow access via /dev/mem) for CXL memory region incorrectly.
    Fortunately, ioremap() doesn't allow to map System RAM and reject the
    access.
    
    So, region_intersects() needs to be fixed to work correctly with the
    resource tree with "System RAM" not at top level as above.  To fix it, if
    we found a unmatched resource in the top level, we will continue to search
    matched resources in its descendant resources.  So, we will not miss any
    matched resources in resource tree anymore.
    
    In the new implementation, an example resource tree
    
    |------------- "CXL Window 0" ------------|
    |-- "System RAM" --|
    
    will behave similar as the following fake resource tree for
    region_intersects(, IORESOURCE_SYSTEM_RAM, ),
    
    |-- "System RAM" --||-- "CXL Window 0a" --|
    
    Where "CXL Window 0a" is part of the original "CXL Window 0" that
    isn't covered by "System RAM".
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM")
    Signed-off-by: "Huang, Ying" <[email protected]>
    Cc: Dan Williams <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Davidlohr Bueso <[email protected]>
    Cc: Jonathan Cameron <[email protected]>
    Cc: Dave Jiang <[email protected]>
    Cc: Alison Schofield <[email protected]>
    Cc: Vishal Verma <[email protected]>
    Cc: Ira Weiny <[email protected]>
    Cc: Alistair Popple <[email protected]>
    Cc: Andy Shevchenko <[email protected]>
    Cc: Bjorn Helgaas <[email protected]>
    Cc: Baoquan He <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "driver core: Fix uevent_show() vs driver detach race" [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue Oct 29 01:23:04 2024 +0100

    Revert "driver core: Fix uevent_show() vs driver detach race"
    
    commit 9a71892cbcdb9d1459c84f5a4c722b14354158a5 upstream.
    
    This reverts commit 15fffc6a5624b13b428bb1c6e9088e32a55eb82c.
    
    This commit causes a regression, so revert it for now until it can come
    back in a way that works for everyone.
    
    Link: https://lore.kernel.org/all/172790598832.1168608.4519484276671503678.stgit@dwillia2-xfh.jf.intel.com/
    Fixes: 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")
    Cc: stable <[email protected]>
    Cc: Ashish Sangwan <[email protected]>
    Cc: Namjae Jeon <[email protected]>
    Cc: Dirk Behme <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Rafael J. Wysocki <[email protected]>
    Cc: Dan Williams <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "drm/mipi-dsi: Set the fwnode for mipi_dsi_device" [+ + +]
Author: Jason-JH.Lin <[email protected]>
Date:   Tue Oct 29 09:24:53 2024 +0800

    Revert "drm/mipi-dsi: Set the fwnode for mipi_dsi_device"
    
    This reverts commit 22b8ac608af5b8a859ed9dc0b15f31dea26cdbb0 which is
    commit a26cc2934331b57b5a7164bff344f0a2ec245fc0 upstream.
    
    Reason for revert:
    1. The commit [1] does not land on linux-5.15, so this patch does not
    fix anything.
    
    2. Since the fw_devlink improvements series [2] does not land on
    linux-5.15, using device_set_fwnode() causes the panel to flash during
    bootup.
    
    Incorrect link management may lead to incorrect device initialization,
    affecting firmware node links and consumer relationships.
    The fwnode setting of panel to the DSI device would cause a DSI
    initialization error without series[2], so this patch was reverted to
    avoid using the incomplete fw_devlink functionality.
    
    [1] commit 3fb16866b51d ("driver core: fw_devlink: Make cycle detection more robust")
    [2] Link: https://lore.kernel.org/all/[email protected]
    
    Cc: [email protected] # 5.15.169
    Cc: [email protected] # 5.10.228
    Cc: [email protected] # 5.4.284
    Signed-off-by: Jason-JH.Lin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "usb: yurex: Replace snprintf() with the safer scnprintf() variant" [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Mon Oct 7 11:39:47 2024 +0200

    Revert "usb: yurex: Replace snprintf() with the safer scnprintf() variant"
    
    commit 71c717cd8a2e180126932cc6851ff21c1d04d69a upstream.
    
    This reverts commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035.
    
    This patch leads to passing 0 to simple_read_from_buffer()
    as a fifth argument, turning the read method into a nop.
    The change is fundamentally flawed, as it breaks the driver.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    Cc: stable <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
riscv: define ILLEGAL_POINTER_VALUE for 64bit [+ + +]
Author: Jisheng Zhang <[email protected]>
Date:   Sat Jul 6 01:02:10 2024 +0800

    riscv: define ILLEGAL_POINTER_VALUE for 64bit
    
    commit 5c178472af247c7b50f962495bb7462ba453b9fb upstream.
    
    This is used in poison.h for poison pointer offset. Based on current
    SV39, SV48 and SV57 vm layout, 0xdead000000000000 is a proper value
    that is not mappable, this can avoid potentially turning an oops to
    an expolit.
    
    Signed-off-by: Jisheng Zhang <[email protected]>
    Fixes: fbe934d69eb7 ("RISC-V: Build Infrastructure")
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

riscv: Fix fp alignment bug in perf_callchain_user() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Mon Jul 8 11:28:46 2024 +0800

    riscv: Fix fp alignment bug in perf_callchain_user()
    
    [ Upstream commit 22ab08955ea13be04a8efd20cc30890e0afaa49c ]
    
    The standard RISC-V calling convention said:
            "The stack grows downward and the stack pointer is always
            kept 16-byte aligned".
    
    So perf_callchain_user() should check whether 16-byte aligned for fp.
    
    Link: https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf
    
    Fixes: dbeb90b0c1eb ("riscv: Add perf callchain support")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Cc: Björn Töpel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: Remove unused GENERATING_ASM_OFFSETS [+ + +]
Author: Chunyan Zhang <[email protected]>
Date:   Tue Oct 8 17:41:38 2024 +0800

    riscv: Remove unused GENERATING_ASM_OFFSETS
    
    [ Upstream commit 46d4e5ac6f2f801f97bcd0ec82365969197dc9b1 ]
    
    The macro is not used in the current version of kernel, it looks like
    can be removed to avoid a build warning:
    
    ../arch/riscv/kernel/asm-offsets.c: At top level:
    ../arch/riscv/kernel/asm-offsets.c:7: warning: macro "GENERATING_ASM_OFFSETS" is not used [-Wunused-macros]
        7 | #define GENERATING_ASM_OFFSETS
    
    Fixes: 9639a44394b9 ("RISC-V: Provide a cleaner raw_smp_processor_id()")
    Cc: [email protected]
    Reviewed-by: Alexandre Ghiti <[email protected]>
    Tested-by: Alexandre Ghiti <[email protected]>
    Signed-off-by: Chunyan Zhang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rtc: at91sam9: fix OF node leak in probe() error path [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 20:31:03 2024 +0200

    rtc: at91sam9: fix OF node leak in probe() error path
    
    commit 73580e2ee6adfb40276bd420da3bb1abae204e10 upstream.
    
    Driver is leaking an OF node reference obtained from
    of_parse_phandle_with_fixed_args().
    
    Fixes: 43e112bb3dea ("rtc: at91sam9: make use of syscon/regmap to access GPBR registers")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390/cpum_sf: Remove WARN_ON_ONCE statements [+ + +]
Author: Thomas Richter <[email protected]>
Date:   Wed Jul 10 12:23:47 2024 +0200

    s390/cpum_sf: Remove WARN_ON_ONCE statements
    
    [ Upstream commit b495e710157606889f2d8bdc62aebf2aa02f67a7 ]
    
    Remove WARN_ON_ONCE statements. These have not triggered in the
    past.
    
    Signed-off-by: Thomas Richter <[email protected]>
    Acked-by: Sumanth Korikkar <[email protected]>
    Cc: Heiko Carstens <[email protected]>
    Cc: Vasily Gorbik <[email protected]>
    Cc: Alexander Gordeev <[email protected]>
    Signed-off-by: Vasily Gorbik <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/facility: Disable compile time optimization for decompressor code [+ + +]
Author: Heiko Carstens <[email protected]>
Date:   Wed Sep 4 11:39:24 2024 +0200

    s390/facility: Disable compile time optimization for decompressor code
    
    [ Upstream commit 0147addc4fb72a39448b8873d8acdf3a0f29aa65 ]
    
    Disable compile time optimizations of test_facility() for the
    decompressor. The decompressor should not contain any optimized code
    depending on the architecture level set the kernel image is compiled
    for to avoid unexpected operation exceptions.
    
    Add a __DECOMPRESSOR check to test_facility() to enforce that
    facilities are always checked during runtime for the decompressor.
    
    Reviewed-by: Sven Schnelle <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/mm: Add cond_resched() to cmm_alloc/free_pages() [+ + +]
Author: Gerald Schaefer <[email protected]>
Date:   Mon Sep 2 14:02:19 2024 +0200

    s390/mm: Add cond_resched() to cmm_alloc/free_pages()
    
    [ Upstream commit 131b8db78558120f58c5dc745ea9655f6b854162 ]
    
    Adding/removing large amount of pages at once to/from the CMM balloon
    can result in rcu_sched stalls or workqueue lockups, because of busy
    looping w/o cond_resched().
    
    Prevent this by adding a cond_resched(). cmm_free_pages() holds a
    spin_lock while looping, so it cannot be added directly to the existing
    loop. Instead, introduce a wrapper function that operates on maximum 256
    pages at once, and add it there.
    
    Signed-off-by: Gerald Schaefer <[email protected]>
    Reviewed-by: Heiko Carstens <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/sclp_vt220: Convert newlines to CRLF instead of LFCR [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Mon Oct 14 07:50:07 2024 +0200

    s390/sclp_vt220: Convert newlines to CRLF instead of LFCR
    
    commit dee3df68ab4b00fff6bdf9fc39541729af37307c upstream.
    
    According to the VT220 specification the possible character combinations
    sent on RETURN are only CR or CRLF [0].
    
            The Return key sends either a CR character (0/13) or a CR
            character (0/13) and an LF character (0/10), depending on the
            set/reset state of line feed/new line mode (LNM).
    
    The sclp/vt220 driver however uses LFCR. This can confuse tools, for
    example the kunit runner.
    
    Link: https://vt100.net/docs/vt220-rm/chapter3.html#S3.2
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: [email protected]
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Reviewed-by: Sven Schnelle <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scripts: kconfig: merge_config: config files: add a trailing newline [+ + +]
Author: Anders Roxell <[email protected]>
Date:   Mon Aug 5 11:22:34 2024 +0200

    scripts: kconfig: merge_config: config files: add a trailing newline
    
    [ Upstream commit 33330bcf031818e60a816db0cfd3add9eecc3b28 ]
    
    When merging files without trailing newlines at the end of the file, two
    config fragments end up at the same row if file1.config doens't have a
    trailing newline at the end of the file.
    
    file1.config "CONFIG_1=y"
    file2.config "CONFIG_2=y"
    ./scripts/kconfig/merge_config.sh -m .config file1.config file2.config
    
    This will generate a .config looking like this.
    cat .config
    ...
    CONFIG_1=yCONFIG_2=y"
    
    Making sure so we add a newline at the end of every config file that is
    passed into the script.
    
    Signed-off-by: Anders Roxell <[email protected]>
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: aacraid: Rearrange order of struct aac_srb_unit [+ + +]
Author: Kees Cook <[email protected]>
Date:   Thu Jul 11 14:57:37 2024 -0700

    scsi: aacraid: Rearrange order of struct aac_srb_unit
    
    [ Upstream commit 6e5860b0ad4934baee8c7a202c02033b2631bb44 ]
    
    struct aac_srb_unit contains struct aac_srb, which contains struct sgmap,
    which ends in a (currently) "fake" (1-element) flexible array.  Converting
    this to a flexible array is needed so that runtime bounds checking won't
    think the array is fixed size (i.e. under CONFIG_FORTIFY_SOURCE=y and/or
    CONFIG_UBSAN_BOUNDS=y), as other parts of aacraid use struct sgmap as a
    flexible array.
    
    It is not legal to have a flexible array in the middle of a structure, so
    it either needs to be split up or rearranged so that it is at the end of
    the structure. Luckily, struct aac_srb_unit, which is exclusively
    consumed/updated by aac_send_safw_bmic_cmd(), does not depend on member
    ordering.
    
    The values set in the on-stack struct aac_srb_unit instance "srbu" by the
    only two callers, aac_issue_safw_bmic_identify() and
    aac_get_safw_ciss_luns(), do not contain anything in srbu.srb.sgmap.sg, and
    they both implicitly initialize srbu.srb.sgmap.count to 0 during
    memset(). For example:
    
            memset(&srbu, 0, sizeof(struct aac_srb_unit));
    
            srbcmd = &srbu.srb;
            srbcmd->flags   = cpu_to_le32(SRB_DataIn);
            srbcmd->cdb[0]  = CISS_REPORT_PHYSICAL_LUNS;
            srbcmd->cdb[1]  = 2; /* extended reporting */
            srbcmd->cdb[8]  = (u8)(datasize >> 8);
            srbcmd->cdb[9]  = (u8)(datasize);
    
            rcode = aac_send_safw_bmic_cmd(dev, &srbu, phys_luns, datasize);
    
    During aac_send_safw_bmic_cmd(), a separate srb is mapped into DMA, and has
    srbu.srb copied into it:
    
            srb = fib_data(fibptr);
            memcpy(srb, &srbu->srb, sizeof(struct aac_srb));
    
    Only then is srb.sgmap.count written and srb->sg populated:
    
            srb->count              = cpu_to_le32(xfer_len);
    
            sg64 = (struct sgmap64 *)&srb->sg;
            sg64->count             = cpu_to_le32(1);
            sg64->sg[0].addr[1]     = cpu_to_le32(upper_32_bits(addr));
            sg64->sg[0].addr[0]     = cpu_to_le32(lower_32_bits(addr));
            sg64->sg[0].count       = cpu_to_le32(xfer_len);
    
    But this is happening in the DMA memory, not in srbu.srb. An attempt to
    copy the changes back to srbu does happen:
    
            /*
             * Copy the updated data for other dumping or other usage if
             * needed
             */
            memcpy(&srbu->srb, srb, sizeof(struct aac_srb));
    
    But this was never correct: the sg64 (3 u32s) overlap of srb.sg (2 u32s)
    always meant that srbu.srb would have held truncated information and any
    attempt to walk srbu.srb.sg.sg based on the value of srbu.srb.sg.count
    would result in attempting to parse past the end of srbu.srb.sg.sg[0] into
    srbu.srb_reply.
    
    After getting a reply from hardware, the reply is copied into
    srbu.srb_reply:
    
            srb_reply = (struct aac_srb_reply *)fib_data(fibptr);
            memcpy(&srbu->srb_reply, srb_reply, sizeof(struct aac_srb_reply));
    
    This has always been fixed-size, so there's no issue here. It is worth
    noting that the two callers _never check_ srbu contents -- neither
    srbu.srb nor srbu.srb_reply is examined. (They depend on the mapped
    xfer_buf instead.)
    
    Therefore, the ordering of members in struct aac_srb_unit does not matter,
    and the flexible array member can moved to the end.
    
    (Additionally, the two memcpy()s that update srbu could be entirely
    removed as they are never consumed, but I left that as-is.)
    
    Signed-off-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start [+ + +]
Author: Xin Long <[email protected]>
Date:   Mon Oct 7 12:25:11 2024 -0400

    sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start
    
    [ Upstream commit 4d5c70e6155d5eae198bade4afeab3c1b15073b6 ]
    
    If hashing fails in sctp_listen_start(), the socket remains in the
    LISTENING state, even though it was not added to the hash table.
    This can lead to a scenario where a socket appears to be listening
    without actually being accessible.
    
    This patch ensures that if the hashing operation fails, the sk_state
    is set back to CLOSED before returning an error.
    
    Note that there is no need to undo the autobind operation if hashing
    fails, as the bind port can still be used for next listen() call on
    the same socket.
    
    Fixes: 76c6d988aeb3 ("sctp: add sock_reuseport for the sock in __sctp_hash_endpoint")
    Reported-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start [+ + +]
Author: Xin Long <[email protected]>
Date:   Mon Sep 30 16:49:51 2024 -0400

    sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start
    
    [ Upstream commit 8beee4d8dee76b67c75dc91fd8185d91e845c160 ]
    
    In sctp_listen_start() invoked by sctp_inet_listen(), it should set the
    sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.
    
    Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse
    is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will
    be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash
    is NULL.
    
      KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
      RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617
      Call Trace:
       <TASK>
       __sys_listen_socket net/socket.c:1883 [inline]
       __sys_listen+0x1b7/0x230 net/socket.c:1894
       __do_sys_listen net/socket.c:1902 [inline]
    
    Fixes: 5e8f3f703ae4 ("sctp: simplify sctp listening code")
    Reported-by: [email protected]
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Link: https://patch.msgid.link/a93e655b3c153dc8945d7a812e6d8ab0d52b7aa0.1727729391.git.lucien.xin@gmail.com
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:29 2024 -0700

    selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c
    
    [ Upstream commit d393f9479d4aaab0fa4c3caf513f28685e831f13 ]
    
    Cast 'rlim_t' argument to match expected type of printf() format and avoid
    compile errors seen building for mips64el/musl-libc:
    
      In file included from map_tests/sk_storage_map.c:20:
      map_tests/sk_storage_map.c: In function 'test_sk_storage_map_stress_free':
      map_tests/sk_storage_map.c:414:56: error: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'rlim_t' {aka 'long long unsigned int'} [-Werror=format=]
        414 |                 CHECK(err, "setrlimit(RLIMIT_NOFILE)", "rlim_new:%lu errno:%d",
            |                                                        ^~~~~~~~~~~~~~~~~~~~~~~
        415 |                       rlim_new.rlim_cur, errno);
            |                       ~~~~~~~~~~~~~~~~~
            |                               |
            |                               rlim_t {aka long long unsigned int}
      ./test_maps.h:12:24: note: in definition of macro 'CHECK'
         12 |                 printf(format);                                         \
            |                        ^~~~~~
      map_tests/sk_storage_map.c:414:68: note: format string is defined here
        414 |                 CHECK(err, "setrlimit(RLIMIT_NOFILE)", "rlim_new:%lu errno:%d",
            |                                                                  ~~^
            |                                                                    |
            |                                                                    long unsigned int
            |                                                                  %llu
      cc1: all warnings being treated as errors
    
    Fixes: 51a0e301a563 ("bpf: Add BPF_MAP_TYPE_SK_STORAGE test to test_maps")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/1e00a1fa7acf91b4ca135c4102dc796d518bad86.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix compiling flow_dissector.c with musl-libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:40 2024 -0700

    selftests/bpf: Fix compiling flow_dissector.c with musl-libc
    
    [ Upstream commit 5e4c43bcb85973243d7274e0058b6e8f5810e4f7 ]
    
    The GNU version of 'struct tcphdr' has members 'doff', 'source' and 'dest',
    which are not exposed by musl libc headers unless _GNU_SOURCE is defined.
    
    Add this definition to fix errors seen compiling for mips64el/musl-libc:
    
      flow_dissector.c:118:30: error: 'struct tcphdr' has no member named 'doff'
        118 |                         .tcp.doff = 5,
            |                              ^~~~
      flow_dissector.c:119:30: error: 'struct tcphdr' has no member named 'source'
        119 |                         .tcp.source = 80,
            |                              ^~~~~~
      flow_dissector.c:120:30: error: 'struct tcphdr' has no member named 'dest'
        120 |                         .tcp.dest = 8080,
            |                              ^~~~
    
    Fixes: ae173a915785 ("selftests/bpf: support BPF_FLOW_DISSECTOR_F_PARSE_1ST_FRAG")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/8f7ab21a73f678f9cebd32b26c444a686e57414d.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix compiling tcp_rtt.c with musl-libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:41 2024 -0700

    selftests/bpf: Fix compiling tcp_rtt.c with musl-libc
    
    [ Upstream commit 18826fb0b79c3c3cd1fe765d85f9c6f1a902c722 ]
    
    The GNU version of 'struct tcp_info' in 'netinet/tcp.h' is not exposed by
    musl headers unless _GNU_SOURCE is defined.
    
    Add this definition to fix errors seen compiling for mips64el/musl-libc:
    
      tcp_rtt.c: In function 'wait_for_ack':
      tcp_rtt.c:24:25: error: storage size of 'info' isn't known
         24 |         struct tcp_info info;
            |                         ^~~~
      tcp_rtt.c:24:25: error: unused variable 'info' [-Werror=unused-variable]
      cc1: all warnings being treated as errors
    
    Fixes: 1f4f80fed217 ("selftests/bpf: test_progs: convert test_tcp_rtt")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/f2329767b15df206f08a5776d35a47c37da855ae.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix error compiling test_lru_map.c [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 29 02:24:19 2024 -0700

    selftests/bpf: Fix error compiling test_lru_map.c
    
    [ Upstream commit cacf2a5a78cd1f5f616eae043ebc6f024104b721 ]
    
    Although the post-increment in macro 'CPU_SET(next++, &cpuset)' seems safe,
    the sequencing can raise compile errors, so move the increment outside the
    macro. This avoids an error seen using gcc 12.3.0 for mips64el/musl-libc:
    
      In file included from test_lru_map.c:11:
      test_lru_map.c: In function 'sched_next_online':
      test_lru_map.c:129:29: error: operation on 'next' may be undefined [-Werror=sequence-point]
        129 |                 CPU_SET(next++, &cpuset);
            |                             ^
      cc1: all warnings being treated as errors
    
    Fixes: 3fbfadce6012 ("bpf: Fix test_lru_sanity5() in test_lru_map.c")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/22993dfb11ccf27925a626b32672fd3324cb76c4.1722244708.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests: breakpoints: Fix a typo of function name [+ + +]
Author: Masami Hiramatsu <[email protected]>
Date:   Thu Oct 31 21:23:00 2019 +0900

    selftests: breakpoints: Fix a typo of function name
    
    commit 5b06eeae52c02dd0d9bc8488275a1207d410870b upstream.
    
    Since commit 5821ba969511 ("selftests: Add test plan API to kselftest.h
    and adjust callers") accidentally introduced 'a' typo in the front of
    run_test() function, breakpoint_test_arm64.c became not able to be
    compiled.
    
    Remove the 'a' from arun_test().
    
    Fixes: 5821ba969511 ("selftests: Add test plan API to kselftest.h and adjust callers")
    Reported-by: Jun Takahashi <[email protected]>
    Signed-off-by: Masami Hiramatsu <[email protected]>
    Cc: Kees Cook <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Samasth Norway Ananda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

selftests: breakpoints: use remaining time to check if suspend succeed [+ + +]
Author: Yifei Liu <[email protected]>
Date:   Mon Sep 30 15:40:25 2024 -0700

    selftests: breakpoints: use remaining time to check if suspend succeed
    
    [ Upstream commit c66be905cda24fb782b91053b196bd2e966f95b7 ]
    
    step_after_suspend_test fails with device busy error while
    writing to /sys/power/state to start suspend. The test believes
    it failed to enter suspend state with
    
    $ sudo ./step_after_suspend_test
    TAP version 13
    Bail out! Failed to enter Suspend state
    
    However, in the kernel message, I indeed see the system get
    suspended and then wake up later.
    
    [611172.033108] PM: suspend entry (s2idle)
    [611172.044940] Filesystems sync: 0.006 seconds
    [611172.052254] Freezing user space processes
    [611172.059319] Freezing user space processes completed (elapsed 0.001 seconds)
    [611172.067920] OOM killer disabled.
    [611172.072465] Freezing remaining freezable tasks
    [611172.080332] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
    [611172.089724] printk: Suspending console(s) (use no_console_suspend to debug)
    [611172.117126] serial 00:03: disabled
    some other hardware get reconnected
    [611203.136277] OOM killer enabled.
    [611203.140637] Restarting tasks ...
    [611203.141135] usb 1-8.1: USB disconnect, device number 7
    [611203.141755] done.
    [611203.155268] random: crng reseeded on system resumption
    [611203.162059] PM: suspend exit
    
    After investigation, I noticed that for the code block
    if (write(power_state_fd, "mem", strlen("mem")) != strlen("mem"))
            ksft_exit_fail_msg("Failed to enter Suspend state\n");
    
    The write will return -1 and errno is set to 16 (device busy).
    It should be caused by the write function is not successfully returned
    before the system suspend and the return value get messed when waking up.
    As a result, It may be better to check the time passed of those few
    instructions to determine whether the suspend is executed correctly for
    it is pretty hard to execute those few lines for 5 seconds.
    
    The timer to wake up the system is set to expire after 5 seconds and
    no re-arm. If the timer remaining time is 0 second and 0 nano secomd,
    it means the timer expired and wake the system up. Otherwise, the system
    could be considered to enter the suspend state failed if there is any
    remaining time.
    
    After appling this patch, the test would not fail for it believes the
    system does not go to suspend by mistake. It now could continue to the
    rest part of the test after suspend.
    
    Fixes: bfd092b8c272 ("selftests: breakpoint: add step_after_suspend_test")
    Reported-by: Sinadin Shan <[email protected]>
    Signed-off-by: Yifei Liu <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: vDSO: fix vDSO symbols lookup for powerpc64 [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Fri Aug 30 14:28:37 2024 +0200

    selftests: vDSO: fix vDSO symbols lookup for powerpc64
    
    [ Upstream commit ba83b3239e657469709d15dcea5f9b65bf9dbf34 ]
    
    On powerpc64, following tests fail locating vDSO functions:
    
      ~ # ./vdso_test_abi
      TAP version 13
      1..16
      # [vDSO kselftest] VDSO_VERSION: LINUX_2.6.15
      # Couldn't find __kernel_gettimeofday
      ok 1 # SKIP __kernel_gettimeofday
      # clock_id: CLOCK_REALTIME
      # Couldn't find __kernel_clock_gettime
      ok 2 # SKIP __kernel_clock_gettime CLOCK_REALTIME
      # Couldn't find __kernel_clock_getres
      ok 3 # SKIP __kernel_clock_getres CLOCK_REALTIME
      ...
      # Couldn't find __kernel_time
      ok 16 # SKIP __kernel_time
      # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:16 error:0
    
      ~ # ./vdso_test_getrandom
      __kernel_getrandom is missing!
    
      ~ # ./vdso_test_gettimeofday
      Could not find __kernel_gettimeofday
    
      ~ # ./vdso_test_getcpu
      Could not find __kernel_getcpu
    
    On powerpc64, as shown below by readelf, vDSO functions symbols have
    type NOTYPE, so also accept that type when looking for symbols.
    
    $ powerpc64-linux-gnu-readelf -a arch/powerpc/kernel/vdso/vdso64.so.dbg
    ELF Header:
      Magic:   7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
      Class:                             ELF64
      Data:                              2's complement, big endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              DYN (Shared object file)
      Machine:                           PowerPC64
      Version:                           0x1
    ...
    
    Symbol table '.dynsym' contains 12 entries:
       Num:    Value          Size Type    Bind   Vis      Ndx Name
         0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
         1: 0000000000000524    84 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
         2: 00000000000005f0    36 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
         3: 0000000000000578    68 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
         4: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS LINUX_2.6.15
         5: 00000000000006c0    48 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
         6: 0000000000000614   172 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
         7: 00000000000006f0    84 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
         8: 000000000000047c    84 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
         9: 0000000000000454    12 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
        10: 00000000000004d0    84 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
        11: 00000000000005bc    52 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
    
    Symbol table '.symtab' contains 56 entries:
       Num:    Value          Size Type    Bind   Vis      Ndx Name
    ...
        45: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS LINUX_2.6.15
        46: 00000000000006c0    48 NOTYPE  GLOBAL DEFAULT    8 __kernel_getcpu
        47: 0000000000000524    84 NOTYPE  GLOBAL DEFAULT    8 __kernel_clock_getres
        48: 00000000000005f0    36 NOTYPE  GLOBAL DEFAULT    8 __kernel_get_tbfreq
        49: 000000000000047c    84 NOTYPE  GLOBAL DEFAULT    8 __kernel_gettimeofday
        50: 0000000000000614   172 NOTYPE  GLOBAL DEFAULT    8 __kernel_sync_dicache
        51: 00000000000006f0    84 NOTYPE  GLOBAL DEFAULT    8 __kernel_getrandom
        52: 0000000000000454    12 NOTYPE  GLOBAL DEFAULT    8 __kernel_sigtram[...]
        53: 0000000000000578    68 NOTYPE  GLOBAL DEFAULT    8 __kernel_time
        54: 00000000000004d0    84 NOTYPE  GLOBAL DEFAULT    8 __kernel_clock_g[...]
        55: 00000000000005bc    52 NOTYPE  GLOBAL DEFAULT    8 __kernel_get_sys[...]
    
    Fixes: 98eedc3a9dbf ("Document the vDSO and add a reference parser")
    Signed-off-by: Christophe Leroy <[email protected]>
    Acked-by: Shuah Khan <[email protected]>
    Signed-off-by: Jason A. Donenfeld <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selinux: improve error checking in sel_write_load() [+ + +]
Author: Paul Moore <[email protected]>
Date:   Fri Oct 25 11:21:18 2024 -0300

    selinux: improve error checking in sel_write_load()
    
    [ Upstream commit 42c773238037c90b3302bf37a57ae3b5c3f6004a ]
    
    Move our existing input sanity checking to the top of sel_write_load()
    and add a check to ensure the buffer size is non-zero.
    
    Move a local variable initialization from the declaration to before it
    is used.
    
    Minor style adjustments.
    
    Reported-by: Sam Sun <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>
    [cascardo: keep fsi initialization at its declaration point as it is used earlier]
    [cascardo: keep check for 64MiB size limit]
    Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
signal: Replace BUG_ON()s [+ + +]
Author: Thomas Gleixner <[email protected]>
Date:   Mon Jun 10 18:42:34 2024 +0200

    signal: Replace BUG_ON()s
    
    [ Upstream commit 7f8af7bac5380f2d95a63a6f19964e22437166e1 ]
    
    These really can be handled gracefully without killing the machine.
    
    Signed-off-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Frederic Weisbecker <[email protected]>
    Reviewed-by: Oleg Nesterov <[email protected]>
    Acked-by: Peter Zijlstra (Intel) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
slip: make slhc_remember() more robust against malicious packets [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Wed Oct 9 09:11:32 2024 +0000

    slip: make slhc_remember() more robust against malicious packets
    
    [ Upstream commit 7d3fce8cbe3a70a1c7c06c9b53696be5d5d8dd5c ]
    
    syzbot found that slhc_remember() was missing checks against
    malicious packets [1].
    
    slhc_remember() only checked the size of the packet was at least 20,
    which is not good enough.
    
    We need to make sure the packet includes the IPv4 and TCP header
    that are supposed to be carried.
    
    Add iph and th pointers to make the code more readable.
    
    [1]
    
    BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
      slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
      ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455
      ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]
      ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212
      ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327
      pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
      sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
      __release_sock+0x1da/0x330 net/core/sock.c:3072
      release_sock+0x6b/0x250 net/core/sock.c:3626
      pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
      sock_sendmsg_nosec net/socket.c:729 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:744
      ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
      ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
      __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
      __do_sys_sendmmsg net/socket.c:2771 [inline]
      __se_sys_sendmmsg net/socket.c:2768 [inline]
      __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
      x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was created at:
      slab_post_alloc_hook mm/slub.c:4091 [inline]
      slab_alloc_node mm/slub.c:4134 [inline]
      kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186
      kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
      __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
      alloc_skb include/linux/skbuff.h:1322 [inline]
      sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
      pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
      sock_sendmsg_nosec net/socket.c:729 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:744
      ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
      ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
      __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
      __do_sys_sendmmsg net/socket.c:2771 [inline]
      __se_sys_sendmmsg net/socket.c:2768 [inline]
      __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
      x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
    
    Fixes: b5451d783ade ("slip: Move the SLIP drivers")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/T/#u
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso [+ + +]
Author: Jiawei Ye <[email protected]>
Date:   Mon Sep 2 08:47:26 2024 +0000

    smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso
    
    [ Upstream commit 2749749afa071f8a0e405605de9da615e771a7ce ]
    
    In the `smk_set_cipso` function, the `skp->smk_netlabel.attr.mls.cat`
    field is directly assigned to a new value without using the appropriate
    RCU pointer assignment functions. According to RCU usage rules, this is
    illegal and can lead to unpredictable behavior, including data
    inconsistencies and impossible-to-diagnose memory corruption issues.
    
    This possible bug was identified using a static analysis tool developed
    by myself, specifically designed to detect RCU-related issues.
    
    To address this, the assignment is now done using rcu_assign_pointer(),
    which ensures that the pointer assignment is done safely, with the
    necessary memory barriers and synchronization. This change prevents
    potential RCU dereference issues by ensuring that the `cat` field is
    safely updated while still adhering to RCU's requirements.
    
    Fixes: 0817534ff9ea ("smackfs: Fix use-after-free in netlbl_catmap_walk()")
    Signed-off-by: Jiawei Ye <[email protected]>
    Signed-off-by: Casey Schaufler <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
smb: client: fix OOBs when building SMB2_IOCTL request [+ + +]
Author: Paulo Alcantara <[email protected]>
Date:   Tue Oct 15 19:04:04 2024 -0300

    smb: client: fix OOBs when building SMB2_IOCTL request
    
    [ Upstream commit 1ab60323c5201bef25f2a3dc0ccc404d9aca77f1 ]
    
    When using encryption, either enforced by the server or when using
    'seal' mount option, the client will squash all compound request buffers
    down for encryption into a single iov in smb2_set_next_command().
    
    SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the
    SMB2_IOCTL request in the first iov, and if the user passes an input
    buffer that is greater than 328 bytes, smb2_set_next_command() will
    end up writing off the end of @rqst->iov[0].iov_base as shown below:
    
      mount.cifs //srv/share /mnt -o ...,seal
      ln -s $(perl -e "print('a')for 1..1024") /mnt/link
    
      BUG: KASAN: slab-out-of-bounds in
      smb2_set_next_command.cold+0x1d6/0x24c [cifs]
      Write of size 4116 at addr ffff8881148fcab8 by task ln/859
    
      CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
      1.16.3-2.fc40 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x5d/0x80
       ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
       print_report+0x156/0x4d9
       ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
       ? __virt_addr_valid+0x145/0x310
       ? __phys_addr+0x46/0x90
       ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
       kasan_report+0xda/0x110
       ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
       kasan_check_range+0x10f/0x1f0
       __asan_memcpy+0x3c/0x60
       smb2_set_next_command.cold+0x1d6/0x24c [cifs]
       smb2_compound_op+0x238c/0x3840 [cifs]
       ? kasan_save_track+0x14/0x30
       ? kasan_save_free_info+0x3b/0x70
       ? vfs_symlink+0x1a1/0x2c0
       ? do_symlinkat+0x108/0x1c0
       ? __pfx_smb2_compound_op+0x10/0x10 [cifs]
       ? kmem_cache_free+0x118/0x3e0
       ? cifs_get_writable_path+0xeb/0x1a0 [cifs]
       smb2_get_reparse_inode+0x423/0x540 [cifs]
       ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs]
       ? rcu_is_watching+0x20/0x50
       ? __kmalloc_noprof+0x37c/0x480
       ? smb2_create_reparse_symlink+0x257/0x490 [cifs]
       ? smb2_create_reparse_symlink+0x38f/0x490 [cifs]
       smb2_create_reparse_symlink+0x38f/0x490 [cifs]
       ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs]
       ? find_held_lock+0x8a/0xa0
       ? hlock_class+0x32/0xb0
       ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs]
       cifs_symlink+0x24f/0x960 [cifs]
       ? __pfx_make_vfsuid+0x10/0x10
       ? __pfx_cifs_symlink+0x10/0x10 [cifs]
       ? make_vfsgid+0x6b/0xc0
       ? generic_permission+0x96/0x2d0
       vfs_symlink+0x1a1/0x2c0
       do_symlinkat+0x108/0x1c0
       ? __pfx_do_symlinkat+0x10/0x10
       ? strncpy_from_user+0xaa/0x160
       __x64_sys_symlinkat+0xb9/0xf0
       do_syscall_64+0xbb/0x1d0
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
      RIP: 0033:0x7f08d75c13bb
    
    Reported-by: David Howells <[email protected]>
    Fixes: e77fe73c7e38 ("cifs: we can not use small padding iovs together with encryption")
    Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soc: versatile: integrator: fix OF node leak in probe() error path [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 20:05:22 2024 +0200

    soc: versatile: integrator: fix OF node leak in probe() error path
    
    commit 874c5b601856adbfda10846b9770a6c66c41e229 upstream.
    
    Driver is leaking OF node reference obtained from
    of_find_matching_node().
    
    Fixes: f956a785a282 ("soc: move SoC driver for the ARM Integrator")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

soc: versatile: realview: fix memory leak during device remove [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 20:05:23 2024 +0200

    soc: versatile: realview: fix memory leak during device remove
    
    [ Upstream commit 1c4f26a41f9d052f334f6ae629e01f598ed93508 ]
    
    If device is unbound, the memory allocated for soc_dev_attr should be
    freed to prevent leaks.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Stable-dep-of: c774f2564c00 ("soc: versatile: realview: fix soc_dev leak during device remove")
    Signed-off-by: Sasha Levin <[email protected]>

soc: versatile: realview: fix soc_dev leak during device remove [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 20:05:24 2024 +0200

    soc: versatile: realview: fix soc_dev leak during device remove
    
    [ Upstream commit c774f2564c0086c23f5269fd4691f233756bf075 ]
    
    If device is unbound, the soc_dev should be unregistered to prevent
    memory leak.
    
    Fixes: a2974c9c1f83 ("soc: add driver for the ARM RealView")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sock_map: Add a cond_resched() in sock_hash_free() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Sep 6 15:44:49 2024 +0000

    sock_map: Add a cond_resched() in sock_hash_free()
    
    [ Upstream commit b1339be951ad31947ae19bc25cb08769bf255100 ]
    
    Several syzbot soft lockup reports all have in common sock_hash_free()
    
    If a map with a large number of buckets is destroyed, we need to yield
    the cpu when needed.
    
    Fixes: 75e68e5bf2c7 ("bpf, sockhash: Synchronize delete from bucket list on map free")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Martin KaFai Lau <[email protected]>
    Acked-by: John Fastabend <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
soundwire: stream: Revert "soundwire: stream: fix programming slave ports for non-continous port maps" [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Sep 9 18:47:46 2024 +0200

    soundwire: stream: Revert "soundwire: stream: fix programming slave ports for non-continous port maps"
    
    commit 233a95fd574fde1c375c486540a90304a2d2d49f upstream.
    
    This reverts commit ab8d66d132bc8f1992d3eb6cab8d32dda6733c84 because it
    breaks codecs using non-continuous masks in source and sink ports.  The
    commit missed the point that port numbers are not used as indices for
    iterating over prop.sink_ports or prop.source_ports.
    
    Soundwire core and existing codecs expect that the array passed as
    prop.sink_ports and prop.source_ports is continuous.  The port mask still
    might be non-continuous, but that's unrelated.
    
    Reported-by: Bard Liao <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Fixes: ab8d66d132bc ("soundwire: stream: fix programming slave ports for non-continous port maps")
    Acked-by: Bard Liao <[email protected]>
    Reviewed-by: Charles Keepax <[email protected]>
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Tested-by: Peter Ujfalusi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
spi: bcm63xx: Enable module autoloading [+ + +]
Author: Liao Chen <[email protected]>
Date:   Sat Aug 31 09:42:31 2024 +0000

    spi: bcm63xx: Enable module autoloading
    
    [ Upstream commit 709df70a20e990d262c473ad9899314039e8ec82 ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based
    on the alias from of_device_id table.
    
    Signed-off-by: Liao Chen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: bcm63xx: Fix module autoloading [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Mon Aug 19 20:33:48 2024 +0800

    spi: bcm63xx: Fix module autoloading
    
    commit 909f34f2462a99bf876f64c5c61c653213e32fce upstream.
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
    based on the alias from platform_device_id table.
    
    Fixes: 44d8fb30941d ("spi/bcm63xx: move register definitions into the driver")
    Cc: [email protected]
    Signed-off-by: Jinjie Ruan <[email protected]>
    Reviewed-by: Jonas Gorski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

spi: nxp-fspi: fix the KASAN report out-of-bounds bug [+ + +]
Author: Han Xu <[email protected]>
Date:   Wed Sep 11 16:11:45 2024 -0500

    spi: nxp-fspi: fix the KASAN report out-of-bounds bug
    
    commit 2a8787c1cdc7be24fdd8953ecd1a8743a1006235 upstream.
    
    Change the memcpy length to fix the out-of-bounds issue when writing the
    data that is not 4 byte aligned to TX FIFO.
    
    To reproduce the issue, write 3 bytes data to NOR chip.
    
    dd if=3b of=/dev/mtd0
    [   36.926103] ==================================================================
    [   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838
    [   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455
    [   36.946721]
    [   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070
    [   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)
    [   36.961260] Call trace:
    [   36.963723]  dump_backtrace+0x90/0xe8
    [   36.967414]  show_stack+0x18/0x24
    [   36.970749]  dump_stack_lvl+0x78/0x90
    [   36.974451]  print_report+0x114/0x5cc
    [   36.978151]  kasan_report+0xa4/0xf0
    [   36.981670]  __asan_report_load_n_noabort+0x1c/0x28
    [   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838
    [   36.990800]  spi_mem_exec_op+0x8ec/0xd30
    [   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0
    [   36.999323]  spi_mem_dirmap_write+0x238/0x32c
    [   37.003710]  spi_nor_write_data+0x220/0x374
    [   37.007932]  spi_nor_write+0x110/0x2e8
    [   37.011711]  mtd_write_oob_std+0x154/0x1f0
    [   37.015838]  mtd_write_oob+0x104/0x1d0
    [   37.019617]  mtd_write+0xb8/0x12c
    [   37.022953]  mtdchar_write+0x224/0x47c
    [   37.026732]  vfs_write+0x1e4/0x8c8
    [   37.030163]  ksys_write+0xec/0x1d0
    [   37.033586]  __arm64_sys_write+0x6c/0x9c
    [   37.037539]  invoke_syscall+0x6c/0x258
    [   37.041327]  el0_svc_common.constprop.0+0x160/0x22c
    [   37.046244]  do_el0_svc+0x44/0x5c
    [   37.049589]  el0_svc+0x38/0x78
    [   37.052681]  el0t_64_sync_handler+0x13c/0x158
    [   37.057077]  el0t_64_sync+0x190/0x194
    [   37.060775]
    [   37.062274] Allocated by task 455:
    [   37.065701]  kasan_save_stack+0x2c/0x54
    [   37.069570]  kasan_save_track+0x20/0x3c
    [   37.073438]  kasan_save_alloc_info+0x40/0x54
    [   37.077736]  __kasan_kmalloc+0xa0/0xb8
    [   37.081515]  __kmalloc_noprof+0x158/0x2f8
    [   37.085563]  mtd_kmalloc_up_to+0x120/0x154
    [   37.089690]  mtdchar_write+0x130/0x47c
    [   37.093469]  vfs_write+0x1e4/0x8c8
    [   37.096901]  ksys_write+0xec/0x1d0
    [   37.100332]  __arm64_sys_write+0x6c/0x9c
    [   37.104287]  invoke_syscall+0x6c/0x258
    [   37.108064]  el0_svc_common.constprop.0+0x160/0x22c
    [   37.112972]  do_el0_svc+0x44/0x5c
    [   37.116319]  el0_svc+0x38/0x78
    [   37.119401]  el0t_64_sync_handler+0x13c/0x158
    [   37.123788]  el0t_64_sync+0x190/0x194
    [   37.127474]
    [   37.128977] The buggy address belongs to the object at ffff00081037c2a0
    [   37.128977]  which belongs to the cache kmalloc-8 of size 8
    [   37.141177] The buggy address is located 0 bytes inside of
    [   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)
    [   37.153465]
    [   37.154971] The buggy address belongs to the physical page:
    [   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c
    [   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)
    [   37.175149] page_type: 0xfdffffff(slab)
    [   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000
    [   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000
    [   37.194553] page dumped because: kasan: bad access detected
    [   37.200144]
    [   37.201647] Memory state around the buggy address:
    [   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
    [   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc
    [   37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc
    [   37.228186]                                ^
    [   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   37.246962] ==================================================================
    [   37.254394] Disabling lock debugging due to kernel taint
    0+1 records in
    0+1 records out
    3 bytes copied, 0.335911 s, 0.0 kB/s
    
    Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller")
    Cc: [email protected]
    Signed-off-by: Han Xu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Wed Aug 14 17:45:12 2024 +0300

    spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ
    
    [ Upstream commit 7781f1d120fec8624fc654eda900fc8748262082 ]
    
    0 is incorrect error code when failed to parse and map IRQ.
    Replace OF specific old API for IRQ retrieval with a generic
    one to fix this issue.
    
    Fixes: 0f245463b01e ("spi: ppc4xx: handle irq_of_parse_and_map() errors")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: ppc4xx: handle irq_of_parse_and_map() errors [+ + +]
Author: Ma Ke <[email protected]>
Date:   Wed Jul 24 16:40:47 2024 +0800

    spi: ppc4xx: handle irq_of_parse_and_map() errors
    
    [ Upstream commit 0f245463b01ea254ae90e1d0389e90b0e7d8dc75 ]
    
    Zero and negative number is not a valid IRQ for in-kernel code and the
    irq_of_parse_and_map() function returns zero on error.  So this check for
    valid IRQs should only accept values > 0.
    
    Fixes: 44dab88e7cc9 ("spi: add spi_ppc4xx driver")
    Signed-off-by: Ma Ke <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: s3c64xx: fix timeout counters in flush_fifo [+ + +]
Author: Ben Dooks <[email protected]>
Date:   Tue Sep 24 14:40:08 2024 +0100

    spi: s3c64xx: fix timeout counters in flush_fifo
    
    [ Upstream commit 68a16708d2503b6303d67abd43801e2ca40c208d ]
    
    In the s3c64xx_flush_fifo() code, the loops counter is post-decremented
    in the do { } while(test && loops--) condition. This means the loops is
    left at the unsigned equivalent of -1 if the loop times out. The test
    after will never pass as if tests for loops == 0.
    
    Signed-off-by: Ben Dooks <[email protected]>
    Fixes: 230d42d422e7 ("spi: Add s3c64xx SPI Controller driver")
    Reviewed-by: Andi Shyti <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() [+ + +]
Author: Zicheng Qu <[email protected]>
Date:   Tue Oct 22 13:43:54 2024 +0000

    staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()
    
    commit 6bd301819f8f69331a55ae2336c8b111fc933f3d upstream.
    
    In the ad9832_write_frequency() function, clk_get_rate() might return 0.
    This can lead to a division by zero when calling ad9832_calc_freqreg().
    The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect
    against the case when fout is 0. The ad9832_write_frequency() function
    is called from ad9832_write(), and fout is derived from a text buffer,
    which can contain any value.
    
    Link: https://lore.kernel.org/all/2024100904-CVE-2024-47663-9bdc@gregkh/
    Fixes: ea707584bac1 ("Staging: IIO: DDS: AD9832 / AD9835 driver")
    Cc: [email protected]
    Signed-off-by: Zicheng Qu <[email protected]>
    Reviewed-by: Nuno Sa <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
SUNRPC: Fix integer overflow in decode_rc_list() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Thu Sep 19 11:50:33 2024 +0300

    SUNRPC: Fix integer overflow in decode_rc_list()
    
    [ Upstream commit 6dbf1f341b6b35bcc20ff95b6b315e509f6c5369 ]
    
    The math in "rc_list->rcl_nrefcalls * 2 * sizeof(uint32_t)" could have an
    integer overflow.  Add bounds checking on rc_list->rcl_nrefcalls to fix
    that.
    
    Fixes: 4aece6a19cf7 ("nfs41: cb_sequence xdr implementation")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process [+ + +]
Author: Jason Xing <[email protected]>
Date:   Fri Aug 23 08:11:52 2024 +0800

    tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process
    
    [ Upstream commit 0d9e5df4a257afc3a471a82961ace9a22b88295a ]
    
    We found that one close-wait socket was reset by the other side
    due to a new connection reusing the same port which is beyond our
    expectation, so we have to investigate the underlying reason.
    
    The following experiment is conducted in the test environment. We
    limit the port range from 40000 to 40010 and delay the time to close()
    after receiving a fin from the active close side, which can help us
    easily reproduce like what happened in production.
    
    Here are three connections captured by tcpdump:
    127.0.0.1.40002 > 127.0.0.1.9999: Flags [S], seq 2965525191
    127.0.0.1.9999 > 127.0.0.1.40002: Flags [S.], seq 2769915070
    127.0.0.1.40002 > 127.0.0.1.9999: Flags [.], ack 1
    127.0.0.1.40002 > 127.0.0.1.9999: Flags [F.], seq 1, ack 1
    // a few seconds later, within 60 seconds
    127.0.0.1.40002 > 127.0.0.1.9999: Flags [S], seq 2965590730
    127.0.0.1.9999 > 127.0.0.1.40002: Flags [.], ack 2
    127.0.0.1.40002 > 127.0.0.1.9999: Flags [R], seq 2965525193
    // later, very quickly
    127.0.0.1.40002 > 127.0.0.1.9999: Flags [S], seq 2965590730
    127.0.0.1.9999 > 127.0.0.1.40002: Flags [S.], seq 3120990805
    127.0.0.1.40002 > 127.0.0.1.9999: Flags [.], ack 1
    
    As we can see, the first flow is reset because:
    1) client starts a new connection, I mean, the second one
    2) client tries to find a suitable port which is a timewait socket
       (its state is timewait, substate is fin_wait2)
    3) client occupies that timewait port to send a SYN
    4) server finds a corresponding close-wait socket in ehash table,
       then replies with a challenge ack
    5) client sends an RST to terminate this old close-wait socket.
    
    I don't think the port selection algo can choose a FIN_WAIT2 socket
    when we turn on tcp_tw_reuse because on the server side there
    remain unread data. In some cases, if one side haven't call close() yet,
    we should not consider it as expendable and treat it at will.
    
    Even though, sometimes, the server isn't able to call close() as soon
    as possible like what we expect, it can not be terminated easily,
    especially due to a second unrelated connection happening.
    
    After this patch, we can see the expected failure if we start a
    connection when all the ports are occupied in fin_wait2 state:
    "Ncat: Cannot assign requested address."
    
    Reported-by: Jade Dong <[email protected]>
    Signed-off-by: Jason Xing <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tcp: check skb is non-NULL in tcp_rto_delta_us() [+ + +]
Author: Josh Hunt <[email protected]>
Date:   Tue Sep 10 15:08:22 2024 -0400

    tcp: check skb is non-NULL in tcp_rto_delta_us()
    
    [ Upstream commit c8770db2d54437a5f49417ae7b46f7de23d14db6 ]
    
    We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic
    kernel that are running ceph and recently hit a null ptr dereference in
    tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also
    saw it getting hit from the RACK case as well. Here are examples of the oops
    messages we saw in each of those cases:
    
    Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020
    Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode
    Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page
    Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0
    Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI
    Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu
    Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023
    Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160
    Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3
    Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246
    Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000
    Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60
    Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8
    Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900
    Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30
    Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000
    Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0
    Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554
    Jul 26 15:05:02 rx [11061395.916786] Call Trace:
    Jul 26 15:05:02 rx [11061395.919488]
    Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f
    Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9
    Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380
    Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0
    Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50
    Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0
    Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20
    Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450
    Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140
    Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90
    Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0
    Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40
    Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160
    Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160
    Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220
    Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240
    Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0
    Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240
    Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130
    Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280
    Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10
    Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30
    Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_event+0x21/0x30
    Jul 26 15:05:02 rx [11061396.021984] ? clockevents_program_event+0x8f/0xe0
    Jul 26 15:05:02 rx [11061396.027035] run_timer_softirq+0x2a/0x50
    Jul 26 15:05:02 rx [11061396.031212] __do_softirq+0xd1/0x2c1
    Jul 26 15:05:02 rx [11061396.035044] do_softirq_own_stack+0x2a/0x40
    Jul 26 15:05:02 rx [11061396.039480]
    Jul 26 15:05:02 rx [11061396.041840] do_softirq.part.0+0x46/0x50
    Jul 26 15:05:02 rx [11061396.046022] __local_bh_enable_ip+0x50/0x60
    Jul 26 15:05:02 rx [11061396.050460] _raw_spin_unlock_bh+0x1e/0x20
    Jul 26 15:05:02 rx [11061396.054817] nf_conntrack_tcp_packet+0x29e/0xbe0 [nf_conntrack]
    Jul 26 15:05:02 rx [11061396.060994] ? get_l4proto+0xe7/0x190 [nf_conntrack]
    Jul 26 15:05:02 rx [11061396.066220] nf_conntrack_in+0xe9/0x670 [nf_conntrack]
    Jul 26 15:05:02 rx [11061396.071618] ipv6_conntrack_local+0x14/0x20 [nf_conntrack]
    Jul 26 15:05:02 rx [11061396.077356] nf_hook_slow+0x45/0xb0
    Jul 26 15:05:02 rx [11061396.081098] ip6_xmit+0x3f0/0x5d0
    Jul 26 15:05:02 rx [11061396.084670] ? ipv6_anycast_cleanup+0x50/0x50
    Jul 26 15:05:02 rx [11061396.089282] ? __sk_dst_check+0x38/0x70
    Jul 26 15:05:02 rx [11061396.093381] ? inet6_csk_route_socket+0x13b/0x200
    Jul 26 15:05:02 rx [11061396.098346] inet6_csk_xmit+0xa7/0xf0
    Jul 26 15:05:02 rx [11061396.102263] __tcp_transmit_skb+0x550/0xb30
    Jul 26 15:05:02 rx [11061396.106701] tcp_write_xmit+0x3c6/0xc20
    Jul 26 15:05:02 rx [11061396.110792] ? __alloc_skb+0x98/0x1d0
    Jul 26 15:05:02 rx [11061396.114708] __tcp_push_pending_frames+0x37/0x100
    Jul 26 15:05:02 rx [11061396.119667] tcp_push+0xfd/0x100
    Jul 26 15:05:02 rx [11061396.123150] tcp_sendmsg_locked+0xc70/0xdd0
    Jul 26 15:05:02 rx [11061396.127588] tcp_sendmsg+0x2d/0x50
    Jul 26 15:05:02 rx [11061396.131245] inet6_sendmsg+0x43/0x70
    Jul 26 15:05:02 rx [11061396.135075] __sock_sendmsg+0x48/0x70
    Jul 26 15:05:02 rx [11061396.138994] ____sys_sendmsg+0x212/0x280
    Jul 26 15:05:02 rx [11061396.143172] ___sys_sendmsg+0x88/0xd0
    Jul 26 15:05:02 rx [11061396.147098] ? __seccomp_filter+0x7e/0x6b0
    Jul 26 15:05:02 rx [11061396.151446] ? __switch_to+0x39c/0x460
    Jul 26 15:05:02 rx [11061396.155453] ? __switch_to_asm+0x42/0x80
    Jul 26 15:05:02 rx [11061396.159636] ? __switch_to_asm+0x5a/0x80
    Jul 26 15:05:02 rx [11061396.163816] __sys_sendmsg+0x5c/0xa0
    Jul 26 15:05:02 rx [11061396.167647] __x64_sys_sendmsg+0x1f/0x30
    Jul 26 15:05:02 rx [11061396.171832] do_syscall_64+0x57/0x190
    Jul 26 15:05:02 rx [11061396.175748] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
    Jul 26 15:05:02 rx [11061396.181055] RIP: 0033:0x7f1ef692618d
    Jul 26 15:05:02 rx [11061396.184893] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 ca ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2f 44 89 c7 48 89 44 24 08 e8 fe ee ff ff 48
    Jul 26 15:05:02 rx [11061396.203889] RSP: 002b:00007f1ef4a26aa0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
    Jul 26 15:05:02 rx [11061396.211708] RAX: ffffffffffffffda RBX: 000000000000084b RCX: 00007f1ef692618d
    Jul 26 15:05:02 rx [11061396.219091] RDX: 0000000000004000 RSI: 00007f1ef4a26b10 RDI: 0000000000000275
    Jul 26 15:05:02 rx [11061396.226475] RBP: 0000000000004000 R08: 0000000000000000 R09: 0000000000000020
    Jul 26 15:05:02 rx [11061396.233859] R10: 0000000000000000 R11: 0000000000000