Linux 6.6.9

 
9p: prevent read overrun in protocol dump tracepoint [+ + +]
Author: JP Kobryn <inwardvessel@gmail.com>
Date:   Mon Dec 4 12:23:20 2023 -0800

    9p: prevent read overrun in protocol dump tracepoint
    
    commit a931c6816078af3e306e0f444f492396ce40de31 upstream.
    
    An out of bounds read can occur within the tracepoint 9p_protocol_dump. In
    the fast assign, there is a memcpy that uses a constant size of 32 (macro
    named P9_PROTO_DUMP_SZ). When the copy is invoked, the source buffer is not
    guaranteed match this size.  It was found that in some cases the source
    buffer size is less than 32, resulting in a read that overruns.
    
    The size of the source buffer seems to be known at the time of the
    tracepoint being invoked. The allocations happen within p9_fcall_init(),
    where the capacity field is set to the allocated size of the payload
    buffer. This patch tries to fix the overrun by changing the fixed array to
    a dynamically sized array and using the minimum of the capacity value or
    P9_PROTO_DUMP_SZ as its length. The trace log statement is adjusted to
    account for this. Note that the trace log no longer splits the payload on
    the first 16 bytes. The full payload is now logged to a single line.
    
    To repro the orignal problem, operations to a plan 9 managed resource can
    be used. The simplest approach might just be mounting a shared filesystem
    (between host and guest vm) using the plan 9 protocol while the tracepoint
    is enabled.
    
    mount -t 9p -o trans=virtio <mount_tag> <mount_path>
    
    The bpftrace program below can be used to show the out of bounds read.
    Note that a recent version of bpftrace is needed for the raw tracepoint
    support. The script was tested using v0.19.0.
    
    /* from include/net/9p/9p.h */
    struct p9_fcall {
        u32 size;
        u8 id;
        u16 tag;
        size_t offset;
        size_t capacity;
        struct kmem_cache *cache;
        u8 *sdata;
        bool zc;
    };
    
    tracepoint:9p:9p_protocol_dump
    {
        /* out of bounds read can happen when this tracepoint is enabled */
    }
    
    rawtracepoint:9p_protocol_dump
    {
        $pdu = (struct p9_fcall *)arg1;
        $dump_sz = (uint64)32;
    
        if ($dump_sz > $pdu->capacity) {
            printf("reading %zu bytes from src buffer of %zu bytes\n",
                $dump_sz, $pdu->capacity);
        }
    }
    
    Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
    Message-ID: <20231204202321.22730-1-inwardvessel@gmail.com>
    Fixes: 60ece0833b6c ("net/9p: allocate appropriate reduced message buffers")
    Cc: stable@vger.kernel.org
    Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
afs: Fix dynamic root lookup DNS check [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Mon Dec 11 15:15:02 2023 +0000

    afs: Fix dynamic root lookup DNS check
    
    [ Upstream commit 74cef6872ceaefb5b6c5c60641371ea28702d358 ]
    
    In the afs dynamic root directory, the ->lookup() function does a DNS check
    on the cell being asked for and if the DNS upcall reports an error it will
    report an error back to userspace (typically ENOENT).
    
    However, if a failed DNS upcall returns a new-style result, it will return
    a valid result, with the status field set appropriately to indicate the
    type of failure - and in that case, dns_query() doesn't return an error and
    we let stat() complete with no error - which can cause confusion in
    userspace as subsequent calls that trigger d_automount then fail with
    ENOENT.
    
    Fix this by checking the status result from a valid dns_query() and
    returning an error if it indicates a failure.
    
    Fixes: bbb4c4323a4d ("dns: Allow the dns resolver to retrieve a server set")
    Reported-by: Markus Suvanto <markus.suvanto@gmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216637
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Markus Suvanto <markus.suvanto@gmail.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

afs: Fix overwriting of result of DNS query [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Thu Dec 21 15:09:31 2023 +0000

    afs: Fix overwriting of result of DNS query
    
    [ Upstream commit a9e01ac8c5ff32669119c40dfdc9e80eb0b7d7aa ]
    
    In afs_update_cell(), ret is the result of the DNS lookup and the errors
    are to be handled by a switch - however, the value gets clobbered in
    between by setting it to -ENOMEM in case afs_alloc_vlserver_list()
    fails.
    
    Fix this by moving the setting of -ENOMEM into the error handling for
    OOM failure.  Further, only do it if we don't have an alternative error
    to return.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.  Based
    on a patch from Anastasia Belova [1].
    
    Fixes: d5c32c89b208 ("afs: Fix cell DNS lookup")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
    cc: Anastasia Belova <abelova@astralinux.ru>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    cc: lvc-project@linuxtesting.org
    Link: https://lore.kernel.org/r/20231221085849.1463-1-abelova@astralinux.ru/ [1]
    Link: https://lore.kernel.org/r/1700862.1703168632@warthog.procyon.org.uk/ # v1
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

afs: Fix the dynamic root's d_delete to always delete unused dentries [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Mon Dec 11 15:08:57 2023 +0000

    afs: Fix the dynamic root's d_delete to always delete unused dentries
    
    [ Upstream commit 71f8b55bc30e82d6355e07811213d847981a32e2 ]
    
    Fix the afs dynamic root's d_delete function to always delete unused
    dentries rather than only deleting them if they're positive.  With things
    as they stand upstream, negative dentries stemming from failed DNS lookups
    stick around preventing retries.
    
    Fixes: 66c7e1d319a5 ("afs: Split the dynroot stuff out and give it its own ops tables")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Markus Suvanto <markus.suvanto@gmail.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

afs: Fix use-after-free due to get/remove race in volume tree [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Thu Dec 21 13:57:31 2023 +0000

    afs: Fix use-after-free due to get/remove race in volume tree
    
    [ Upstream commit 9a6b294ab496650e9f270123730df37030911b55 ]
    
    When an afs_volume struct is put, its refcount is reduced to 0 before
    the cell->volume_lock is taken and the volume removed from the
    cell->volumes tree.
    
    Unfortunately, this means that the lookup code can race and see a volume
    with a zero ref in the tree, resulting in a use-after-free:
    
        refcount_t: addition on 0; use-after-free.
        WARNING: CPU: 3 PID: 130782 at lib/refcount.c:25 refcount_warn_saturate+0x7a/0xda
        ...
        RIP: 0010:refcount_warn_saturate+0x7a/0xda
        ...
        Call Trace:
         afs_get_volume+0x3d/0x55
         afs_create_volume+0x126/0x1de
         afs_validate_fc+0xfe/0x130
         afs_get_tree+0x20/0x2e5
         vfs_get_tree+0x1d/0xc9
         do_new_mount+0x13b/0x22e
         do_mount+0x5d/0x8a
         __do_sys_mount+0x100/0x12a
         do_syscall_64+0x3a/0x94
         entry_SYSCALL_64_after_hwframe+0x62/0x6a
    
    Fix this by:
    
     (1) When putting, use a flag to indicate if the volume has been removed
         from the tree and skip the rb_erase if it has.
    
     (2) When looking up, use a conditional ref increment and if it fails
         because the refcount is 0, replace the node in the tree and set the
         removal flag.
    
    Fixes: 20325960f875 ("afs: Reorganise volume and server trees to be rooted on the cell")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: hda/realtek: Add quirk for ASUS ROG GV302XA [+ + +]
Author: Clément Villeret <clement.villeret@gmail.com>
Date:   Thu Dec 14 21:36:32 2023 +0100

    ALSA: hda/realtek: Add quirk for ASUS ROG GV302XA
    
    commit 02a460adfc4920d4da775fb59ab3e54036daef22 upstream.
    
    Asus ROG Flowx13 (GV302XA) seems require same patch as others asus products
    
    Signed-off-by: Clément Villeret <clement.villeret@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/0a27bf4b-3056-49ac-9651-ebd7f3e36328@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/tas2781: select program 0, conf 0 by default [+ + +]
Author: Gergo Koteles <soyer@irl.hu>
Date:   Fri Dec 15 00:33:27 2023 +0100

    ALSA: hda/tas2781: select program 0, conf 0 by default
    
    commit ec1de5c214eb5a892fdb7c450748249d5e2840f5 upstream.
    
    Currently, cur_prog/cur_conf remains at the default value (-1), while
    program 0 has been loaded into the amplifiers.
    
    In the playback hook, tasdevice_tuning_switch tries to restore the
    cur_prog/cur_conf. In the runtime_resume/system_resume,
    tasdevice_prmg_load tries to load the cur_prog as well.
    
    Set cur_prog and cur_conf to 0 if available in the firmware.
    
    Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver")
    CC: stable@vger.kernel.org
    Signed-off-by: Gergo Koteles <soyer@irl.hu>
    Link: https://lore.kernel.org/r/038add0bdca1f979cc7abcce8f24cbcd3544084b.1702596646.git.soyer@irl.hu
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Increase delay in MOTU M quirk [+ + +]
Author: Jeremie Knuesel <knuesel@gmail.com>
Date:   Sun Dec 17 12:22:43 2023 +0100

    ALSA: usb-audio: Increase delay in MOTU M quirk
    
    commit 48d6b91798a6694fdd6edb62799754b9d3fe0792 upstream.
    
    Increase the quirk delay from 2 seconds to 4 seconds. This reflects a
    change in the Windows driver in which the delay was increased to about
    3.7 seconds. The larger delay fixes an issue where the device fails to
    work unless it was powered up early during boot.
    
    Also clarify in the quirk comment that the quirk is only applied to
    older devices (USB ID 07fd:0008).
    
    Signed-off-by: Jeremie Knuesel <knuesel@gmail.com>
    Suggested-by: Alexander Tsoy <alexander@tsoy.me>
    Cc: <stable@vger.kernel.org>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=211975
    Link: https://lore.kernel.org/r/20231217112243.33409-1-knuesel@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: dts: allwinner: h616: update emac for Orange Pi Zero 3 [+ + +]
Author: Chukun Pan <amadeus@jmu.edu.cn>
Date:   Sun Oct 29 15:40:09 2023 +0800

    arm64: dts: allwinner: h616: update emac for Orange Pi Zero 3
    
    [ Upstream commit b9622937d95809ef89904583191571a9fa326402 ]
    
    The current emac setting is not suitable for Orange Pi Zero 3,
    move it back to Orange Pi Zero 2 DT. Also update phy mode and
    delay values for emac on Orange Pi Zero 3.
    With these changes, Ethernet now looks stable.
    
    Fixes: 322bf103204b ("arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DT")
    Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Link: https://lore.kernel.org/r/20231029074009.7820-2-amadeus@jmu.edu.cn
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: dts: dra7: Fix DRA7 L3 NoC node register size [+ + +]
Author: Andrew Davis <afd@ti.com>
Date:   Mon Nov 13 12:16:04 2023 -0600

    ARM: dts: dra7: Fix DRA7 L3 NoC node register size
    
    [ Upstream commit 1e5caee2ba8f1426e8098afb4ca38dc40a0ca71b ]
    
    This node can access any part of the L3 configuration registers space,
    including CLK1 and CLK2 which are 0x800000 offset. Restore this area
    size to include these areas.
    
    Fixes: 7f2659ce657e ("ARM: dts: Move dra7 l3 noc to a separate node")
    Signed-off-by: Andrew Davis <afd@ti.com>
    Message-ID: <20231113181604.546444-1-afd@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: Fix occasional boot hang for am3 usb [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Tue Dec 12 15:50:35 2023 +0200

    ARM: dts: Fix occasional boot hang for am3 usb
    
    commit 9b6a51aab5f5f9f71d2fa16e8b4d530e1643dfcb upstream.
    
    With subtle timings changes, we can now sometimes get an external abort on
    non-linefetch error booting am3 devices at sysc_reset(). This is because
    of a missing reset delay needed for the usb target module.
    
    Looks like we never enabled the delay earlier for am3, although a similar
    issue was seen earlier with a similar usb setup for dm814x as described in
    commit ebf244148092 ("ARM: OMAP2+: Use srst_udelay for USB on dm814x").
    
    Cc: stable@vger.kernel.org
    Fixes: 0782e8572ce4 ("ARM: dts: Probe am335x musb with ti-sysc")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: OMAP2+: Fix null pointer dereference and memory leak in omap_soc_device_init [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Thu Nov 23 22:52:37 2023 +0800

    ARM: OMAP2+: Fix null pointer dereference and memory leak in omap_soc_device_init
    
    [ Upstream commit c72b9c33ef9695ad7ce7a6eb39a9df8a01b70796 ]
    
    kasprintf() returns a pointer to dynamically allocated memory which can
    be NULL upon failure. When 'soc_dev_attr->family' is NULL,it'll trigger
    the null pointer dereference issue, such as in 'soc_info_show'.
    
    And when 'soc_device_register' fails, it's necessary to release
    'soc_dev_attr->family' to avoid memory leaks.
    
    Fixes: 6770b2114325 ("ARM: OMAP2+: Export SoC information to userspace")
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Message-ID: <20231123145237.609442-1-chentao@kylinos.cn>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: fsl_sai: Fix channel swap issue on i.MX8MP [+ + +]
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Tue Dec 19 10:30:57 2023 +0800

    ASoC: fsl_sai: Fix channel swap issue on i.MX8MP
    
    [ Upstream commit 8f0f01647550daf9cd8752c1656dcb0136d79ce1 ]
    
    When flag mclk_with_tere and mclk_direction_output enabled,
    The SAI transmitter or receiver will be enabled in very early
    stage, that if FSL_SAI_xMR is set by previous case,
    for example previous case is one channel, current case is
    two channels, then current case started with wrong xMR in
    the beginning, then channel swap happen.
    
    The patch is to clear xMR in hw_free() to avoid such
    channel swap issue.
    
    Fixes: 3e4a82612998 ("ASoC: fsl_sai: MCLK bind with TX/RX enable bit")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
    Link: https://msgid.link/r/1702953057-4499-1-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: hdmi-codec: fix missing report for jack initial status [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Mon Dec 18 15:56:52 2023 +0100

    ASoC: hdmi-codec: fix missing report for jack initial status
    
    [ Upstream commit 025222a9d6d25eee2ad9a1bb5a8b29b34b5ba576 ]
    
    This fixes a problem introduced while fixing ELD reporting with no jack
    set.
    
    Most driver using the hdmi-codec will call the 'plugged_cb' callback
    directly when registered to report the initial state of the HDMI connector.
    
    With the commit mentionned, this occurs before jack is ready and the
    initial report is lost for platforms actually providing a jack for HDMI.
    
    Fix this by storing the hdmi connector status regardless of jack being set
    or not and report the last status when jack gets set.
    
    With this, the initial state is reported correctly even if it is
    disconnected. This was not done initially and is also a fix.
    
    Fixes: 15be353d55f9 ("ASoC: hdmi-codec: register hpd callback on component probe")
    Reported-by: Zhengqiao Xia <xiazhengqiao@huaqin.corp-partner.google.com>
    Closes: https://lore.kernel.org/alsa-devel/CADYyEwTNyY+fR9SgfDa-g6iiDwkU3MUdPVCYexs2_3wbcM8_vg@mail.gmail.com/
    Cc: Hsin-Yi Wang <hsinyi@google.com>
    Tested-by: Zhengqiao Xia <xiazhengqiao@huaqin.corp-partner.google.com>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://msgid.link/r/20231218145655.134929-1-jbrunet@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: tas2781: check the validity of prm_no/cfg_no [+ + +]
Author: Gergo Koteles <soyer@irl.hu>
Date:   Thu Dec 14 23:04:44 2023 +0100

    ASoC: tas2781: check the validity of prm_no/cfg_no
    
    commit f32c80d34249e1cfb2e647ab3c8ef38a460c787f upstream.
    
    Add additional checks for program/config numbers to avoid loading from
    invalid addresses.
    
    If prm_no/cfg_no is negative, skip uploading program/config.
    
    The tas2781-hda driver caused a NULL pointer dereference after loading
    module, and before first runtime_suspend.
    
    the state was:
    tas_priv->cur_conf = -1;
    tas_priv->tasdevice[i].cur_conf = 0;
    program = &(tas_fmw->programs[-1]);
    
    BUG: kernel NULL pointer dereference, address: 0000000000000010
    Call Trace:
     <TASK>
     ? __die+0x23/0x70
     ? page_fault_oops+0x171/0x4e0
     ? vprintk_emit+0x175/0x2b0
     ? exc_page_fault+0x7f/0x180
     ? asm_exc_page_fault+0x26/0x30
     ? tasdevice_load_block_kernel+0x21/0x310 [snd_soc_tas2781_fmwlib]
     tasdevice_select_tuningprm_cfg+0x268/0x3a0 [snd_soc_tas2781_fmwlib]
     tasdevice_tuning_switch+0x69/0x710 [snd_soc_tas2781_fmwlib]
     tas2781_hda_playback_hook+0xd4/0x110 [snd_hda_scodec_tas2781_i2c]
    
    Fixes: 915f5eadebd2 ("ASoC: tas2781: firmware lib")
    CC:  <stable@vger.kernel.org>
    Signed-off-by: Gergo Koteles <soyer@irl.hu>
    Link: https://msgid.link/r/523780155bfdca9bc0acd39efc79ed039454818d.1702591356.git.soyer@irl.hu
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Bluetooth: Add more enc key size check [+ + +]
Author: Alex Lu <alex_lu@realsil.com.cn>
Date:   Tue Dec 12 10:30:34 2023 +0800

    Bluetooth: Add more enc key size check
    
    commit 04a342cc49a8522e99c9b3346371c329d841dcd2 upstream.
    
    When we are slave role and receives l2cap conn req when encryption has
    started, we should check the enc key size to avoid KNOB attack or BLUFFS
    attack.
    From SIG recommendation, implementations are advised to reject
    service-level connections on an encrypted baseband link with key
    strengths below 7 octets.
    A simple and clear way to achieve this is to place the enc key size
    check in hci_cc_read_enc_key_size()
    
    The btmon log below shows the case that lacks enc key size check.
    
    > HCI Event: Connect Request (0x04) plen 10
            Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Class: 0x480104
              Major class: Computer (desktop, notebook, PDA, organizers)
              Minor class: Desktop workstation
              Capturing (Scanner, Microphone)
              Telephony (Cordless telephony, Modem, Headset)
            Link type: ACL (0x01)
    < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
            Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Role: Peripheral (0x01)
    > HCI Event: Command Status (0x0f) plen 4
          Accept Connection Request (0x01|0x0009) ncmd 2
            Status: Success (0x00)
    > HCI Event: Connect Complete (0x03) plen 11
            Status: Success (0x00)
            Handle: 1
            Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Link type: ACL (0x01)
            Encryption: Disabled (0x00)
    ...
    
    > HCI Event: Encryption Change (0x08) plen 4
            Status: Success (0x00)
            Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Encryption: Enabled with E0 (0x01)
    < HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2
            Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33)
    > HCI Event: Command Complete (0x0e) plen 7
          Read Encryption Key Size (0x05|0x0008) ncmd 2
            Status: Success (0x00)
            Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Key size: 6
    // We should check the enc key size
    ...
    
    > ACL Data RX: Handle 1 flags 0x02 dlen 12
          L2CAP: Connection Request (0x02) ident 3 len 4
            PSM: 25 (0x0019)
            Source CID: 64
    < ACL Data TX: Handle 1 flags 0x00 dlen 16
          L2CAP: Connection Response (0x03) ident 3 len 8
            Destination CID: 64
            Source CID: 64
            Result: Connection pending (0x0001)
            Status: Authorization pending (0x0002)
    > HCI Event: Number of Completed Packets (0x13) plen 5
            Num handles: 1
            Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Count: 1
            #35: len 16 (25 Kb/s)
            Latency: 5 msec (2-7 msec ~4 msec)
    < ACL Data TX: Handle 1 flags 0x00 dlen 16
          L2CAP: Connection Response (0x03) ident 3 len 8
            Destination CID: 64
            Source CID: 64
            Result: Connection successful (0x0000)
            Status: No further information available (0x0000)
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
    Signed-off-by: Max Chou <max.chou@realtek.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg [+ + +]
Author: Hyunwoo Kim <v4bel@theori.io>
Date:   Sat Dec 9 05:55:18 2023 -0500

    Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg
    
    commit 2e07e8348ea454615e268222ae3fc240421be768 upstream.
    
    This can cause a race with bt_sock_ioctl() because
    bt_sock_recvmsg() gets the skb from sk->sk_receive_queue
    and then frees it without holding lock_sock.
    A use-after-free for a skb occurs with the following flow.
    ```
    bt_sock_recvmsg() -> skb_recv_datagram() -> skb_free_datagram()
    bt_sock_ioctl() -> skb_peek()
    ```
    Add lock_sock to bt_sock_recvmsg() to fix this issue.
    
    Cc: stable@vger.kernel.org
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: Fix deadlock in vhci_send_frame [+ + +]
Author: Ying Hsu <yinghsu@chromium.org>
Date:   Fri Nov 10 01:46:05 2023 +0000

    Bluetooth: Fix deadlock in vhci_send_frame
    
    [ Upstream commit 769bf60e17ee1a56a81e7c031192c3928312c52e ]
    
    syzbot found a potential circular dependency leading to a deadlock:
        -> #3 (&hdev->req_lock){+.+.}-{3:3}:
        __mutex_lock_common+0x1b6/0x1bc2 kernel/locking/mutex.c:599
        __mutex_lock kernel/locking/mutex.c:732 [inline]
        mutex_lock_nested+0x17/0x1c kernel/locking/mutex.c:784
        hci_dev_do_close+0x3f/0x9f net/bluetooth/hci_core.c:551
        hci_rfkill_set_block+0x130/0x1ac net/bluetooth/hci_core.c:935
        rfkill_set_block+0x1e6/0x3b8 net/rfkill/core.c:345
        rfkill_fop_write+0x2d8/0x672 net/rfkill/core.c:1274
        vfs_write+0x277/0xcf5 fs/read_write.c:594
        ksys_write+0x19b/0x2bd fs/read_write.c:650
        do_syscall_x64 arch/x86/entry/common.c:55 [inline]
        do_syscall_64+0x51/0xba arch/x86/entry/common.c:93
        entry_SYSCALL_64_after_hwframe+0x61/0xcb
    
        -> #2 (rfkill_global_mutex){+.+.}-{3:3}:
        __mutex_lock_common+0x1b6/0x1bc2 kernel/locking/mutex.c:599
        __mutex_lock kernel/locking/mutex.c:732 [inline]
        mutex_lock_nested+0x17/0x1c kernel/locking/mutex.c:784
        rfkill_register+0x30/0x7e3 net/rfkill/core.c:1045
        hci_register_dev+0x48f/0x96d net/bluetooth/hci_core.c:2622
        __vhci_create_device drivers/bluetooth/hci_vhci.c:341 [inline]
        vhci_create_device+0x3ad/0x68f drivers/bluetooth/hci_vhci.c:374
        vhci_get_user drivers/bluetooth/hci_vhci.c:431 [inline]
        vhci_write+0x37b/0x429 drivers/bluetooth/hci_vhci.c:511
        call_write_iter include/linux/fs.h:2109 [inline]
        new_sync_write fs/read_write.c:509 [inline]
        vfs_write+0xaa8/0xcf5 fs/read_write.c:596
        ksys_write+0x19b/0x2bd fs/read_write.c:650
        do_syscall_x64 arch/x86/entry/common.c:55 [inline]
        do_syscall_64+0x51/0xba arch/x86/entry/common.c:93
        entry_SYSCALL_64_after_hwframe+0x61/0xcb
    
        -> #1 (&data->open_mutex){+.+.}-{3:3}:
        __mutex_lock_common+0x1b6/0x1bc2 kernel/locking/mutex.c:599
        __mutex_lock kernel/locking/mutex.c:732 [inline]
        mutex_lock_nested+0x17/0x1c kernel/locking/mutex.c:784
        vhci_send_frame+0x68/0x9c drivers/bluetooth/hci_vhci.c:75
        hci_send_frame+0x1cc/0x2ff net/bluetooth/hci_core.c:2989
        hci_sched_acl_pkt net/bluetooth/hci_core.c:3498 [inline]
        hci_sched_acl net/bluetooth/hci_core.c:3583 [inline]
        hci_tx_work+0xb94/0x1a60 net/bluetooth/hci_core.c:3654
        process_one_work+0x901/0xfb8 kernel/workqueue.c:2310
        worker_thread+0xa67/0x1003 kernel/workqueue.c:2457
        kthread+0x36a/0x430 kernel/kthread.c:319
        ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
    
        -> #0 ((work_completion)(&hdev->tx_work)){+.+.}-{0:0}:
        check_prev_add kernel/locking/lockdep.c:3053 [inline]
        check_prevs_add kernel/locking/lockdep.c:3172 [inline]
        validate_chain kernel/locking/lockdep.c:3787 [inline]
        __lock_acquire+0x2d32/0x77fa kernel/locking/lockdep.c:5011
        lock_acquire+0x273/0x4d5 kernel/locking/lockdep.c:5622
        __flush_work+0xee/0x19f kernel/workqueue.c:3090
        hci_dev_close_sync+0x32f/0x1113 net/bluetooth/hci_sync.c:4352
        hci_dev_do_close+0x47/0x9f net/bluetooth/hci_core.c:553
        hci_rfkill_set_block+0x130/0x1ac net/bluetooth/hci_core.c:935
        rfkill_set_block+0x1e6/0x3b8 net/rfkill/core.c:345
        rfkill_fop_write+0x2d8/0x672 net/rfkill/core.c:1274
        vfs_write+0x277/0xcf5 fs/read_write.c:594
        ksys_write+0x19b/0x2bd fs/read_write.c:650
        do_syscall_x64 arch/x86/entry/common.c:55 [inline]
        do_syscall_64+0x51/0xba arch/x86/entry/common.c:93
        entry_SYSCALL_64_after_hwframe+0x61/0xcb
    
    This change removes the need for acquiring the open_mutex in
    vhci_send_frame, thus eliminating the potential deadlock while
    maintaining the required packet ordering.
    
    Fixes: 92d4abd66f70 ("Bluetooth: vhci: Fix race when opening vhci device")
    Signed-off-by: Ying Hsu <yinghsu@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: Fix not notifying when connection encryption changes [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Oct 23 16:26:23 2023 -0700

    Bluetooth: Fix not notifying when connection encryption changes
    
    [ Upstream commit f67eabffb57d0bee379994a18ec5f462b2cbdf86 ]
    
    Some layers such as SMP depend on getting notified about encryption
    changes immediately as they only allow certain PDU to be transmitted
    over an encrypted link which may cause SMP implementation to reject
    valid PDUs received thus causing pairing to fail when it shouldn't.
    
    Fixes: 7aca0ac4792e ("Bluetooth: Wait for HCI_OP_WRITE_AUTH_PAYLOAD_TO to complete")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_core: Fix hci_conn_hash_lookup_cis [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Dec 8 17:22:29 2023 -0500

    Bluetooth: hci_core: Fix hci_conn_hash_lookup_cis
    
    [ Upstream commit 50efc63d1a7a7b9a6ed21adae1b9a7123ec8abc0 ]
    
    hci_conn_hash_lookup_cis shall always match the requested CIG and CIS
    ids even when they are unset as otherwise it result in not being able
    to bind/connect different sockets to the same address as that would
    result in having multiple sockets mapping to the same hci_conn which
    doesn't really work and prevents BAP audio configuration such as
    AC 6(i) when CIG and CIS are left unset.
    
    Fixes: c14516faede3 ("Bluetooth: hci_conn: Fix not matching by CIS ID")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_event: Fix not checking if HCI_OP_INQUIRY has been sent [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Nov 20 10:04:39 2023 -0500

    Bluetooth: hci_event: Fix not checking if HCI_OP_INQUIRY has been sent
    
    commit 99e67d46e5ff3c7c901af6009edec72d3d363be8 upstream.
    
    Before setting HCI_INQUIRY bit check if HCI_OP_INQUIRY was really sent
    otherwise the controller maybe be generating invalid events or, more
    likely, it is a result of fuzzing tools attempting to test the right
    behavior of the stack when unexpected events are generated.
    
    Cc: stable@vger.kernel.org
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218151
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_event: shut up a false-positive warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 22 23:17:44 2023 +0100

    Bluetooth: hci_event: shut up a false-positive warning
    
    [ Upstream commit a5812c68d849505ea657f653446512b85887f813 ]
    
    Turning on -Wstringop-overflow globally exposed a misleading compiler
    warning in bluetooth:
    
    net/bluetooth/hci_event.c: In function 'hci_cc_read_class_of_dev':
    net/bluetooth/hci_event.c:524:9: error: 'memcpy' writing 3 bytes into a
    region of size 0 overflows the destination [-Werror=stringop-overflow=]
      524 |         memcpy(hdev->dev_class, rp->dev_class, 3);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    The problem here is the check for hdev being NULL in bt_dev_dbg() that
    leads the compiler to conclude that hdev->dev_class might be an invalid
    pointer access.
    
    Add another explicit check for the same condition to make sure gcc sees
    this cannot happen.
    
    Fixes: a9de9248064b ("[Bluetooth] Switch from OGF+OCF to using only opcodes")
    Fixes: 1b56c90018f0 ("Makefile: Enable -Wstringop-overflow globally")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: L2CAP: Send reject on command corrupted request [+ + +]
Author: Frédéric Danis <frederic.danis@collabora.com>
Date:   Fri Dec 8 18:41:50 2023 +0100

    Bluetooth: L2CAP: Send reject on command corrupted request
    
    commit 78b99eb1faa7371bf9c534690f26a71b6996622d upstream.
    
    L2CAP/COS/CED/BI-02-C PTS test send a malformed L2CAP signaling packet
    with 2 commands in it (a connection request and an unknown command) and
    expect to get a connection response packet and a command reject packet.
    The second is currently not sent.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE [+ + +]
Author: Xiao Yao <xiaoyao@rock-chips.com>
Date:   Tue Dec 12 00:27:18 2023 +0800

    Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE
    
    commit 59b047bc98084f8af2c41483e4d68a5adf2fa7f7 upstream.
    
    If two Bluetooth devices both support BR/EDR and BLE, and also
    support Secure Connections, then they only need to pair once.
    The LTK generated during the LE pairing process may be converted
    into a BR/EDR link key for BR/EDR transport, and conversely, a
    link key generated during the BR/EDR SSP pairing process can be
    converted into an LTK for LE transport. Hence, the link type of
    the link key and LTK is not fixed, they can be either an LE LINK
    or an ACL LINK.
    
    Currently, in the mgmt_new_irk/ltk/crsk/link_key functions, the
    link type is fixed, which could lead to incorrect address types
    being reported to the application layer. Therefore, it is necessary
    to add link_type/addr_type to the smp_irk/ltk/crsk and link_key,
    to ensure the generation of the correct address type.
    
    SMP over BREDR:
    Before Fix:
    > ACL Data RX: Handle 11 flags 0x02 dlen 12
            BR/EDR SMP: Identity Address Information (0x09) len 7
            Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
    @ MGMT Event: New Identity Resolving Key (0x0018) plen 30
            Random address: 00:00:00:00:00:00 (Non-Resolvable)
            LE Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
    @ MGMT Event: New Long Term Key (0x000a) plen 37
            LE Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
            Key type: Authenticated key from P-256 (0x03)
    
    After Fix:
    > ACL Data RX: Handle 11 flags 0x02 dlen 12
          BR/EDR SMP: Identity Address Information (0x09) len 7
            Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
    @ MGMT Event: New Identity Resolving Key (0x0018) plen 30
            Random address: 00:00:00:00:00:00 (Non-Resolvable)
            BR/EDR Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
    @ MGMT Event: New Long Term Key (0x000a) plen 37
            BR/EDR Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
            Key type: Authenticated key from P-256 (0x03)
    
    SMP over LE:
    Before Fix:
    @ MGMT Event: New Identity Resolving Key (0x0018) plen 30
            Random address: 5F:5C:07:37:47:D5 (Resolvable)
            LE Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
    @ MGMT Event: New Long Term Key (0x000a) plen 37
            LE Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
            Key type: Authenticated key from P-256 (0x03)
    @ MGMT Event: New Link Key (0x0009) plen 26
            BR/EDR Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
            Key type: Authenticated Combination key from P-256 (0x08)
    
    After Fix:
    @ MGMT Event: New Identity Resolving Key (0x0018) plen 30
            Random address: 5E:03:1C:00:38:21 (Resolvable)
            LE Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
    @ MGMT Event: New Long Term Key (0x000a) plen 37
            LE Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
            Key type: Authenticated key from P-256 (0x03)
    @ MGMT Event: New Link Key (0x0009) plen 26
            Store hint: Yes (0x01)
            LE Address: F8:7D:76:F2:12:F3 (OUI F8-7D-76)
            Key type: Authenticated Combination key from P-256 (0x08)
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Xiao Yao <xiaoyao@rock-chips.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bnxt_en: do not map packet buffers twice [+ + +]
Author: Andy Gospodarek <andrew.gospodarek@broadcom.com>
Date:   Thu Dec 14 13:31:38 2023 -0800

    bnxt_en: do not map packet buffers twice
    
    [ Upstream commit 23c93c3b6275a59f2a685f4a693944b53c31df4e ]
    
    Remove double-mapping of DMA buffers as it can prevent page pool entries
    from being freed.  Mapping is managed by page pool infrastructure and
    was previously managed by the driver in __bnxt_alloc_rx_page before
    allowing the page pool infrastructure to manage it.
    
    Fixes: 578fcfd26e2a ("bnxt_en: Let the page pool manage the DMA mapping")
    Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Andy Gospodarek <andrew.gospodarek@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Reviewed-by: David Wei <dw@davidwei.uk>
    Link: https://lore.kernel.org/r/20231214213138.98095-1-michael.chan@broadcom.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Fix prog_array_map_poke_run map poke update [+ + +]
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Wed Dec 6 09:30:40 2023 +0100

    bpf: Fix prog_array_map_poke_run map poke update
    
    commit 4b7de801606e504e69689df71475d27e35336fb3 upstream.
    
    Lee pointed out issue found by syscaller [0] hitting BUG in prog array
    map poke update in prog_array_map_poke_run function due to error value
    returned from bpf_arch_text_poke function.
    
    There's race window where bpf_arch_text_poke can fail due to missing
    bpf program kallsym symbols, which is accounted for with check for
    -EINVAL in that BUG_ON call.
    
    The problem is that in such case we won't update the tail call jump
    and cause imbalance for the next tail call update check which will
    fail with -EBUSY in bpf_arch_text_poke.
    
    I'm hitting following race during the program load:
    
      CPU 0                             CPU 1
    
      bpf_prog_load
        bpf_check
          do_misc_fixups
            prog_array_map_poke_track
    
                                        map_update_elem
                                          bpf_fd_array_map_update_elem
                                            prog_array_map_poke_run
    
                                              bpf_arch_text_poke returns -EINVAL
    
        bpf_prog_kallsyms_add
    
    After bpf_arch_text_poke (CPU 1) fails to update the tail call jump, the next
    poke update fails on expected jump instruction check in bpf_arch_text_poke
    with -EBUSY and triggers the BUG_ON in prog_array_map_poke_run.
    
    Similar race exists on the program unload.
    
    Fixing this by moving the update to bpf_arch_poke_desc_update function which
    makes sure we call __bpf_arch_text_poke that skips the bpf address check.
    
    Each architecture has slightly different approach wrt looking up bpf address
    in bpf_arch_text_poke, so instead of splitting the function or adding new
    'checkip' argument in previous version, it seems best to move the whole
    map_poke_run update as arch specific code.
    
      [0] https://syzkaller.appspot.com/bug?extid=97a4fe20470e9bc30810
    
    Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT")
    Reported-by: syzbot+97a4fe20470e9bc30810@syzkaller.appspotmail.com
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Cc: Lee Jones <lee@kernel.org>
    Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Link: https://lore.kernel.org/bpf/20231206083041.1306660-2-jolsa@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bpf: syzkaller found null ptr deref in unix_bpf proto add [+ + +]
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Fri Dec 1 10:01:38 2023 -0800

    bpf: syzkaller found null ptr deref in unix_bpf proto add
    
    [ Upstream commit 8d6650646ce49e9a5b8c5c23eb94f74b1749f70f ]
    
    I added logic to track the sock pair for stream_unix sockets so that we
    ensure lifetime of the sock matches the time a sockmap could reference
    the sock (see fixes tag). I forgot though that we allow af_unix unconnected
    sockets into a sock{map|hash} map.
    
    This is problematic because previous fixed expected sk_pair() to exist
    and did not NULL check it. Because unconnected sockets have a NULL
    sk_pair this resulted in the NULL ptr dereference found by syzkaller.
    
    BUG: KASAN: null-ptr-deref in unix_stream_bpf_update_proto+0x72/0x430 net/unix/unix_bpf.c:171
    Write of size 4 at addr 0000000000000080 by task syz-executor360/5073
    Call Trace:
     <TASK>
     ...
     sock_hold include/net/sock.h:777 [inline]
     unix_stream_bpf_update_proto+0x72/0x430 net/unix/unix_bpf.c:171
     sock_map_init_proto net/core/sock_map.c:190 [inline]
     sock_map_link+0xb87/0x1100 net/core/sock_map.c:294
     sock_map_update_common+0xf6/0x870 net/core/sock_map.c:483
     sock_map_update_elem_sys+0x5b6/0x640 net/core/sock_map.c:577
     bpf_map_update_value+0x3af/0x820 kernel/bpf/syscall.c:167
    
    We considered just checking for the null ptr and skipping taking a ref
    on the NULL peer sock. But, if the socket is then connected() after
    being added to the sockmap we can cause the original issue again. So
    instead this patch blocks adding af_unix sockets that are not in the
    ESTABLISHED state.
    
    Reported-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot+e8030702aefd3444fb9e@syzkaller.appspotmail.com
    Fixes: 8866730aed51 ("bpf, sockmap: af_unix stream sockets need to hold ref for pair sock")
    Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/r/20231201180139.328529-2-john.fastabend@gmail.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: free qgroup pertrans reserve on transaction abort [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Fri Dec 1 13:00:11 2023 -0800

    btrfs: free qgroup pertrans reserve on transaction abort
    
    [ Upstream commit b321a52cce062ec7ed385333a33905d22159ce36 ]
    
    If we abort a transaction, we never run the code that frees the pertrans
    qgroup reservation. This results in warnings on unmount as that
    reservation has been leaked. The leak isn't a huge issue since the fs is
    read-only, but it's better to clean it up when we know we can/should. Do
    it during the cleanup_transaction step of aborting.
    
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: qgroup: iterate qgroups without memory allocation for qgroup_reserve() [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Sat Sep 2 08:13:52 2023 +0800

    btrfs: qgroup: iterate qgroups without memory allocation for qgroup_reserve()
    
    [ Upstream commit 686c4a5a42635e0d2889e3eb461c554fd0b616b4 ]
    
    Qgroup heavily relies on ulist to go through all the involved
    qgroups, but since we're using ulist inside fs_info->qgroup_lock
    spinlock, this means we're doing a lot of GFP_ATOMIC allocations.
    
    This patch reduces the GFP_ATOMIC usage for qgroup_reserve() by
    eliminating the memory allocation completely.
    
    This is done by moving the needed memory to btrfs_qgroup::iterator
    list_head, so that we can put all the involved qgroup into a on-stack
    list, thus eliminating the need to allocate memory while holding
    spinlock.
    
    The only cost is the slightly higher memory usage, but considering the
    reduce GFP_ATOMIC during a hot path, it should still be acceptable.
    
    Function qgroup_reserve() is the perfect start point for this
    conversion.
    
    Reviewed-by: Boris Burkov <boris@bur.io>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Stable-dep-of: b321a52cce06 ("btrfs: free qgroup pertrans reserve on transaction abort")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: qgroup: use qgroup_iterator in qgroup_convert_meta() [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Sat Sep 2 08:13:54 2023 +0800

    btrfs: qgroup: use qgroup_iterator in qgroup_convert_meta()
    
    [ Upstream commit 0913445082496c2b29668ee26521401b273838b8 ]
    
    With the new qgroup_iterator_add() and qgroup_iterator_clean(), we can
    get rid of the ulist and its GFP_ATOMIC memory allocation.
    
    Reviewed-by: Boris Burkov <boris@bur.io>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Stable-dep-of: b321a52cce06 ("btrfs: free qgroup pertrans reserve on transaction abort")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bus: ti-sysc: Flush posted write only after srst_udelay [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Fri Nov 24 10:50:56 2023 +0200

    bus: ti-sysc: Flush posted write only after srst_udelay
    
    commit f71f6ff8c1f682a1cae4e8d7bdeed9d7f76b8f75 upstream.
    
    Commit 34539b442b3b ("bus: ti-sysc: Flush posted write on enable before
    reset") caused a regression reproducable on omap4 duovero where the ISS
    target module can produce interconnect errors on boot. Turns out the
    registers are not accessible until after a delay for devices needing
    a ti,sysc-delay-us value.
    
    Let's fix this by flushing the posted write only after the reset delay.
    We do flushing also for ti,sysc-delay-us using devices as that should
    trigger an interconnect error if the delay is not properly configured.
    
    Let's also add some comments while at it.
    
    Fixes: 34539b442b3b ("bus: ti-sysc: Flush posted write on enable before reset")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm-integrity: don't modify bio's immutable bio_vec in integrity_metadata() [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Dec 5 16:39:16 2023 +0100

    dm-integrity: don't modify bio's immutable bio_vec in integrity_metadata()
    
    commit b86f4b790c998afdbc88fe1aa55cfe89c4068726 upstream.
    
    __bio_for_each_segment assumes that the first struct bio_vec argument
    doesn't change - it calls "bio_advance_iter_single((bio), &(iter),
    (bvl).bv_len)" to advance the iterator. Unfortunately, the dm-integrity
    code changes the bio_vec with "bv.bv_len -= pos". When this code path
    is taken, the iterator would be out of sync and dm-integrity would
    report errors. This happens if the machine is out of memory and
    "kmalloc" fails.
    
    Fix this bug by making a copy of "bv" and changing the copy instead.
    
    Fixes: 7eada909bfd7 ("dm: add integrity target")
    Cc: stable@vger.kernel.org      # v4.12+
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: fix hw rotated modes when PSR-SU is enabled [+ + +]
Author: Hamza Mahfooz <hamza.mahfooz@amd.com>
Date:   Tue Dec 5 14:55:04 2023 -0500

    drm/amd/display: fix hw rotated modes when PSR-SU is enabled
    
    [ Upstream commit f528ee145bd0076cd0ed7e7b2d435893e6329e98 ]
    
    We currently don't support dirty rectangles on hardware rotated modes.
    So, if a user is using hardware rotated modes with PSR-SU enabled,
    use PSR-SU FFU for all rotated planes (including cursor planes).
    
    Cc: stable@vger.kernel.org
    Fixes: 30ebe41582d1 ("drm/amd/display: add FB_DAMAGE_CLIPS support")
    Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2952
    Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Tested-by: Bin Li <binli@gnome.org>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: re-create idle bo's PTE during VM state machine reset [+ + +]
Author: ZhenGuo Yin <zhenguo.yin@amd.com>
Date:   Tue Dec 19 14:39:42 2023 +0800

    drm/amdgpu: re-create idle bo's PTE during VM state machine reset
    
    [ Upstream commit 4a0057afa35872a5f2e65576785844688dd9fa5e ]
    
    Idle bo's PTE needs to be re-created when resetting VM state machine.
    Set idle bo's vm_bo as moved to mark it as invalid.
    
    Fixes: 55bf196f60df ("drm/amdgpu: reset VM when an error is detected")
    Signed-off-by: ZhenGuo Yin <zhenguo.yin@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/dmc: Don't enable any pipe DMC events [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Dec 11 23:37:47 2023 +0200

    drm/i915/dmc: Don't enable any pipe DMC events
    
    commit 49e0a85ec3441edc6c77aa40206d6e5ee4597efc upstream.
    
    The pipe DMC seems to be making a mess of things in ADL. Various weird
    symptoms have been observed such as missing vblank irqs, typicalle
    happening when using multiple displays.
    
    Keep all pipe DMC event handlers disabled until needed (which is never
    atm). This is also what Windows does on ADL+.
    
    We can also drop DG2 from disable_all_flip_queue_events() since
    on DG2 the pipe DMC is the one that handles the flip queue events.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8685
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231211213750.27109-2-ville.syrjala@linux.intel.com
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    (cherry picked from commit 648d7be8ecf47b0556e32550145c70db153b16fb)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Dec 5 20:05:51 2023 +0200

    drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select
    
    [ Upstream commit e6861d8264cd43c5eb20196e53df36fd71ec5698 ]
    
    The eDP 1.5 spec adds a clarification for eDP 1.4x:
    
    > For eDP v1.4x, if the Source device chooses the Main-Link rate by way
    > of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
    
    We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
    DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the panel
    to ignore the rate set method.
    
    Moreover, 0 is a reserved value for DP_LINK_BW_SET, and should not be
    used.
    
    v2: Improve the comments (Ville)
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081
    Tested-by: Animesh Manna <animesh.manna@intel.com>
    Reviewed-by: Uma Shankar <uma.shankar@intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231205180551.2476228-1-jani.nikula@intel.com
    (cherry picked from commit 23b392b94acb0499f69706c5808c099f590ebcf4)
    Cc: stable@vger.kernel.org
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/hwmon: Fix static analysis tool reported issues [+ + +]
Author: Karthik Poosa <karthik.poosa@intel.com>
Date:   Mon Dec 4 20:18:09 2023 +0530

    drm/i915/hwmon: Fix static analysis tool reported issues
    
    [ Upstream commit 768f17fd25e4a98bf5166148629ecf6f647d5efc ]
    
    Updated i915 hwmon with fixes for issues reported by static analysis tool.
    Fixed integer overflow with upcasting.
    
    v2:
    - Added Fixes tag (Badal).
    - Updated commit message as per review comments (Anshuman).
    
    Fixes: 4c2572fe0ae7 ("drm/i915/hwmon: Expose power1_max_interval")
    Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
    Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
    Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
    Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231204144809.1518704-1-karthik.poosa@intel.com
    (cherry picked from commit ac3420d3d428443a08b923f9118121c170192b62)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/mtl: Fix HDMI/DP PLL clock selection [+ + +]
Author: Imre Deak <imre.deak@intel.com>
Date:   Thu Dec 14 00:05:26 2023 +0200

    drm/i915/mtl: Fix HDMI/DP PLL clock selection
    
    [ Upstream commit dbcab554f777390d9bb6a808ed0cd90ee59bb44e ]
    
    Select the HDMI specific PLL clock only for HDMI outputs.
    
    Fixes: 62618c7f117e ("drm/i915/mtl: C20 PLL programming")
    Cc: Mika Kahola <mika.kahola@intel.com>
    Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
    Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
    Signed-off-by: Imre Deak <imre.deak@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231213220526.1828827-1-imre.deak@intel.com
    (cherry picked from commit 937d02cc79c6828fef28a4d80d8d0ad2f7bf2b62)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915: Fix FEC state dump [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue May 2 17:39:01 2023 +0300

    drm/i915: Fix FEC state dump
    
    [ Upstream commit 3dfeb80b308882cc6e1f5f6c36fd9a7f4cae5fc6 ]
    
    Stop dumping state while reading it out. We have a proper
    place for that stuff.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230502143906.2401-7-ville.syrjala@linux.intel.com
    Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
    Stable-dep-of: e6861d8264cd ("drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915: Introduce crtc_state->enhanced_framing [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed May 3 14:36:59 2023 +0300

    drm/i915: Introduce crtc_state->enhanced_framing
    
    [ Upstream commit 3072a24c778a7102d70692af5556e47363114c67 ]
    
    Track DP enhanced framing properly in the crtc state instead
    of relying just on the cached DPCD everywhere, and hook it
    up into the state check and dump.
    
    v2: Actually set enhanced_framing in .compute_config()
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230503113659.16305-1-ville.syrjala@linux.intel.com
    Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
    Stable-dep-of: e6861d8264cd ("drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915: Reject async flips with bigjoiner [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Dec 11 10:11:34 2023 +0200

    drm/i915: Reject async flips with bigjoiner
    
    commit 88a173e5dd05e788068e8fa20a8c37c44bd8f416 upstream.
    
    Currently async flips are busted when bigjoiner is in use.
    As a short term fix simply reject async flips in that case.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9769
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231211081134.2698-1-ville.syrjala@linux.intel.com
    Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
    (cherry picked from commit e93bffc2ac0a833b42841f31fff955549d38ce98)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm: Fix FD ownership check in drm_master_check_perm() [+ + +]
Author: Lingkai Dong <Lingkai.Dong@arm.com>
Date:   Wed Dec 6 13:51:58 2023 +0000

    drm: Fix FD ownership check in drm_master_check_perm()
    
    [ Upstream commit 5a6c9a05e55cb2972396cc991af9d74c8c15029a ]
    
    The DRM subsystem keeps a record of the owner of a DRM device file
    descriptor using thread group ID (TGID) instead of process ID (PID), to
    ensures all threads within the same userspace process are considered the
    owner. However, the DRM master ownership check compares the current
    thread's PID against the record, so the thread is incorrectly considered to
    be not the FD owner if the PID is not equal to the TGID. This causes DRM
    ioctls to be denied master privileges, even if the same thread that opened
    the FD performs an ioctl. Fix this by checking TGID.
    
    Fixes: 4230cea89cafb ("drm: Track clients by tgid and not tid")
    Signed-off-by: Lingkai Dong <lingkai.dong@arm.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Cc: <stable@vger.kernel.org> # v6.4+
    Link: https://patchwork.freedesktop.org/patch/msgid/PA6PR08MB107665920BE9A96658CDA04CE8884A@PA6PR08MB10766.eurprd08.prod.outlook.com
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: Update file owner during use [+ + +]
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date:   Wed Jun 21 10:48:24 2023 +0100

    drm: Update file owner during use
    
    [ Upstream commit 1c7a387ffef894b1ab3942f0482dac7a6e0a909c ]
    
    With the typical model where the display server opens the file descriptor
    and then hands it over to the client(*), we were showing stale data in
    debugfs.
    
    Fix it by updating the drm_file->pid on ioctl access from a different
    process.
    
    The field is also made RCU protected to allow for lockless readers. Update
    side is protected with dev->filelist_mutex.
    
    Before:
    
    $ cat /sys/kernel/debug/dri/0/clients
                 command   pid dev master a   uid      magic
                    Xorg  2344   0   y    y     0          0
                    Xorg  2344   0   n    y     0          2
                    Xorg  2344   0   n    y     0          3
                    Xorg  2344   0   n    y     0          4
    
    After:
    
    $ cat /sys/kernel/debug/dri/0/clients
                 command  tgid dev master a   uid      magic
                    Xorg   830   0   y    y     0          0
           xfce4-session   880   0   n    y     0          1
                   xfwm4   943   0   n    y     0          2
               neverball  1095   0   n    y     0          3
    
    *)
    More detailed and historically accurate description of various handover
    implementation kindly provided by Emil Velikov:
    
    """
    The traditional model, the server was the orchestrator managing the
    primary device node. From the fd, to the master status and
    authentication. But looking at the fd alone, this has varied across
    the years.
    
    IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open
    fd(s) and reuse those whenever needed, DRI2 the client was responsible
    for open() themselves and with DRI3 the fd was passed to the client.
    
    Around the inception of DRI3 and systemd-logind, the latter became
    another possible orchestrator. Whereby Xorg and Wayland compositors
    could ask it for the fd. For various reasons (hysterical and genuine
    ones) Xorg has a fallback path going the open(), whereas Wayland
    compositors are moving to solely relying on logind... some never had
    fallback even.
    
    Over the past few years, more projects have emerged which provide
    functionality similar (be that on API level, Dbus, or otherwise) to
    systemd-logind.
    """
    
    v2:
     * Fixed typo in commit text and added a fine historical explanation
       from Emil.
    
    Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Cc: "Christian König" <christian.koenig@amd.com>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Tested-by: Rob Clark <robdclark@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230621094824.2348732-1-tvrtko.ursulin@linux.intel.com
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Stable-dep-of: 5a6c9a05e55c ("drm: Fix FD ownership check in drm_master_check_perm()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: nvmem: mxs-ocotp: Document fsl,ocotp [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Fri Dec 15 11:13:57 2023 +0000

    dt-bindings: nvmem: mxs-ocotp: Document fsl,ocotp
    
    commit a2a8aefecbd0f87d6127951cef33b3def8439057 upstream.
    
    Both imx23.dtsi and imx28.dtsi describe the OCOTP nodes in
    the format:
    
    compatible = "fsl,imx28-ocotp", "fsl,ocotp";
    
    Document the "fsl,ocotp" entry to fix the following schema
    warning:
    
    efuse@8002c000: compatible: ['fsl,imx23-ocotp', 'fsl,ocotp'] is too long
    from schema $id: http://devicetree.org/schemas/nvmem/mxs-ocotp.yaml#
    
    Fixes: 2c504460f502 ("dt-bindings: nvmem: Convert MXS OCOTP to json-schema")
    Cc:  <Stable@vger.kernel.org>
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20231215111358.316727-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ethernet: atheros: fix a memleak in atl1e_setup_ring_resources [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Thu Dec 14 21:04:04 2023 +0800

    ethernet: atheros: fix a memleak in atl1e_setup_ring_resources
    
    [ Upstream commit 309fdb1c33fe726d92d0030481346f24e1b01f07 ]
    
    In the error handling of 'offset > adapter->ring_size', the
    tx_ring->tx_buffer allocated by kzalloc should be freed,
    instead of 'goto failed' instantly.
    
    Fixes: a6a5325239c2 ("atl1e: Atheros L1E Gigabit Ethernet driver")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Reviewed-by: Suman Ghosh <sumang@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpio: dwapb: mask/unmask IRQ when disable/enale it [+ + +]
Author: xiongxin <xiongxin@kylinos.cn>
Date:   Wed Dec 20 10:29:01 2023 +0800

    gpio: dwapb: mask/unmask IRQ when disable/enale it
    
    commit 1cc3542c76acb5f59001e3e562eba672f1983355 upstream.
    
    In the hardware implementation of the I2C HID driver based on DesignWare
    GPIO IRQ chip, when the user continues to use the I2C HID device in the
    suspend process, the I2C HID interrupt will be masked after the resume
    process is finished.
    
    This is because the disable_irq()/enable_irq() of the DesignWare GPIO
    driver does not synchronize the IRQ mask register state. In normal use
    of the I2C HID procedure, the GPIO IRQ irq_mask()/irq_unmask() functions
    are called in pairs. In case of an exception, i2c_hid_core_suspend()
    calls disable_irq() to disable the GPIO IRQ. With low probability, this
    causes irq_unmask() to not be called, which causes the GPIO IRQ to be
    masked and not unmasked in enable_irq(), raising an exception.
    
    Add synchronization to the masked register state in the
    dwapb_irq_enable()/dwapb_irq_disable() function. mask the GPIO IRQ
    before disabling it. After enabling the GPIO IRQ, unmask the IRQ.
    
    Fixes: 7779b3455697 ("gpio: add a driver for the Synopsys DesignWare APB GPIO block")
    Cc: stable@kernel.org
    Co-developed-by: Riwen Lu <luriwen@kylinos.cn>
    Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
    Signed-off-by: xiongxin <xiongxin@kylinos.cn>
    Acked-by: Serge Semin <fancer.lancer@gmail.com>
    Reviewed-by: Andy Shevchenko <andy@kernel.org>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpiolib: cdev: add gpio_device locking wrapper around gpio_ioctl() [+ + +]
Author: Kent Gibson <warthog618@gmail.com>
Date:   Thu Dec 21 09:20:36 2023 +0800

    gpiolib: cdev: add gpio_device locking wrapper around gpio_ioctl()
    
    [ Upstream commit 1d656bd259edb89dc1d9938ec5c5389867088546 ]
    
    While the GPIO cdev gpio_ioctl() call is in progress, the kernel can
    call gpiochip_remove() which will set gdev->chip to NULL, after which
    any subsequent access will cause a crash.
    
    gpio_ioctl() was overlooked by the previous fix to protect syscalls
    (bdbbae241a04), so add protection for that.
    
    Fixes: bdbbae241a04 ("gpiolib: protect the GPIO device against being dropped while in use by user-space")
    Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines")
    Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL")
    Fixes: aad955842d1c ("gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL")
    Signed-off-by: Kent Gibson <warthog618@gmail.com>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: aspeed: Handle the coalesced stop conditions with the start conditions. [+ + +]
Author: Quan Nguyen <quan@os.amperecomputing.com>
Date:   Mon Dec 11 17:22:16 2023 +0700

    i2c: aspeed: Handle the coalesced stop conditions with the start conditions.
    
    [ Upstream commit b4cc1cbba5195a4dd497cf2f8f09e7807977d543 ]
    
    Some masters may drive the transfers with low enough latency between
    the nak/stop phase of the current command and the start/address phase
    of the following command that the interrupts are coalesced by the
    time we process them.
    Handle the stop conditions before processing SLAVE_MATCH to fix the
    complaints that sometimes occur below.
    
    "aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
    0x00000086, but was 0x00000084"
    
    Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
    Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com>
    Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: qcom-geni: fix missing clk_disable_unprepare() and geni_se_resources_off() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Nov 30 09:43:24 2023 +0800

    i2c: qcom-geni: fix missing clk_disable_unprepare() and geni_se_resources_off()
    
    [ Upstream commit 043465b66506e8c647cdd38a2db1f2ee0f369a1b ]
    
    Add missing clk_disable_unprepare() and geni_se_resources_off() in the error
    path in geni_i2c_probe().
    
    Fixes: 14d02fbadb5d ("i2c: qcom-geni: add desc struct to prepare support for I2C Master Hub variant")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ice: alter feature support check for SRIOV and LAG [+ + +]
Author: Dave Ertman <david.m.ertman@intel.com>
Date:   Mon Dec 11 13:19:28 2023 -0800

    ice: alter feature support check for SRIOV and LAG
    
    [ Upstream commit 4d50fcdc2476eef94c14c6761073af5667bb43b6 ]
    
    Previously, the ice driver had support for using a handler for bonding
    netdev events to ensure that conflicting features were not allowed to be
    activated at the same time.  While this was still in place, additional
    support was added to specifically support SRIOV and LAG together.  These
    both utilized the netdev event handler, but the SRIOV and LAG feature was
    behind a capabilities feature check to make sure the current NVM has
    support.
    
    The exclusion part of the event handler should be removed since there are
    users who have custom made solutions that depend on the non-exclusion of
    features.
    
    Wrap the creation/registration and cleanup of the event handler and
    associated structs in the probe flow with a feature check so that the
    only systems that support the full implementation of LAG features will
    initialize support.  This will leave other systems unhindered with
    functionality as it existed before any LAG code was added.
    
    Fixes: bb52f42acef6 ("ice: Add driver support for firmware changes for LAG")
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: Fix PF with enabled XDP going no-carrier after reset [+ + +]
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date:   Tue Dec 12 10:29:01 2023 +0100

    ice: Fix PF with enabled XDP going no-carrier after reset
    
    [ Upstream commit f5728a418945ba53e2fdf38a6e5c5a2670965e85 ]
    
    Commit 6624e780a577fc596788 ("ice: split ice_vsi_setup into smaller
    functions") has refactored a bunch of code involved in PFR. In this
    process, TC queue number adjustment for XDP was lost. Bring it back.
    
    Lack of such adjustment causes interface to go into no-carrier after a
    reset, if XDP program is attached, with the following message:
    
    ice 0000:b1:00.0: Failed to set LAN Tx queue context, error: -22
    ice 0000:b1:00.0 ens801f0np0: Failed to open VSI 0x0006 on switch 0x0001
    ice 0000:b1:00.0: enable VSI failed, err -22, VSI index 0, type ICE_VSI_PF
    ice 0000:b1:00.0: PF VSI rebuild failed: -22
    ice 0000:b1:00.0: Rebuild failed, unload and reload driver
    
    Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions")
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: fix theoretical out-of-bounds access in ethtool link modes [+ + +]
Author: Michal Schmidt <mschmidt@redhat.com>
Date:   Thu Nov 30 17:58:06 2023 +0100

    ice: fix theoretical out-of-bounds access in ethtool link modes
    
    [ Upstream commit 91f9181c738101a276d9da333e0ab665ad806e6d ]
    
    To map phy types reported by the hardware to ethtool link mode bits,
    ice uses two lookup tables (phy_type_low_lkup, phy_type_high_lkup).
    The "low" table has 64 elements to cover every possible bit the hardware
    may report, but the "high" table has only 13. If the hardware reports a
    higher bit in phy_types_high, the driver would access memory beyond the
    lookup table's end.
    
    Instead of iterating through all 64 bits of phy_types_{low,high}, use
    the sizes of the respective lookup tables.
    
    Fixes: 9136e1f1e5c3 ("ice: refactor PHY type to ethtool link mode")
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: stop trashing VF VSI aggregator node ID information [+ + +]
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Wed Dec 6 12:19:05 2023 -0800

    ice: stop trashing VF VSI aggregator node ID information
    
    [ Upstream commit 7d881346121a97756f34e00e6296a5d63f001f7f ]
    
    When creating new VSIs, they are assigned into an aggregator node in the
    scheduler tree. Information about which aggregator node a VSI is assigned
    into is maintained by the vsi->agg_node structure. In ice_vsi_decfg(), this
    information is being destroyed, by overwriting the valid flag and the
    agg_id field to zero.
    
    For VF VSIs, this breaks the aggregator node configuration replay, which
    depends on this information. This results in VFs being inserted into the
    default aggregator node. The resulting configuration will have unexpected
    Tx bandwidth sharing behavior.
    
    This was broken by commit 6624e780a577 ("ice: split ice_vsi_setup into
    smaller functions"), which added the block to reset the agg_node data.
    
    The vsi->agg_node structure is not managed by the scheduler code, but is
    instead a wrapper around an aggregator node ID that is tracked at the VSI
    layer. Its been around for a long time, and its primary purpose was for
    handling VFs. The SR-IOV VF reset flow does not make use of the standard VSI
    rebuild/replay logic, and uses vsi->agg_node as part of its handling to
    rebuild the aggregator node configuration.
    
    The logic for aggregator nodes stretches  back to early ice driver code from
    commit b126bd6bcd67 ("ice: create scheduler aggregator node config and move
    VSIs")
    
    The logic in ice_vsi_decfg() which trashes the ice_agg_node data is clearly
    wrong. It destroys information that is necessary for handling VF reset,. It
    is also not the correct way to actually remove a VSI from an aggregator
    node. For that, we need to implement logic in the scheduler code. Further,
    non-VF VSIs properly replay their aggregator configuration using existing
    scheduler replay logic.
    
    To fix the VF replay logic, remove this broken aggregator node cleanup
    logic. This is the simplest way to immediately fix this.
    
    This ensures that VFs will have proper aggregate configuration after a
    reset. This is especially important since VFs often perform resets as part
    of their reconfiguration flows. Without fixing this, VFs will be placed in
    the default aggregator node and Tx bandwidth will not be shared in the
    expected and configured manner.
    
    Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions")
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: adc: imx93: add four channels for imx93 adc [+ + +]
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Thu Nov 16 15:10:26 2023 +0800

    iio: adc: imx93: add four channels for imx93 adc
    
    commit 2475ecdb9b6e177b133cf26e64e8d441d37bebde upstream.
    
    According to the spec, this ADC totally support 8 channels.
    i.MX93 contain this ADC with 4 channels connected to pins in
    the package. i.MX95 contain this ADC with 8 channels connected
    to pins in the package.
    
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Fixes: 7d02296ac8b8 ("iio: adc: add imx93 adc support")
    Link: https://lore.kernel.org/r/20231116071026.611269-1-haibo.chen@nxp.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adc: meson: add separate config for axg SoC family [+ + +]
Author: George Stark <gnstark@salutedevices.com>
Date:   Tue Nov 28 02:55:58 2023 +0300

    iio: adc: meson: add separate config for axg SoC family
    
    [ Upstream commit 59b75dcb0953813676b5030877f3f37cedaed87d ]
    
    According to Amlogic custom kernels ADC of axg SoC family has
    vref_select and requires this setting to work nominally and thus
    needs a separate config.
    
    Fixes: 90c6241860bf ("iio: adc: meson: init voltage control bits")
    Signed-off-by: George Stark <gnstark@salutedevices.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20231127235558.71995-1-gnstark@salutedevices.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ti_am335x_adc: Fix return value check of tiadc_request_dma() [+ + +]
Author: Wadim Egorov <w.egorov@phytec.de>
Date:   Mon Sep 25 15:44:27 2023 +0200

    iio: adc: ti_am335x_adc: Fix return value check of tiadc_request_dma()
    
    commit 60576e84c187043cef11f11d015249e71151d35a upstream.
    
    Fix wrong handling of a DMA request where the probing only failed
    if -EPROPE_DEFER was returned. Instead, let us fail if a non -ENODEV
    value is returned. This makes DMAs explicitly optional. Even if the
    DMA request is unsuccessfully, the ADC can still work properly.
    We do also handle the defer probe case by making use of dev_err_probe().
    
    Fixes: f438b9da75eb ("drivers: iio: ti_am335x_adc: add dma support")
    Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
    Reviewed-by: Bhavya Kapoor <b-kapoor@ti.com>
    Link: https://lore.kernel.org/r/20230925134427.214556-1-w.egorov@phytec.de
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: common: ms_sensors: ms_sensors_i2c: fix humidity conversion time table [+ + +]
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Thu Oct 26 17:44:49 2023 +0200

    iio: common: ms_sensors: ms_sensors_i2c: fix humidity conversion time table
    
    commit 54cf39ec16335dadbe1ba008d8e5e98dae3e26f8 upstream.
    
    The HTU21 offers 4 sampling frequencies: 20, 40, 70 and 120, which are
    associated to an index that is used to select the right measurement
    resolution and its corresponding measurement time. The current
    implementation selects the measurement resolution and the temperature
    measurement time properly, but it does not select the right humidity
    measurement time in all cases.
    
    In summary, the 40 and 70 humidity measurement times are swapped.
    
    The reason for that is probably the unusual coding for the measurement
    resolution. According to the datasheet, the bits [7,0] of the "user
    register" are used as follows to select the bit resolution:
    
    --------------------------------------------------
    | Bit 7 | Bit 0 | RH | Temp | Trh (us) | Tt (us) |
    --------------------------------------------------
    |   0   |   0   | 12 |  14  |  16000   |  50000  |
    --------------------------------------------------
    |   0   |   1   | 8  |  12  |  3000    |  13000  |
    --------------------------------------------------
    |   1   |   0   | 10 |  13  |  5000    |  25000  |
    --------------------------------------------------
    |   1   |   1   | 11 |  11  |  8000    |  7000   |
    --------------------------------------------------
    *This table is available in the official datasheet, page 13/21. I have
    just appended the times provided in the humidity/temperature tables,
    pages 3/21, 5/21. Note that always a pair of resolutions is selected.
    
    The sampling frequencies [20, 40, 70, 120] are assigned to a linear
    index [0..3] which is then coded as follows [1]:
    
    Index    [7,0]
    --------------
    idx 0     0,0
    idx 1     1,0
    idx 2     0,1
    idx 3     1,1
    
    That is done that way because the temperature measurements are being
    used as the reference for the sampling frequency (the frequencies and
    the temperature measurement times are correlated), so increasing the
    index always reduces the temperature measurement time and its
    resolution. Therefore, the temperature measurement time array is as
    simple as [50000, 25000, 13000, 7000]
    
    On the other hand, the humidity resolution cannot follow the same
    pattern because of the way it is coded in the "user register", where
    both resolutions are selected at the same time. The humidity measurement
    time array is the following: [16000, 3000, 5000, 8000], which defines
    the following assignments:
    
    Index    [7,0]    Trh
    -----------------------
    idx 0     0,0     16000  -> right, [0,0] selects 12 bits (Trh = 16000)
    idx 1     1,0     3000   -> wrong! [1,0] selects 10 bits (Trh = 5000)
    idx 2     0,1     5000   -> wrong! [0,1] selects 8 bits (Trh = 3000)
    idx 3     1,1     8000   -> right, [1,1] selects 11 bits (Trh = 8000)
    
    The times have been ordered as if idx = 1 -> [0,1] and idx = 2 -> [1,0],
    which is not the case for the reason explained above.
    
    So a simple modification is required to obtain the right humidity
    measurement time array, swapping the values in the positions 1 and 2.
    
    The right table should be the following: [16000, 5000, 3000, 8000]
    
    Fix the humidity measurement time array with the right idex/value
    coding.
    
    [1] The actual code that makes this coding and assigns it to the current
    value of the "user register" is the following:
    config_reg &= 0x7E;
    config_reg |= ((i & 1) << 7) + ((i & 2) >> 1);
    
    Fixes: d574a87cc311 ("Add meas-spec sensors common part")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Link: https://lore.kernel.org/r/20231026-topic-htu21_conversion_time-v1-1-bd257dc44209@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: imu: adis16475: add spi_device_id table [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Thu Nov 2 13:52:58 2023 +0100

    iio: imu: adis16475: add spi_device_id table
    
    commit ee4d79055aeea27f1b8c42233cc0c90d0a8b5355 upstream.
    
    This prevents the warning message "SPI driver has no spi_device_id for..."
    when registering the driver. More importantly, it makes sure that
    module autoloading works as spi relies on spi: modaliases and not of.
    
    While at it, move the of_device_id table to it's natural place.
    
    Fixes: fff7352bf7a3c ("iio: imu: Add support for adis16475")
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20231102125258.3284830-1-nuno.sa@analog.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: imu: inv_mpu6050: fix an error code problem in inv_mpu6050_read_raw [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Mon Oct 30 10:02:19 2023 +0800

    iio: imu: inv_mpu6050: fix an error code problem in inv_mpu6050_read_raw
    
    [ Upstream commit c3df0e29fb7788c4b3ddf37d5ed87dda2b822943 ]
    
    inv_mpu6050_sensor_show() can return -EINVAL or IIO_VAL_INT. Return the
    true value rather than only return IIO_VAL_INT.
    
    Fixes: d5098447147c ("iio: imu: mpu6050: add calibration offset support")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Link: https://lore.kernel.org/r/20231030020218.65728-1-suhui@nfschina.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: kx022a: Fix acceleration value scaling [+ + +]
Author: Matti Vaittinen <mazziesaccount@gmail.com>
Date:   Thu Oct 19 16:23:56 2023 +0300

    iio: kx022a: Fix acceleration value scaling
    
    commit 92bfa4ab1b79be95c4f52d13f5386390f0a513c2 upstream.
    
    The IIO ABI mandates acceleration values from accelerometer to be
    emitted in m/s^2. The KX022A was emitting values in micro m/s^2.
    
    Fix driver to report the correct scale values.
    
    Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Reported-by: Jagath Jog J <jagathjog1996@gmail.com>
    Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer")
    Tested-by: Jagath Jog J <jagathjog1996@gmail.com>
    Link: https://lore.kernel.org/r/ZTEt7NqfDHPOkm8j@dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: tmag5273: fix temperature offset [+ + +]
Author: Javier Carrasco <javier.carrasco@wolfvision.net>
Date:   Tue Nov 21 06:48:39 2023 +0100

    iio: tmag5273: fix temperature offset
    
    commit 3b8157ec4573e304a29b7bced627e144dbc3dfdb upstream.
    
    The current offset has the scale already applied to it. The ABI
    documentation defines the offset parameter as "offset to be added
    to <type>[Y]_raw prior to scaling by <type>[Y]_scale in order to
    obtain value in the <type> units as specified in <type>[Y]_raw
    documentation"
    
    The right value is obtained at 0 degrees Celsius by the formula provided
    in the datasheet:
    
    T = Tsens_t0 + (Tadc_t - Tadc_t0) / Tadc_res
    
    where:
    T = 0 degrees Celsius
    Tsens_t0 (reference temperature) = 25 degrees Celsius
    Tadc_t0 (16-bit format for Tsens_t0) = 17508
    Tadc_res = 60.1 LSB/degree Celsius
    
    The resulting offset is 16005.5, which has been truncated to 16005 to
    provide an integer value with a precision loss smaller than the 1-LSB
    measurement precision.
    
    Fix the offset to apply its value prior to scaling.
    
    Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
    Link: https://lore.kernel.org/r/9879beec-05fc-4fc6-af62-d771e238954e@wolfvision.net
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: triggered-buffer: prevent possible freeing of wrong buffer [+ + +]
Author: David Lechner <dlechner@baylibre.com>
Date:   Tue Oct 31 16:05:19 2023 -0500

    iio: triggered-buffer: prevent possible freeing of wrong buffer
    
    commit bce61476dc82f114e24e9c2e11fb064781ec563c upstream.
    
    Commit ee708e6baacd ("iio: buffer: introduce support for attaching more
    IIO buffers") introduced support for multiple buffers per indio_dev but
    left indio_dev->buffer for a few legacy use cases.
    
    In the case of the triggered buffer, iio_triggered_buffer_cleanup()
    still assumes that indio_dev->buffer points to the buffer allocated by
    iio_triggered_buffer_setup_ext(). However, since
    iio_triggered_buffer_setup_ext() now calls iio_device_attach_buffer()
    to attach the buffer, indio_dev->buffer will only point to the buffer
    allocated by iio_device_attach_buffer() if it the first buffer attached.
    
    This adds a check to make sure that no other buffer has been attached
    yet to ensure that indio_dev->buffer will be assigned when
    iio_device_attach_buffer() is called.
    
    As per discussion in the review thread, we may want to deal with multiple
    triggers per device, but this is a fix for the issue in the meantime and
    any such support would be unlikely to be suitable for a backport.
    
    Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers")
    Signed-off-by: David Lechner <dlechner@baylibre.com>
    Acked-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20231031210521.1661552-1-dlechner@baylibre.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Input: ipaq-micro-keys - add error handling for devm_kmemdup [+ + +]
Author: Haoran Liu <liuhaoran14@163.com>
Date:   Sun Dec 3 19:00:23 2023 +0000

    Input: ipaq-micro-keys - add error handling for devm_kmemdup
    
    [ Upstream commit 59b6a747e2d39227ac2325c5e29d6ab3bb070c2a ]
    
    Check the return value of i2c_add_adapter. Static analysis revealed that
    the function did not properly handle potential failures of
    i2c_add_adapter, which could lead to partial initialization of the I2C
    adapter and unstable operation.
    
    Signed-off-by: Haoran Liu <liuhaoran14@163.com>
    Link: https://lore.kernel.org/r/20231203164653.38983-1-liuhaoran14@163.com
    Fixes: d7535ffa427b ("Input: driver for microcontroller keys on the iPaq h3xxx")
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: soc_button_array - add mapping for airplane mode button [+ + +]
Author: Christoffer Sandberg <cs@tuxedo.de>
Date:   Fri Dec 22 23:25:38 2023 -0800

    Input: soc_button_array - add mapping for airplane mode button
    
    commit ea3715941a9b7d816a1e9096ac0577900af2a69e upstream.
    
    This add a mapping for the airplane mode button on the TUXEDO Pulse Gen3.
    
    While it is physically a key it behaves more like a switch, sending a key
    down on first press and a key up on 2nd press. Therefor the switch event
    is used here. Besides this behaviour it uses the HID usage-id 0xc6
    (Wireless Radio Button) and not 0xc8 (Wireless Radio Slider Switch), but
    since neither 0xc6 nor 0xc8 are currently implemented at all in
    soc_button_array this not to standard behaviour is not put behind a quirk
    for the moment.
    
    Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Link: https://lore.kernel.org/r/20231215171718.80229-1-wse@tuxedocomputers.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
interconnect: qcom: sm8250: Enable sync_state [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Thu Nov 30 15:04:45 2023 +0100

    interconnect: qcom: sm8250: Enable sync_state
    
    [ Upstream commit bfc7db1cb94ad664546d70212699f8cc6c539e8c ]
    
    Add the generic icc sync_state callback to ensure interconnect votes
    are taken into account, instead of being pegged at maximum values.
    
    Fixes: b95b668eaaa2 ("interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231130-topic-8250icc_syncstate-v1-1-7ce78ba6e04c@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: Treat xlate() returning NULL node as an error [+ + +]
Author: Mike Tipton <quic_mdtipton@quicinc.com>
Date:   Wed Oct 25 07:58:29 2023 -0700

    interconnect: Treat xlate() returning NULL node as an error
    
    [ Upstream commit ad2ab1297d0c80899125a842bb7a078abfe1e6ce ]
    
    Currently, if provider->xlate() or provider->xlate_extended()
    "successfully" return a NULL node, then of_icc_get_from_provider() won't
    consider that an error and will successfully return the NULL node. This
    bypasses error handling in of_icc_get_by_index() and leads to NULL
    dereferences in path_find().
    
    This could be avoided by ensuring provider callbacks always return an
    error for NULL nodes, but it's better to explicitly protect against this
    in the common framework.
    
    Fixes: 87e3031b6fbd ("interconnect: Allow endpoints translation via DT")
    Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com>
    Link: https://lore.kernel.org/r/20231025145829.11603-1-quic_mdtipton@quicinc.com
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Sat Dec 9 00:41:55 2023 +0000

    keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry
    
    [ Upstream commit 39299bdd2546688d92ed9db4948f6219ca1b9542 ]
    
    If a key has an expiration time, then when that time passes, the key is
    left around for a certain amount of time before being collected (5 mins by
    default) so that EKEYEXPIRED can be returned instead of ENOKEY.  This is a
    problem for DNS keys because we want to redo the DNS lookup immediately at
    that point.
    
    Fix this by allowing key types to be marked such that keys of that type
    don't have this extra period, but are reclaimed as soon as they expire and
    turn this on for dns_resolver-type keys.  To make this easier to handle,
    key->expiry is changed to be permanent if TIME64_MAX rather than 0.
    
    Furthermore, give such new-style negative DNS results a 1s default expiry
    if no other expiry time is set rather than allowing it to stick around
    indefinitely.  This shouldn't be zero as ls will follow a failing stat call
    immediately with a second with AT_SYMLINK_NOFOLLOW added.
    
    Fixes: 1a4240f4764a ("DNS: Separate out CIFS DNS Resolver code")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Markus Suvanto <markus.suvanto@gmail.com>
    cc: Wang Lei <wang840925@gmail.com>
    cc: Jeff Layton <jlayton@redhat.com>
    cc: Steve French <smfrench@gmail.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: Jarkko Sakkinen <jarkko@kernel.org>
    cc: "David S. Miller" <davem@davemloft.net>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Jakub Kicinski <kuba@kernel.org>
    cc: Paolo Abeni <pabeni@redhat.com>
    cc: linux-afs@lists.infradead.org
    cc: linux-cifs@vger.kernel.org
    cc: linux-nfs@vger.kernel.org
    cc: ceph-devel@vger.kernel.org
    cc: keyrings@vger.kernel.org
    cc: netdev@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: arm64: vgic: Add a non-locking primitive for kvm_vgic_vcpu_destroy() [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Thu Dec 7 15:11:58 2023 +0000

    KVM: arm64: vgic: Add a non-locking primitive for kvm_vgic_vcpu_destroy()
    
    commit d26b9cb33c2d1ba68d1f26bb06c40300f16a3799 upstream.
    
    As we are going to need to call into kvm_vgic_vcpu_destroy() without
    prior holding of the slots_lock, introduce __kvm_vgic_vcpu_destroy()
    as a non-locking primitive of kvm_vgic_vcpu_destroy().
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20231207151201.3028710-3-maz@kernel.org
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Thu Dec 7 15:11:59 2023 +0000

    KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy
    
    commit 02e3858f08faabab9503ae2911cf7c7e27702257 upstream.
    
    When failing to create a vcpu because (for example) it has a
    duplicate vcpu_id, we destroy the vcpu. Amusingly, this leaves
    the redistributor registered with the KVM_MMIO bus.
    
    This is no good, and we should properly clean the mess. Force
    a teardown of the vgic vcpu interface, including the RD device
    before returning to the caller.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20231207151201.3028710-4-maz@kernel.org
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: arm64: vgic: Simplify kvm_vgic_destroy() [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Thu Dec 7 15:11:57 2023 +0000

    KVM: arm64: vgic: Simplify kvm_vgic_destroy()
    
    commit 01ad29d224ff73bc4e16e0ef9ece17f28598c4a4 upstream.
    
    When destroying a vgic, we have rather cumbersome rules about
    when slots_lock and config_lock are held, resulting in fun
    buglets.
    
    The first port of call is to simplify kvm_vgic_map_resources()
    so that there is only one call to kvm_vgic_destroy() instead of
    two, with the second only holding half of the locks.
    
    For that, we kill the non-locking primitive and move the call
    outside of the locking altogether. This doesn't change anything
    (we re-acquire the locks and teardown the whole vgic), and
    simplifies the code significantly.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20231207151201.3028710-2-maz@kernel.org
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lib/vsprintf: Fix %pfwf when current node refcount == 0 [+ + +]
Author: Herve Codina <herve.codina@bootlin.com>
Date:   Tue Nov 14 16:26:55 2023 +0100

    lib/vsprintf: Fix %pfwf when current node refcount == 0
    
    commit 5c47251e8c4903111608ddcba2a77c0c425c247c upstream.
    
    A refcount issue can appeared in __fwnode_link_del() due to the
    pr_debug() call:
      WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
      Call Trace:
      <TASK>
      ...
      of_node_get+0x1e/0x30
      of_fwnode_get+0x28/0x40
      fwnode_full_name_string+0x34/0x90
      fwnode_string+0xdb/0x140
      ...
      vsnprintf+0x17b/0x630
      ...
      __fwnode_link_del+0x25/0xa0
      fwnode_links_purge+0x39/0xb0
      of_node_release+0xd9/0x180
      ...
    
    Indeed, an fwnode (of_node) is being destroyed and so, of_node_release()
    is called because the of_node refcount reached 0.
    From of_node_release() several function calls are done and lead to
    a pr_debug() calls with %pfwf to print the fwnode full name.
    The issue is not present if we change %pfwf to %pfwP.
    
    To print the full name, %pfwf iterates over the current node and its
    parents and obtain/drop a reference to all nodes involved.
    
    In order to allow to print the full name (%pfwf) of a node while it is
    being destroyed, do not obtain/drop a reference to this current node.
    
    Fixes: a92eb7621b9f ("lib/vsprintf: Make use of fwnode API to obtain node names and separators")
    Cc: stable@vger.kernel.org
    Signed-off-by: Herve Codina <herve.codina@bootlin.com>
    Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20231114152655.409331-1-herve.codina@bootlin.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.6.9 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Jan 1 12:42:47 2024 +0000

    Linux 6.6.9
    
    Link: https://lore.kernel.org/r/20231230115812.333117904@linuxfoundation.org
    Tested-by: Ricardo B. Marliere <ricardo@marliere.net>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/damon/core: make damon_start() waits until kdamond_fn() starts [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Fri Dec 8 17:50:18 2023 +0000

    mm/damon/core: make damon_start() waits until kdamond_fn() starts
    
    [ Upstream commit 6376a824595607e99d032a39ba3394988b4fce96 ]
    
    The cleanup tasks of kdamond threads including reset of corresponding
    DAMON context's ->kdamond field and decrease of global nr_running_ctxs
    counter is supposed to be executed by kdamond_fn().  However, commit
    0f91d13366a4 ("mm/damon: simplify stop mechanism") made neither
    damon_start() nor damon_stop() ensure the corresponding kdamond has
    started the execution of kdamond_fn().
    
    As a result, the cleanup can be skipped if damon_stop() is called fast
    enough after the previous damon_start().  Especially the skipped reset
    of ->kdamond could cause a use-after-free.
    
    Fix it by waiting for start of kdamond_fn() execution from
    damon_start().
    
    Link: https://lkml.kernel.org/r/20231208175018.63880-1-sj@kernel.org
    Fixes: 0f91d13366a4 ("mm/damon: simplify stop mechanism")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Reported-by: Jakub Acs <acsjakub@amazon.de>
    Cc: Changbin Du <changbin.du@intel.com>
    Cc: Jakub Acs <acsjakub@amazon.de>
    Cc: <stable@vger.kernel.org> # 5.15.x
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mm/damon/core: use number of passed access sampling as a timer [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Thu Sep 14 02:15:23 2023 +0000

    mm/damon/core: use number of passed access sampling as a timer
    
    [ Upstream commit 4472edf63d6630e6cf65e205b4fc8c3c94d0afe5 ]
    
    DAMON sleeps for sampling interval after each sampling, and check if the
    aggregation interval and the ops update interval have passed using
    ktime_get_coarse_ts64() and baseline timestamps for the intervals.  That
    design is for making the operations occur at deterministic timing
    regardless of the time that spend for each work.  However, it turned out
    it is not that useful, and incur not-that-intuitive results.
    
    After all, timer functions, and especially sleep functions that DAMON uses
    to wait for specific timing, are not necessarily strictly accurate.  It is
    legal design, so no problem.  However, depending on such inaccuracies, the
    nr_accesses can be larger than aggregation interval divided by sampling
    interval.  For example, with the default setting (5 ms sampling interval
    and 100 ms aggregation interval) we frequently show regions having
    nr_accesses larger than 20.  Also, if the execution of a DAMOS scheme
    takes a long time, next aggregation could happen before enough number of
    samples are collected.  This is not what usual users would intuitively
    expect.
    
    Since access check sampling is the smallest unit work of DAMON, using the
    number of passed sampling intervals as the DAMON-internal timer can easily
    avoid these problems.  That is, convert aggregation and ops update
    intervals to numbers of sampling intervals that need to be passed before
    those operations be executed, count the number of passed sampling
    intervals, and invoke the operations as soon as the specific amount of
    sampling intervals passed.  Make the change.
    
    Note that this could make a behavioral change to settings that using
    intervals that not aligned by the sampling interval.  For example, if the
    sampling interval is 5 ms and the aggregation interval is 12 ms, DAMON
    effectively uses 15 ms as its aggregation interval, because it checks
    whether the aggregation interval after sleeping the sampling interval.
    This change will make DAMON to effectively use 10 ms as aggregation
    interval, since it uses 'aggregation interval / sampling interval *
    sampling interval' as the effective aggregation interval, and we don't use
    floating point types.  Usual users would have used aligned intervals, so
    this behavioral change is not expected to make any meaningful impact, so
    just make this change.
    
    Link: https://lkml.kernel.org/r/20230914021523.60649-1-sj@kernel.org
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 6376a8245956 ("mm/damon/core: make damon_start() waits until kdamond_fn() starts")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/ipv6: Revert remove expired routes with a separated list of routes [+ + +]
Author: David Ahern <dsahern@kernel.org>
Date:   Mon Dec 18 20:02:43 2023 -0700

    net/ipv6: Revert remove expired routes with a separated list of routes
    
    [ Upstream commit dade3f6a1e4e35a5ae916d5e78b3229ec34c78ec ]
    
    This reverts commit 3dec89b14d37ee635e772636dad3f09f78f1ab87.
    
    The commit has some race conditions given how expires is managed on a
    fib6_info in relation to gc start, adding the entry to the gc list and
    setting the timer value leading to UAF. Revert the commit and try again
    in a later release.
    
    Fixes: 3dec89b14d37 ("net/ipv6: Remove expired routes with a separated list of routes")
    Cc: Kui-Feng Lee <thinker.li@gmail.com>
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20231219030243.25687-1-dsahern@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: Fix fw tracer first block check [+ + +]
Author: Moshe Shemesh <moshe@nvidia.com>
Date:   Thu Nov 30 11:30:34 2023 +0200

    net/mlx5: Fix fw tracer first block check
    
    [ Upstream commit 4261edf11cb7c9224af713a102e5616329306932 ]
    
    While handling new traces, to verify it is not the first block being
    written, last_timestamp is checked. But instead of checking it is non
    zero it is verified to be zero. Fix to verify last_timestamp is not
    zero.
    
    Fixes: c71ad41ccb0c ("net/mlx5: FW tracer, events handling")
    Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
    Reviewed-by: Feras Daoud <ferasda@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Refactor mlx5_flow_destination->rep pointer to vport num [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Fri Oct 6 15:22:22 2023 +0200

    net/mlx5: Refactor mlx5_flow_destination->rep pointer to vport num
    
    [ Upstream commit 04ad04e4fdd10f92ef4f2b3f6227ec9824682197 ]
    
    Currently the destination rep pointer is only used for comparisons or to
    obtain vport number from it. Since it is used both during flow creation and
    deletion it may point to representor of another eswitch instance which can
    be deallocated during driver unload even when there are rules pointing to
    it[0]. Refactor the code to store vport number and 'valid' flag instead of
    the representor pointer.
    
    [0]:
    [176805.886303] ==================================================================
    [176805.889433] BUG: KASAN: slab-use-after-free in esw_cleanup_dests+0x390/0x440 [mlx5_core]
    [176805.892981] Read of size 2 at addr ffff888155090aa0 by task modprobe/27280
    
    [176805.895462] CPU: 3 PID: 27280 Comm: modprobe Tainted: G    B              6.6.0-rc3+ #1
    [176805.896771] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    [176805.898514] Call Trace:
    [176805.899026]  <TASK>
    [176805.899519]  dump_stack_lvl+0x33/0x50
    [176805.900221]  print_report+0xc2/0x610
    [176805.900893]  ? mlx5_chains_put_table+0x33d/0x8d0 [mlx5_core]
    [176805.901897]  ? esw_cleanup_dests+0x390/0x440 [mlx5_core]
    [176805.902852]  kasan_report+0xac/0xe0
    [176805.903509]  ? esw_cleanup_dests+0x390/0x440 [mlx5_core]
    [176805.904461]  esw_cleanup_dests+0x390/0x440 [mlx5_core]
    [176805.905223]  __mlx5_eswitch_del_rule+0x1ae/0x460 [mlx5_core]
    [176805.906044]  ? esw_cleanup_dests+0x440/0x440 [mlx5_core]
    [176805.906822]  ? xas_find_conflict+0x420/0x420
    [176805.907496]  ? down_read+0x11e/0x200
    [176805.908046]  mlx5e_tc_rule_unoffload+0xc4/0x2a0 [mlx5_core]
    [176805.908844]  mlx5e_tc_del_fdb_flow+0x7da/0xb10 [mlx5_core]
    [176805.909597]  mlx5e_flow_put+0x4b/0x80 [mlx5_core]
    [176805.910275]  mlx5e_delete_flower+0x5b4/0xb70 [mlx5_core]
    [176805.911010]  tc_setup_cb_reoffload+0x27/0xb0
    [176805.911648]  fl_reoffload+0x62d/0x900 [cls_flower]
    [176805.912313]  ? mlx5e_rep_indr_block_unbind+0xd0/0xd0 [mlx5_core]
    [176805.913151]  ? __fl_put+0x230/0x230 [cls_flower]
    [176805.913768]  ? filter_irq_stacks+0x90/0x90
    [176805.914335]  ? kasan_save_stack+0x1e/0x40
    [176805.914893]  ? kasan_set_track+0x21/0x30
    [176805.915484]  ? kasan_save_free_info+0x27/0x40
    [176805.916105]  tcf_block_playback_offloads+0x79/0x1f0
    [176805.916773]  ? mlx5e_rep_indr_block_unbind+0xd0/0xd0 [mlx5_core]
    [176805.917647]  tcf_block_unbind+0x12d/0x330
    [176805.918239]  tcf_block_offload_cmd.isra.0+0x24e/0x320
    [176805.918953]  ? tcf_block_bind+0x770/0x770
    [176805.919551]  ? _raw_read_unlock_irqrestore+0x30/0x30
    [176805.920236]  ? mutex_lock+0x7d/0xd0
    [176805.920735]  ? mutex_unlock+0x80/0xd0
    [176805.921255]  tcf_block_offload_unbind+0xa5/0x120
    [176805.921909]  __tcf_block_put+0xc2/0x2d0
    [176805.922467]  ingress_destroy+0xf4/0x3d0 [sch_ingress]
    [176805.923178]  __qdisc_destroy+0x9d/0x280
    [176805.923741]  dev_shutdown+0x1c6/0x330
    [176805.924295]  unregister_netdevice_many_notify+0x6ef/0x1500
    [176805.925034]  ? netdev_freemem+0x50/0x50
    [176805.925610]  ? _raw_spin_lock_irq+0x7b/0xd0
    [176805.926235]  ? _raw_spin_lock_bh+0xe0/0xe0
    [176805.926849]  unregister_netdevice_queue+0x1e0/0x280
    [176805.927592]  ? unregister_netdevice_many+0x10/0x10
    [176805.928275]  unregister_netdev+0x18/0x20
    [176805.928835]  mlx5e_vport_rep_unload+0xc0/0x200 [mlx5_core]
    [176805.929608]  mlx5_esw_offloads_unload_rep+0x9d/0xc0 [mlx5_core]
    [176805.930492]  mlx5_eswitch_unload_vf_vports+0x108/0x1a0 [mlx5_core]
    [176805.931422]  ? mlx5_eswitch_unload_sf_vport+0x50/0x50 [mlx5_core]
    [176805.932304]  ? rwsem_down_write_slowpath+0x11f0/0x11f0
    [176805.932987]  mlx5_eswitch_disable_sriov+0x6f9/0xa60 [mlx5_core]
    [176805.933807]  ? mlx5_core_disable_hca+0xe1/0x130 [mlx5_core]
    [176805.934576]  ? mlx5_eswitch_disable_locked+0x580/0x580 [mlx5_core]
    [176805.935463]  mlx5_device_disable_sriov+0x138/0x490 [mlx5_core]
    [176805.936308]  mlx5_sriov_disable+0x8c/0xb0 [mlx5_core]
    [176805.937063]  remove_one+0x7f/0x210 [mlx5_core]
    [176805.937711]  pci_device_remove+0x96/0x1c0
    [176805.938289]  device_release_driver_internal+0x361/0x520
    [176805.938981]  ? kobject_put+0x5c/0x330
    [176805.939553]  driver_detach+0xd7/0x1d0
    [176805.940101]  bus_remove_driver+0x11f/0x290
    [176805.943847]  pci_unregister_driver+0x23/0x1f0
    [176805.944505]  mlx5_cleanup+0xc/0x20 [mlx5_core]
    [176805.945189]  __x64_sys_delete_module+0x2b3/0x450
    [176805.945837]  ? module_flags+0x300/0x300
    [176805.946377]  ? dput+0xc2/0x830
    [176805.946848]  ? __kasan_record_aux_stack+0x9c/0xb0
    [176805.947555]  ? __call_rcu_common.constprop.0+0x46c/0xb50
    [176805.948338]  ? fpregs_assert_state_consistent+0x1d/0xa0
    [176805.949055]  ? exit_to_user_mode_prepare+0x30/0x120
    [176805.949713]  do_syscall_64+0x3d/0x90
    [176805.950226]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [176805.950904] RIP: 0033:0x7f7f42c3f5ab
    [176805.951462] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48
    [176805.953710] RSP: 002b:00007fff07dc9d08 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
    [176805.954691] RAX: ffffffffffffffda RBX: 000055b6e91c01e0 RCX: 00007f7f42c3f5ab
    [176805.955691] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6e91c0248
    [176805.956662] RBP: 000055b6e91c01e0 R08: 0000000000000000 R09: 0000000000000000
    [176805.957601] R10: 00007f7f42d9eac0 R11: 0000000000000206 R12: 000055b6e91c0248
    [176805.958593] R13: 0000000000000000 R14: 000055b6e91bfb38 R15: 0000000000000000
    [176805.959599]  </TASK>
    
    [176805.960324] Allocated by task 20490:
    [176805.960893]  kasan_save_stack+0x1e/0x40
    [176805.961463]  kasan_set_track+0x21/0x30
    [176805.962019]  __kasan_kmalloc+0x77/0x90
    [176805.962554]  esw_offloads_init+0x1bb/0x480 [mlx5_core]
    [176805.963318]  mlx5_eswitch_init+0xc70/0x15c0 [mlx5_core]
    [176805.964092]  mlx5_init_one_devl_locked+0x366/0x1230 [mlx5_core]
    [176805.964902]  probe_one+0x6f7/0xc90 [mlx5_core]
    [176805.965541]  local_pci_probe+0xd7/0x180
    [176805.966075]  pci_device_probe+0x231/0x6f0
    [176805.966631]  really_probe+0x1d4/0xb50
    [176805.967179]  __driver_probe_device+0x18d/0x450
    [176805.967810]  driver_probe_device+0x49/0x120
    [176805.968431]  __driver_attach+0x1fb/0x490
    [176805.968976]  bus_for_each_dev+0xed/0x170
    [176805.969560]  bus_add_driver+0x21a/0x570
    [176805.970124]  driver_register+0x133/0x460
    [176805.970684]  0xffffffffa0678065
    [176805.971180]  do_one_initcall+0x92/0x2b0
    [176805.971744]  do_init_module+0x22d/0x720
    [176805.972318]  load_module+0x58c3/0x63b0
    [176805.972847]  init_module_from_file+0xd2/0x130
    [176805.973441]  __x64_sys_finit_module+0x389/0x7c0
    [176805.974045]  do_syscall_64+0x3d/0x90
    [176805.974556]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    [176805.975566] Freed by task 27280:
    [176805.976077]  kasan_save_stack+0x1e/0x40
    [176805.976655]  kasan_set_track+0x21/0x30
    [176805.977221]  kasan_save_free_info+0x27/0x40
    [176805.977834]  ____kasan_slab_free+0x11a/0x1b0
    [176805.978505]  __kmem_cache_free+0x163/0x2d0
    [176805.979113]  esw_offloads_cleanup_reps+0xb8/0x120 [mlx5_core]
    [176805.979963]  mlx5_eswitch_cleanup+0x182/0x270 [mlx5_core]
    [176805.980763]  mlx5_cleanup_once+0x9a/0x1e0 [mlx5_core]
    [176805.981477]  mlx5_uninit_one+0xa9/0x180 [mlx5_core]
    [176805.982196]  remove_one+0x8f/0x210 [mlx5_core]
    [176805.982868]  pci_device_remove+0x96/0x1c0
    [176805.983461]  device_release_driver_internal+0x361/0x520
    [176805.984169]  driver_detach+0xd7/0x1d0
    [176805.984702]  bus_remove_driver+0x11f/0x290
    [176805.985261]  pci_unregister_driver+0x23/0x1f0
    [176805.985847]  mlx5_cleanup+0xc/0x20 [mlx5_core]
    [176805.986483]  __x64_sys_delete_module+0x2b3/0x450
    [176805.987126]  do_syscall_64+0x3d/0x90
    [176805.987665]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    [176805.988667] Last potentially related work creation:
    [176805.989305]  kasan_save_stack+0x1e/0x40
    [176805.989839]  __kasan_record_aux_stack+0x9c/0xb0
    [176805.990443]  kvfree_call_rcu+0x84/0xa30
    [176805.990973]  clean_xps_maps+0x265/0x6e0
    [176805.991547]  netif_reset_xps_queues.part.0+0x3f/0x80
    [176805.992226]  unregister_netdevice_many_notify+0xfcf/0x1500
    [176805.992966]  unregister_netdevice_queue+0x1e0/0x280
    [176805.993638]  unregister_netdev+0x18/0x20
    [176805.994205]  mlx5e_remove+0xba/0x1e0 [mlx5_core]
    [176805.994872]  auxiliary_bus_remove+0x52/0x70
    [176805.995490]  device_release_driver_internal+0x361/0x520
    [176805.996196]  bus_remove_device+0x1e1/0x3d0
    [176805.996767]  device_del+0x390/0x980
    [176805.997270]  mlx5_rescan_drivers_locked.part.0+0x130/0x540 [mlx5_core]
    [176805.998195]  mlx5_unregister_device+0x77/0xc0 [mlx5_core]
    [176805.998989]  mlx5_uninit_one+0x41/0x180 [mlx5_core]
    [176805.999719]  remove_one+0x8f/0x210 [mlx5_core]
    [176806.000387]  pci_device_remove+0x96/0x1c0
    [176806.000938]  device_release_driver_internal+0x361/0x520
    [176806.001612]  unbind_store+0xd8/0xf0
    [176806.002108]  kernfs_fop_write_iter+0x2c0/0x440
    [176806.002748]  vfs_write+0x725/0xba0
    [176806.003294]  ksys_write+0xed/0x1c0
    [176806.003823]  do_syscall_64+0x3d/0x90
    [176806.004357]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    [176806.005317] The buggy address belongs to the object at ffff888155090a80
                     which belongs to the cache kmalloc-64 of size 64
    [176806.006774] The buggy address is located 32 bytes inside of
                     freed 64-byte region [ffff888155090a80, ffff888155090ac0)
    
    [176806.008773] The buggy address belongs to the physical page:
    [176806.009480] page:00000000a407e0e6 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155090
    [176806.010633] flags: 0x200000000000800(slab|node=0|zone=2)
    [176806.011352] page_type: 0xffffffff()
    [176806.011905] raw: 0200000000000800 ffff888100042640 ffffea000422b1c0 dead000000000004
    [176806.012949] raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
    [176806.013933] page dumped because: kasan: bad access detected
    
    [176806.014935] Memory state around the buggy address:
    [176806.015601]  ffff888155090980: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [176806.016568]  ffff888155090a00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [176806.017497] >ffff888155090a80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [176806.018438]                                ^
    [176806.019007]  ffff888155090b00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [176806.020001]  ffff888155090b80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [176806.020996] ==================================================================
    
    Fixes: a508728a4c8b ("net/mlx5e: VF tunnel RX traffic offloading")
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Correct snprintf truncation handling for fw_version buffer [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Tue Nov 21 15:00:21 2023 -0800

    net/mlx5e: Correct snprintf truncation handling for fw_version buffer
    
    [ Upstream commit ad436b9c1270c40554e274f067f1b78fcc06a004 ]
    
    snprintf returns the length of the formatted string, excluding the trailing
    null, without accounting for truncation. This means that is the return
    value is greater than or equal to the size parameter, the fw_version string
    was truncated.
    
    Reported-by: David Laight <David.Laight@ACULAB.COM>
    Closes: https://lore.kernel.org/netdev/81cae734ee1b4cde9b380a9a31006c1a@AcuMS.aculab.com/
    Link: https://docs.kernel.org/core-api/kernel-api.html#c.snprintf
    Fixes: 41e63c2baa11 ("net/mlx5e: Check return value of snprintf writing to fw_version buffer")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Correct snprintf truncation handling for fw_version buffer used by representors [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Tue Nov 21 15:00:22 2023 -0800

    net/mlx5e: Correct snprintf truncation handling for fw_version buffer used by representors
    
    [ Upstream commit b13559b76157de9d74f04d3ca0e49d69de3b5675 ]
    
    snprintf returns the length of the formatted string, excluding the trailing
    null, without accounting for truncation. This means that is the return
    value is greater than or equal to the size parameter, the fw_version string
    was truncated.
    
    Link: https://docs.kernel.org/core-api/kernel-api.html#c.snprintf
    Fixes: 1b2bd0c0264f ("net/mlx5e: Check return value of snprintf writing to fw_version buffer for representors")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Decrease num_block_tc when unblock tc offload [+ + +]
Author: Chris Mi <cmi@nvidia.com>
Date:   Wed Nov 29 04:53:32 2023 +0200

    net/mlx5e: Decrease num_block_tc when unblock tc offload
    
    [ Upstream commit be86106fd74a145f24c56c9bc18d658e8fe6d4f4 ]
    
    The cited commit increases num_block_tc when unblock tc offload.
    Actually should decrease it.
    
    Fixes: c8e350e62fc5 ("net/mlx5e: Make TC and IPsec offloads mutually exclusive on a netdev")
    Signed-off-by: Chris Mi <cmi@nvidia.com>
    Reviewed-by: Jianbo Liu <jianbol@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: fix a potential double-free in fs_udp_create_groups [+ + +]
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Tue Nov 28 17:40:53 2023 +0800

    net/mlx5e: fix a potential double-free in fs_udp_create_groups
    
    [ Upstream commit e75efc6466ae289e599fb12a5a86545dff245c65 ]
    
    When kcalloc() for ft->g succeeds but kvzalloc() for in fails,
    fs_udp_create_groups() will free ft->g. However, its caller
    fs_udp_create_table() will free ft->g again through calling
    mlx5e_destroy_flow_table(), which will lead to a double-free.
    Fix this by setting ft->g to NULL in fs_udp_create_groups().
    
    Fixes: 1c80bd684388 ("net/mlx5e: Introduce Flow Steering UDP API")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Fix a race in command alloc flow [+ + +]
Author: Shifeng Li <lishifeng@sangfor.com.cn>
Date:   Sat Dec 2 00:01:26 2023 -0800

    net/mlx5e: Fix a race in command alloc flow
    
    [ Upstream commit 8f5100da56b3980276234e812ce98d8f075194cd ]
    
    Fix a cmd->ent use after free due to a race on command entry.
    Such race occurs when one of the commands releases its last refcount and
    frees its index and entry while another process running command flush
    flow takes refcount to this command entry. The process which handles
    commands flush may see this command as needed to be flushed if the other
    process allocated a ent->idx but didn't set ent to cmd->ent_arr in
    cmd_work_handler(). Fix it by moving the assignment of cmd->ent_arr into
    the spin lock.
    
    [70013.081955] BUG: KASAN: use-after-free in mlx5_cmd_trigger_completions+0x1e2/0x4c0 [mlx5_core]
    [70013.081967] Write of size 4 at addr ffff88880b1510b4 by task kworker/26:1/1433361
    [70013.081968]
    [70013.082028] Workqueue: events aer_isr
    [70013.082053] Call Trace:
    [70013.082067]  dump_stack+0x8b/0xbb
    [70013.082086]  print_address_description+0x6a/0x270
    [70013.082102]  kasan_report+0x179/0x2c0
    [70013.082173]  mlx5_cmd_trigger_completions+0x1e2/0x4c0 [mlx5_core]
    [70013.082267]  mlx5_cmd_flush+0x80/0x180 [mlx5_core]
    [70013.082304]  mlx5_enter_error_state+0x106/0x1d0 [mlx5_core]
    [70013.082338]  mlx5_try_fast_unload+0x2ea/0x4d0 [mlx5_core]
    [70013.082377]  remove_one+0x200/0x2b0 [mlx5_core]
    [70013.082409]  pci_device_remove+0xf3/0x280
    [70013.082439]  device_release_driver_internal+0x1c3/0x470
    [70013.082453]  pci_stop_bus_device+0x109/0x160
    [70013.082468]  pci_stop_and_remove_bus_device+0xe/0x20
    [70013.082485]  pcie_do_fatal_recovery+0x167/0x550
    [70013.082493]  aer_isr+0x7d2/0x960
    [70013.082543]  process_one_work+0x65f/0x12d0
    [70013.082556]  worker_thread+0x87/0xb50
    [70013.082571]  kthread+0x2e9/0x3a0
    [70013.082592]  ret_from_fork+0x1f/0x40
    
    The logical relationship of this error is as follows:
    
                 aer_recover_work              |          ent->work
    -------------------------------------------+------------------------------
    aer_recover_work_func                      |
    |- pcie_do_recovery                        |
      |- report_error_detected                 |
        |- mlx5_pci_err_detected               |cmd_work_handler
          |- mlx5_enter_error_state            |  |- cmd_alloc_index
            |- enter_error_state               |    |- lock cmd->alloc_lock
              |- mlx5_cmd_flush                |    |- clear_bit
                |- mlx5_cmd_trigger_completions|    |- unlock cmd->alloc_lock
                  |- lock cmd->alloc_lock      |
                  |- vector = ~dev->cmd.vars.bitmask
                  |- for_each_set_bit          |
                    |- cmd_ent_get(cmd->ent_arr[i]) (UAF)
                  |- unlock cmd->alloc_lock    |  |- cmd->ent_arr[ent->idx]=ent
    
    The cmd->ent_arr[ent->idx] assignment and the bit clearing are not
    protected by the cmd->alloc_lock in cmd_work_handler().
    
    Fixes: 50b2412b7e78 ("net/mlx5: Avoid possible free of command entry while timeout comp handler")
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Shifeng Li <lishifeng@sangfor.com.cn>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Fix error code in mlx5e_tc_action_miss_mapping_get() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Dec 13 17:08:17 2023 +0300

    net/mlx5e: Fix error code in mlx5e_tc_action_miss_mapping_get()
    
    [ Upstream commit 86d5922679f3b6d02a64df66cdd777fdd4ea5c0d ]
    
    Preserve the error code if esw_add_restore_rule() fails.  Don't return
    success.
    
    Fixes: 6702782845a5 ("net/mlx5e: TC, Set CT miss to the specific ct action instance")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Fix error codes in alloc_branch_attr() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Dec 13 17:08:57 2023 +0300

    net/mlx5e: Fix error codes in alloc_branch_attr()
    
    [ Upstream commit d792e5f7f19b95f5ce41ac49df5ead4d280238f4 ]
    
    Set the error code if set_branch_dest_ft() fails.
    
    Fixes: ccbe33003b10 ("net/mlx5e: TC, Don't offload post action rule if not supported")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Fix overrun reported by coverity [+ + +]
Author: Jianbo Liu <jianbol@nvidia.com>
Date:   Tue Nov 14 01:25:21 2023 +0000

    net/mlx5e: Fix overrun reported by coverity
    
    [ Upstream commit da75fa542873e5f7d7f615566c0b00042d8a0437 ]
    
    Coverity Scan reports the following issue. But it's impossible that
    mlx5_get_dev_index returns 7 for PF, even if the index is calculated
    from PCI FUNC ID. So add the checking to make coverity slience.
    
    CID 610894 (#2 of 2): Out-of-bounds write (OVERRUN)
    Overrunning array esw->fdb_table.offloads.peer_miss_rules of 4 8-byte
    elements at element index 7 (byte offset 63) using index
    mlx5_get_dev_index(peer_dev) (which evaluates to 7).
    
    Fixes: 9bee385a6e39 ("net/mlx5: E-switch, refactor FDB miss rule add/remove")
    Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list() [+ + +]
Author: Shifeng Li <lishifeng@sangfor.com.cn>
Date:   Thu Nov 30 01:46:56 2023 -0800

    net/mlx5e: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list()
    
    [ Upstream commit ddb38ddff9c71026bad481b791a94d446ee37603 ]
    
    Out_sz that the size of out buffer is calculated using query_nic_vport
    _context_in structure when driver query the MAC list. However query_nic
    _vport_context_in structure is smaller than query_nic_vport_context_out.
    When allowed_list_size is greater than 96, calling ether_addr_copy() will
    trigger an slab-out-of-bounds.
    
    [ 1170.055866] BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core]
    [ 1170.055869] Read of size 4 at addr ffff88bdbc57d912 by task kworker/u128:1/461
    [ 1170.055870]
    [ 1170.055932] Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core]
    [ 1170.055936] Call Trace:
    [ 1170.055949]  dump_stack+0x8b/0xbb
    [ 1170.055958]  print_address_description+0x6a/0x270
    [ 1170.055961]  kasan_report+0x179/0x2c0
    [ 1170.056061]  mlx5_query_nic_vport_mac_list+0x481/0x4d0 [mlx5_core]
    [ 1170.056162]  esw_update_vport_addr_list+0x2c5/0xcd0 [mlx5_core]
    [ 1170.056257]  esw_vport_change_handle_locked+0xd08/0x1a20 [mlx5_core]
    [ 1170.056377]  esw_vport_change_handler+0x6b/0x90 [mlx5_core]
    [ 1170.056381]  process_one_work+0x65f/0x12d0
    [ 1170.056383]  worker_thread+0x87/0xb50
    [ 1170.056390]  kthread+0x2e9/0x3a0
    [ 1170.056394]  ret_from_fork+0x1f/0x40
    
    Fixes: e16aea2744ab ("net/mlx5: Introduce access functions to modify/query vport mac lists")
    Cc: Ding Hui <dinghui@sangfor.com.cn>
    Signed-off-by: Shifeng Li <lishifeng@sangfor.com.cn>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: XDP, Drop fragmented packets larger than MTU size [+ + +]
Author: Carolina Jubran <cjubran@nvidia.com>
Date:   Thu Nov 23 16:11:20 2023 +0200

    net/mlx5e: XDP, Drop fragmented packets larger than MTU size
    
    [ Upstream commit bcaf109f794744c14da0e9123b31d1f4571b0a35 ]
    
    XDP transmits fragmented packets that are larger than MTU size instead of
    dropping those packets. The drop check that checks whether a packet is larger
    than MTU is comparing MTU size against the linear part length only.
    
    Adjust the drop check to compare MTU size against both linear and non-linear
    part lengths to avoid transmitting fragmented packets larger than MTU size.
    
    Fixes: 39a1665d16a2 ("net/mlx5e: Implement sending multi buffer XDP frames")
    Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/rose: fix races in rose_kill_by_device() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Dec 14 15:27:47 2023 +0000

    net/rose: fix races in rose_kill_by_device()
    
    [ Upstream commit 64b8bc7d5f1434c636a40bdcfcd42b278d1714be ]
    
    syzbot found an interesting netdev refcounting issue in
    net/rose/af_rose.c, thanks to CONFIG_NET_DEV_REFCNT_TRACKER=y [1]
    
    Problem is that rose_kill_by_device() can change rose->device
    while other threads do not expect the pointer to be changed.
    
    We have to first collect sockets in a temporary array,
    then perform the changes while holding the socket
    lock and rose_list_lock spinlock (in this order)
    
    Change rose_release() to also acquire rose_list_lock
    before releasing the netdev refcount.
    
    [1]
    
    [ 1185.055088][ T7889] ref_tracker: reference already released.
    [ 1185.061476][ T7889] ref_tracker: allocated in:
    [ 1185.066081][ T7889]  rose_bind+0x4ab/0xd10
    [ 1185.070446][ T7889]  __sys_bind+0x1ec/0x220
    [ 1185.074818][ T7889]  __x64_sys_bind+0x72/0xb0
    [ 1185.079356][ T7889]  do_syscall_64+0x40/0x110
    [ 1185.083897][ T7889]  entry_SYSCALL_64_after_hwframe+0x63/0x6b
    [ 1185.089835][ T7889] ref_tracker: freed in:
    [ 1185.094088][ T7889]  rose_release+0x2f5/0x570
    [ 1185.098629][ T7889]  __sock_release+0xae/0x260
    [ 1185.103262][ T7889]  sock_close+0x1c/0x20
    [ 1185.107453][ T7889]  __fput+0x270/0xbb0
    [ 1185.111467][ T7889]  task_work_run+0x14d/0x240
    [ 1185.116085][ T7889]  get_signal+0x106f/0x2790
    [ 1185.120622][ T7889]  arch_do_signal_or_restart+0x90/0x7f0
    [ 1185.126205][ T7889]  exit_to_user_mode_prepare+0x121/0x240
    [ 1185.131846][ T7889]  syscall_exit_to_user_mode+0x1e/0x60
    [ 1185.137293][ T7889]  do_syscall_64+0x4d/0x110
    [ 1185.141783][ T7889]  entry_SYSCALL_64_after_hwframe+0x63/0x6b
    [ 1185.148085][ T7889] ------------[ cut here ]------------
    
    WARNING: CPU: 1 PID: 7889 at lib/ref_tracker.c:255 ref_tracker_free+0x61a/0x810 lib/ref_tracker.c:255
    Modules linked in:
    CPU: 1 PID: 7889 Comm: syz-executor.2 Not tainted 6.7.0-rc4-syzkaller-00162-g65c95f78917e #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
    RIP: 0010:ref_tracker_free+0x61a/0x810 lib/ref_tracker.c:255
    Code: 00 44 8b 6b 18 31 ff 44 89 ee e8 21 62 f5 fc 45 85 ed 0f 85 a6 00 00 00 e8 a3 66 f5 fc 48 8b 34 24 48 89 ef e8 27 5f f1 05 90 <0f> 0b 90 bb ea ff ff ff e9 52 fd ff ff e8 84 66 f5 fc 4c 8d 6d 44
    RSP: 0018:ffffc90004917850 EFLAGS: 00010202
    RAX: 0000000000000201 RBX: ffff88802618f4c0 RCX: 0000000000000000
    RDX: 0000000000000202 RSI: ffffffff8accb920 RDI: 0000000000000001
    RBP: ffff8880269ea5b8 R08: 0000000000000001 R09: fffffbfff23e35f6
    R10: ffffffff91f1afb7 R11: 0000000000000001 R12: 1ffff92000922f0c
    R13: 0000000005a2039b R14: ffff88802618f4d8 R15: 00000000ffffffff
    FS: 00007f0a720ef6c0(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f43a819d988 CR3: 0000000076c64000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    netdev_tracker_free include/linux/netdevice.h:4127 [inline]
    netdev_put include/linux/netdevice.h:4144 [inline]
    netdev_put include/linux/netdevice.h:4140 [inline]
    rose_kill_by_device net/rose/af_rose.c:195 [inline]
    rose_device_event+0x25d/0x330 net/rose/af_rose.c:218
    notifier_call_chain+0xb6/0x3b0 kernel/notifier.c:93
    call_netdevice_notifiers_info+0xbe/0x130 net/core/dev.c:1967
    call_netdevice_notifiers_extack net/core/dev.c:2005 [inline]
    call_netdevice_notifiers net/core/dev.c:2019 [inline]
    __dev_notify_flags+0x1f5/0x2e0 net/core/dev.c:8646
    dev_change_flags+0x122/0x170 net/core/dev.c:8682
    dev_ifsioc+0x9ad/0x1090 net/core/dev_ioctl.c:529
    dev_ioctl+0x224/0x1090 net/core/dev_ioctl.c:786
    sock_do_ioctl+0x198/0x270 net/socket.c:1234
    sock_ioctl+0x22e/0x6b0 net/socket.c:1339
    vfs_ioctl fs/ioctl.c:51 [inline]
    __do_sys_ioctl fs/ioctl.c:871 [inline]
    __se_sys_ioctl fs/ioctl.c:857 [inline]
    __x64_sys_ioctl+0x18f/0x210 fs/ioctl.c:857
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    RIP: 0033:0x7f0a7147cba9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f0a720ef0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007f0a7159bf80 RCX: 00007f0a7147cba9
    RDX: 0000000020000040 RSI: 0000000000008914 RDI: 0000000000000004
    RBP: 00007f0a714c847a R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007f0a7159bf80 R15: 00007ffc8bb3a5f8
    </TASK>
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Bernard Pidoux <f6bvp@free.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: 9p: avoid freeing uninit memory in p9pdu_vreadf [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Wed Dec 6 23:09:13 2023 +0300

    net: 9p: avoid freeing uninit memory in p9pdu_vreadf
    
    commit ff49bf1867578f23a5ffdd38f927f6e1e16796c4 upstream.
    
    If some of p9pdu_readf() calls inside case 'T' in p9pdu_vreadf() fails,
    the error path is not handled properly. *wnames or members of *wnames
    array may be left uninitialized and invalidly freed.
    
    Initialize *wnames to NULL in beginning of case 'T'. Initialize the first
    *wnames array element to NULL and nullify the failing *wnames element so
    that the error path freeing loop stops on the first NULL element and
    doesn't proceed further.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: ace51c4dd2f9 ("9p: add new protocol support code")
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Message-ID: <20231206200913.16135-1-pchelkin@ispras.ru>
    Cc: stable@vger.kernel.org
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: avoid build bug in skb extension length calculation [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Mon Dec 18 18:06:54 2023 +0100

    net: avoid build bug in skb extension length calculation
    
    commit d6e5794b06c0fab74fe6e4fa55d508a5ceb14735 upstream.
    
    GCC seems to incorrectly fail to evaluate skb_ext_total_length() at
    compile time under certain conditions.
    
    The issue even occurs if all values in skb_ext_type_len[] are "0",
    ruling out the possibility of an actual overflow.
    
    As the patch has been in mainline since v6.6 without triggering the
    problem it seems to be a very uncommon occurrence.
    
    As the issue only occurs when -fno-tree-loop-im is specified as part of
    CFLAGS_GCOV, disable the BUILD_BUG_ON() only when building with coverage
    reporting enabled.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202312171924.4FozI5FG-lkp@intel.com/
    Suggested-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/lkml/487cfd35-fe68-416f-9bfd-6bb417f98304@app.fastmail.com/
    Fixes: 5d21d0a65b57 ("net: generalize calculation of skb extensions length")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20231218-net-skbuff-build-bug-v1-1-eefc2fb0a7d3@weissschuh.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: check dev->gso_max_size in gso_features_check() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Dec 19 12:53:31 2023 +0000

    net: check dev->gso_max_size in gso_features_check()
    
    [ Upstream commit 24ab059d2ebd62fdccc43794796f6ffbabe49ebc ]
    
    Some drivers might misbehave if TSO packets get too big.
    
    GVE for instance uses a 16bit field in its TX descriptor,
    and will do bad things if a packet is bigger than 2^16 bytes.
    
    Linux TCP stack honors dev->gso_max_size, but there are
    other ways for too big packets to reach an ndo_start_xmit()
    handler : virtio_net, af_packet, GRO...
    
    Add a generic check in gso_features_check() and fallback
    to GSO when needed.
    
    gso_max_size was added in the blamed commit.
    
    Fixes: 82cc1a7a5687 ("[NET]: Add per-connection option to set max TSO frame size")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20231219125331.4127498-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: check vlan filter feature in vlan_vids_add_by_dev() and vlan_vids_del_by_dev() [+ + +]
Author: Liu Jian <liujian56@huawei.com>
Date:   Sat Dec 16 15:52:18 2023 +0800

    net: check vlan filter feature in vlan_vids_add_by_dev() and vlan_vids_del_by_dev()
    
    [ Upstream commit 01a564bab4876007ce35f312e16797dfe40e4823 ]
    
    I got the below warning trace:
    
    WARNING: CPU: 4 PID: 4056 at net/core/dev.c:11066 unregister_netdevice_many_notify
    CPU: 4 PID: 4056 Comm: ip Not tainted 6.7.0-rc4+ #15
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
    RIP: 0010:unregister_netdevice_many_notify+0x9a4/0x9b0
    Call Trace:
     rtnl_dellink
     rtnetlink_rcv_msg
     netlink_rcv_skb
     netlink_unicast
     netlink_sendmsg
     __sock_sendmsg
     ____sys_sendmsg
     ___sys_sendmsg
     __sys_sendmsg
     do_syscall_64
     entry_SYSCALL_64_after_hwframe
    
    It can be repoduced via:
    
        ip netns add ns1
        ip netns exec ns1 ip link add bond0 type bond mode 0
        ip netns exec ns1 ip link add bond_slave_1 type veth peer veth2
        ip netns exec ns1 ip link set bond_slave_1 master bond0
    [1] ip netns exec ns1 ethtool -K bond0 rx-vlan-filter off
    [2] ip netns exec ns1 ip link add link bond_slave_1 name bond_slave_1.0 type vlan id 0
    [3] ip netns exec ns1 ip link add link bond0 name bond0.0 type vlan id 0
    [4] ip netns exec ns1 ip link set bond_slave_1 nomaster
    [5] ip netns exec ns1 ip link del veth2
        ip netns del ns1
    
    This is all caused by command [1] turning off the rx-vlan-filter function
    of bond0. The reason is the same as commit 01f4fd270870 ("bonding: Fix
    incorrect deletion of ETH_P_8021AD protocol vid from slaves"). Commands
    [2] [3] add the same vid to slave and master respectively, causing
    command [4] to empty slave->vlan_info. The following command [5] triggers
    this problem.
    
    To fix this problem, we should add VLAN_FILTER feature checks in
    vlan_vids_add_by_dev() and vlan_vids_del_by_dev() to prevent incorrect
    addition or deletion of vlan_vid information.
    
    Fixes: 348a1443cc43 ("vlan: introduce functions to do mass addition/deletion of vids by another device")
    Signed-off-by: Liu Jian <liujian56@huawei.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: mtk_wed: fix possible NULL pointer dereference in mtk_wed_wo_queue_tx_clean() [+ + +]
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date:   Sun Dec 17 16:37:40 2023 +0100

    net: ethernet: mtk_wed: fix possible NULL pointer dereference in mtk_wed_wo_queue_tx_clean()
    
    [ Upstream commit 7cb8cd4daacfea646cf8b5925ca2c66c98b18480 ]
    
    In order to avoid a NULL pointer dereference, check entry->buf pointer before running
    skb_free_frag in mtk_wed_wo_queue_tx_clean routine.
    
    Fixes: 799684448e3e ("net: ethernet: mtk_wed: introduce wed wo support")
    Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/3c1262464d215faa8acebfc08869798c81c96f4a.1702827359.git.lorenzo@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ks8851: Fix TX stall caused by TX buffer overrun [+ + +]
Author: Ronald Wahl <ronald.wahl@raritan.com>
Date:   Thu Dec 14 19:11:12 2023 +0100

    net: ks8851: Fix TX stall caused by TX buffer overrun
    
    commit 3dc5d44545453de1de9c53cc529cc960a85933da upstream.
    
    There is a bug in the ks8851 Ethernet driver that more data is written
    to the hardware TX buffer than actually available. This is caused by
    wrong accounting of the free TX buffer space.
    
    The driver maintains a tx_space variable that represents the TX buffer
    space that is deemed to be free. The ks8851_start_xmit_spi() function
    adds an SKB to a queue if tx_space is large enough and reduces tx_space
    by the amount of buffer space it will later need in the TX buffer and
    then schedules a work item. If there is not enough space then the TX
    queue is stopped.
    
    The worker function ks8851_tx_work() dequeues all the SKBs and writes
    the data into the hardware TX buffer. The last packet will trigger an
    interrupt after it was send. Here it is assumed that all data fits into
    the TX buffer.
    
    In the interrupt routine (which runs asynchronously because it is a
    threaded interrupt) tx_space is updated with the current value from the
    hardware. Also the TX queue is woken up again.
    
    Now it could happen that after data was sent to the hardware and before
    handling the TX interrupt new data is queued in ks8851_start_xmit_spi()
    when the TX buffer space had still some space left. When the interrupt
    is actually handled tx_space is updated from the hardware but now we
    already have new SKBs queued that have not been written to the hardware
    TX buffer yet. Since tx_space has been overwritten by the value from the
    hardware the space is not accounted for.
    
    Now we have more data queued then buffer space available in the hardware
    and ks8851_tx_work() will potentially overrun the hardware TX buffer. In
    many cases it will still work because often the buffer is written out
    fast enough so that no overrun occurs but for example if the peer
    throttles us via flow control then an overrun may happen.
    
    This can be fixed in different ways. The most simple way would be to set
    tx_space to 0 before writing data to the hardware TX buffer preventing
    the queuing of more SKBs until the TX interrupt has been handled. I have
    chosen a slightly more efficient (and still rather simple) way and
    track the amount of data that is already queued and not yet written to
    the hardware. When new SKBs are to be queued the already queued amount
    of data is honoured when checking free TX buffer space.
    
    I tested this with a setup of two linked KS8851 running iperf3 between
    the two in bidirectional mode. Before the fix I got a stall after some
    minutes. With the fix I saw now issues anymore after hours.
    
    Fixes: 3ba81f3ece3c ("net: Micrel KS8851 SPI network driver")
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Ben Dooks <ben.dooks@codethink.co.uk>
    Cc: Tristram Ha <Tristram.Ha@microchip.com>
    Cc: netdev@vger.kernel.org
    Cc: stable@vger.kernel.org # 5.10+
    Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20231214181112.76052-1-rwahl@gmx.de
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: mana: select PAGE_POOL [+ + +]
Author: Yury Norov <yury.norov@gmail.com>
Date:   Fri Dec 15 12:33:53 2023 -0800

    net: mana: select PAGE_POOL
    
    [ Upstream commit 340943fbff3d8faa44d2223ca04917df28786a07 ]
    
    Mana uses PAGE_POOL API. x86_64 defconfig doesn't select it:
    
    ld: vmlinux.o: in function `mana_create_page_pool.isra.0':
    mana_en.c:(.text+0x9ae36f): undefined reference to `page_pool_create'
    ld: vmlinux.o: in function `mana_get_rxfrag':
    mana_en.c:(.text+0x9afed1): undefined reference to `page_pool_alloc_pages'
    make[3]: *** [/home/yury/work/linux/scripts/Makefile.vmlinux:37: vmlinux] Error 1
    make[2]: *** [/home/yury/work/linux/Makefile:1154: vmlinux] Error 2
    make[1]: *** [/home/yury/work/linux/Makefile:234: __sub-make] Error 2
    make[1]: Leaving directory '/home/yury/work/build-linux-x86_64'
    make: *** [Makefile:234: __sub-make] Error 2
    
    So we need to select it explicitly.
    
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Simon Horman <horms@kernel.org> # build-tested
    Fixes: ca9c54d2 ("net: mana: Add a driver for Microsoft Azure Network Adapter")
    Link: https://lore.kernel.org/r/20231215203353.635379-1-yury.norov@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mscc: ocelot: fix eMAC TX RMON stats for bucket 256-511 and above [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Thu Dec 14 02:09:01 2023 +0200

    net: mscc: ocelot: fix eMAC TX RMON stats for bucket 256-511 and above
    
    [ Upstream commit 52eda4641d041667fa059f4855c5f88dcebd8afe ]
    
    There is a typo in the driver due to which we report incorrect TX RMON
    counters for the 256-511 octet bucket and all the other buckets larger
    than that.
    
    Bug found with the selftest at
    https://patchwork.kernel.org/project/netdevbpf/patch/20231211223346.2497157-9-tobias@waldekranz.com/
    
    Fixes: e32036e1ae7b ("net: mscc: ocelot: add support for all sorts of standardized counters present in DSA")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://lore.kernel.org/r/20231214000902.545625-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mscc: ocelot: fix pMAC TX RMON stats for bucket 256-511 and above [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Thu Dec 14 02:09:02 2023 +0200

    net: mscc: ocelot: fix pMAC TX RMON stats for bucket 256-511 and above
    
    [ Upstream commit 70f010da00f90415296f93fb47a561977eae41cb ]
    
    The typo from ocelot_port_rmon_stats_cb() was also carried over to
    ocelot_port_pmac_rmon_stats_cb() as well, leading to incorrect TX RMON
    stats for the pMAC too.
    
    Fixes: ab3f97a9610a ("net: mscc: ocelot: export ethtool MAC Merge stats for Felix VSC9959")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://lore.kernel.org/r/20231214000902.545625-2-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: skip LED triggers on PHYs on SFP modules [+ + +]
Author: Daniel Golle <daniel@makrotopia.org>
Date:   Tue Dec 12 00:05:35 2023 +0000

    net: phy: skip LED triggers on PHYs on SFP modules
    
    [ Upstream commit b1dfc0f76231bbf395c59d20a2070684620d5d0f ]
    
    Calling led_trigger_register() when attaching a PHY located on an SFP
    module potentially (and practically) leads into a deadlock.
    Fix this by not calling led_trigger_register() for PHYs localted on SFP
    modules as such modules actually never got any LEDs.
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.7.0-rc4-next-20231208+ #0 Tainted: G           O
    ------------------------------------------------------
    kworker/u8:2/43 is trying to acquire lock:
    ffffffc08108c4e8 (triggers_list_lock){++++}-{3:3}, at: led_trigger_register+0x4c/0x1a8
    
    but task is already holding lock:
    ffffff80c5c6f318 (&sfp->sm_mutex){+.+.}-{3:3}, at: cleanup_module+0x2ba8/0x3120 [sfp]
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #3 (&sfp->sm_mutex){+.+.}-{3:3}:
           __mutex_lock+0x88/0x7a0
           mutex_lock_nested+0x20/0x28
           cleanup_module+0x2ae0/0x3120 [sfp]
           sfp_register_bus+0x5c/0x9c
           sfp_register_socket+0x48/0xd4
           cleanup_module+0x271c/0x3120 [sfp]
           platform_probe+0x64/0xb8
           really_probe+0x17c/0x3c0
           __driver_probe_device+0x78/0x164
           driver_probe_device+0x3c/0xd4
           __driver_attach+0xec/0x1f0
           bus_for_each_dev+0x60/0xa0
           driver_attach+0x20/0x28
           bus_add_driver+0x108/0x208
           driver_register+0x5c/0x118
           __platform_driver_register+0x24/0x2c
           init_module+0x28/0xa7c [sfp]
           do_one_initcall+0x70/0x2ec
           do_init_module+0x54/0x1e4
           load_module+0x1b78/0x1c8c
           __do_sys_init_module+0x1bc/0x2cc
           __arm64_sys_init_module+0x18/0x20
           invoke_syscall.constprop.0+0x4c/0xdc
           do_el0_svc+0x3c/0xbc
           el0_svc+0x34/0x80
           el0t_64_sync_handler+0xf8/0x124
           el0t_64_sync+0x150/0x154
    
    -> #2 (rtnl_mutex){+.+.}-{3:3}:
           __mutex_lock+0x88/0x7a0
           mutex_lock_nested+0x20/0x28
           rtnl_lock+0x18/0x20
           set_device_name+0x30/0x130
           netdev_trig_activate+0x13c/0x1ac
           led_trigger_set+0x118/0x234
           led_trigger_write+0x104/0x17c
           sysfs_kf_bin_write+0x64/0x80
           kernfs_fop_write_iter+0x128/0x1b4
           vfs_write+0x178/0x2a4
           ksys_write+0x58/0xd4
           __arm64_sys_write+0x18/0x20
           invoke_syscall.constprop.0+0x4c/0xdc
           do_el0_svc+0x3c/0xbc
           el0_svc+0x34/0x80
           el0t_64_sync_handler+0xf8/0x124
           el0t_64_sync+0x150/0x154
    
    -> #1 (&led_cdev->trigger_lock){++++}-{3:3}:
           down_write+0x4c/0x13c
           led_trigger_write+0xf8/0x17c
           sysfs_kf_bin_write+0x64/0x80
           kernfs_fop_write_iter+0x128/0x1b4
           vfs_write+0x178/0x2a4
           ksys_write+0x58/0xd4
           __arm64_sys_write+0x18/0x20
           invoke_syscall.constprop.0+0x4c/0xdc
           do_el0_svc+0x3c/0xbc
           el0_svc+0x34/0x80
           el0t_64_sync_handler+0xf8/0x124
           el0t_64_sync+0x150/0x154
    
    -> #0 (triggers_list_lock){++++}-{3:3}:
           __lock_acquire+0x12a0/0x2014
           lock_acquire+0x100/0x2ac
           down_write+0x4c/0x13c
           led_trigger_register+0x4c/0x1a8
           phy_led_triggers_register+0x9c/0x214
           phy_attach_direct+0x154/0x36c
           phylink_attach_phy+0x30/0x60
           phylink_sfp_connect_phy+0x140/0x510
           sfp_add_phy+0x34/0x50
           init_module+0x15c/0xa7c [sfp]
           cleanup_module+0x1d94/0x3120 [sfp]
           cleanup_module+0x2bb4/0x3120 [sfp]
           process_one_work+0x1f8/0x4ec
           worker_thread+0x1e8/0x3d8
           kthread+0x104/0x110
           ret_from_fork+0x10/0x20
    
    other info that might help us debug this:
    
    Chain exists of:
      triggers_list_lock --> rtnl_mutex --> &sfp->sm_mutex
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&sfp->sm_mutex);
                                   lock(rtnl_mutex);
                                   lock(&sfp->sm_mutex);
      lock(triggers_list_lock);
    
     *** DEADLOCK ***
    
    4 locks held by kworker/u8:2/43:
     #0: ffffff80c000f938 ((wq_completion)events_power_efficient){+.+.}-{0:0}, at: process_one_work+0x150/0x4ec
     #1: ffffffc08214bde8 ((work_completion)(&(&sfp->timeout)->work)){+.+.}-{0:0}, at: process_one_work+0x150/0x4ec
     #2: ffffffc0810902f8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x18/0x20
     #3: ffffff80c5c6f318 (&sfp->sm_mutex){+.+.}-{3:3}, at: cleanup_module+0x2ba8/0x3120 [sfp]
    
    stack backtrace:
    CPU: 0 PID: 43 Comm: kworker/u8:2 Tainted: G           O       6.7.0-rc4-next-20231208+ #0
    Hardware name: Bananapi BPI-R4 (DT)
    Workqueue: events_power_efficient cleanup_module [sfp]
    Call trace:
     dump_backtrace+0xa8/0x10c
     show_stack+0x14/0x1c
     dump_stack_lvl+0x5c/0xa0
     dump_stack+0x14/0x1c
     print_circular_bug+0x328/0x430
     check_noncircular+0x124/0x134
     __lock_acquire+0x12a0/0x2014
     lock_acquire+0x100/0x2ac
     down_write+0x4c/0x13c
     led_trigger_register+0x4c/0x1a8
     phy_led_triggers_register+0x9c/0x214
     phy_attach_direct+0x154/0x36c
     phylink_attach_phy+0x30/0x60
     phylink_sfp_connect_phy+0x140/0x510
     sfp_add_phy+0x34/0x50
     init_module+0x15c/0xa7c [sfp]
     cleanup_module+0x1d94/0x3120 [sfp]
     cleanup_module+0x2bb4/0x3120 [sfp]
     process_one_work+0x1f8/0x4ec
     worker_thread+0x1e8/0x3d8
     kthread+0x104/0x110
     ret_from_fork+0x10/0x20
    
    Signed-off-by: Daniel Golle <daniel@makrotopia.org>
    Fixes: 01e5b728e9e4 ("net: phy: Add a binding for PHY LEDs")
    Link: https://lore.kernel.org/r/102a9dce38bdf00215735d04cd4704458273ad9c.1702339354.git.daniel@makrotopia.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: Return error from sk_stream_wait_connect() if sk_wait_event() fails [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Thu Dec 14 14:09:22 2023 +0900

    net: Return error from sk_stream_wait_connect() if sk_wait_event() fails
    
    [ Upstream commit cac23b7d7627915d967ce25436d7aae26e88ed06 ]
    
    The following NULL pointer dereference issue occurred:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    <...>
    RIP: 0010:ccid_hc_tx_send_packet net/dccp/ccid.h:166 [inline]
    RIP: 0010:dccp_write_xmit+0x49/0x140 net/dccp/output.c:356
    <...>
    Call Trace:
     <TASK>
     dccp_sendmsg+0x642/0x7e0 net/dccp/proto.c:801
     inet_sendmsg+0x63/0x90 net/ipv4/af_inet.c:846
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0x83/0xe0 net/socket.c:745
     ____sys_sendmsg+0x443/0x510 net/socket.c:2558
     ___sys_sendmsg+0xe5/0x150 net/socket.c:2612
     __sys_sendmsg+0xa6/0x120 net/socket.c:2641
     __do_sys_sendmsg net/socket.c:2650 [inline]
     __se_sys_sendmsg net/socket.c:2648 [inline]
     __x64_sys_sendmsg+0x45/0x50 net/socket.c:2648
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x43/0x110 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    sk_wait_event() returns an error (-EPIPE) if disconnect() is called on the
    socket waiting for the event. However, sk_stream_wait_connect() returns
    success, i.e. zero, even if sk_wait_event() returns -EPIPE, so a function
    that waits for a connection with sk_stream_wait_connect() may misbehave.
    
    In the case of the above DCCP issue, dccp_sendmsg() is waiting for the
    connection. If disconnect() is called in concurrently, the above issue
    occurs.
    
    This patch fixes the issue by returning error from sk_stream_wait_connect()
    if sk_wait_event() fails.
    
    Fixes: 419ce133ab92 ("tcp: allow again tcp_disconnect() when threads are waiting")
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reported-by: syzbot+c71bc336c5061153b502@syzkaller.appspotmail.com
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: rfkill: gpio: set GPIO direction [+ + +]
Author: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Date:   Thu Dec 7 08:58:36 2023 +0100

    net: rfkill: gpio: set GPIO direction
    
    commit 23484d817082c3005252d8edfc8292c8a1006b5b upstream.
    
    Fix the undefined usage of the GPIO consumer API after retrieving the
    GPIO description with GPIO_ASIS. The API documentation mentions that
    GPIO_ASIS won't set a GPIO direction and requires the user to set a
    direction before using the GPIO.
    
    This can be confirmed on i.MX6 hardware, where rfkill-gpio is no longer
    able to enabled/disable a device, presumably because the GPIO controller
    was never configured for the output direction.
    
    Fixes: b2f750c3a80b ("net: rfkill: gpio: prevent value glitch during probe")
    Cc: stable@vger.kernel.org
    Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
    Link: https://msgid.link/20231207075835.3091694-1-r.czerwinski@pengutronix.de
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: sched: ife: fix potential use-after-free [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Dec 14 11:30:38 2023 +0000

    net: sched: ife: fix potential use-after-free
    
    [ Upstream commit 19391a2ca98baa7b80279306cdf7dd43f81fa595 ]
    
    ife_decode() calls pskb_may_pull() two times, we need to reload
    ifehdr after the second one, or risk use-after-free as reported
    by syzbot:
    
    BUG: KASAN: slab-use-after-free in __ife_tlv_meta_valid net/ife/ife.c:108 [inline]
    BUG: KASAN: slab-use-after-free in ife_tlv_meta_decode+0x1d1/0x210 net/ife/ife.c:131
    Read of size 2 at addr ffff88802d7300a4 by task syz-executor.5/22323
    
    CPU: 0 PID: 22323 Comm: syz-executor.5 Not tainted 6.7.0-rc3-syzkaller-00804-g074ac38d5b95 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
    Call Trace:
    <TASK>
    __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
    print_address_description mm/kasan/report.c:364 [inline]
    print_report+0xc4/0x620 mm/kasan/report.c:475
    kasan_report+0xda/0x110 mm/kasan/report.c:588
    __ife_tlv_meta_valid net/ife/ife.c:108 [inline]
    ife_tlv_meta_decode+0x1d1/0x210 net/ife/ife.c:131
    tcf_ife_decode net/sched/act_ife.c:739 [inline]
    tcf_ife_act+0x4e3/0x1cd0 net/sched/act_ife.c:879
    tc_act include/net/tc_wrapper.h:221 [inline]
    tcf_action_exec+0x1ac/0x620 net/sched/act_api.c:1079
    tcf_exts_exec include/net/pkt_cls.h:344 [inline]
    mall_classify+0x201/0x310 net/sched/cls_matchall.c:42
    tc_classify include/net/tc_wrapper.h:227 [inline]
    __tcf_classify net/sched/cls_api.c:1703 [inline]
    tcf_classify+0x82f/0x1260 net/sched/cls_api.c:1800
    hfsc_classify net/sched/sch_hfsc.c:1147 [inline]
    hfsc_enqueue+0x315/0x1060 net/sched/sch_hfsc.c:1546
    dev_qdisc_enqueue+0x3f/0x230 net/core/dev.c:3739
    __dev_xmit_skb net/core/dev.c:3828 [inline]
    __dev_queue_xmit+0x1de1/0x3d30 net/core/dev.c:4311
    dev_queue_xmit include/linux/netdevice.h:3165 [inline]
    packet_xmit+0x237/0x350 net/packet/af_packet.c:276
    packet_snd net/packet/af_packet.c:3081 [inline]
    packet_sendmsg+0x24aa/0x5200 net/packet/af_packet.c:3113
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190
    __do_sys_sendto net/socket.c:2202 [inline]
    __se_sys_sendto net/socket.c:2198 [inline]
    __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
    do_syscall_x64 arch/x86/entry/common.c:51 [inline]
    do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    RIP: 0033:0x7fe9acc7cae9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fe9ada450c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 00007fe9acd9bf80 RCX: 00007fe9acc7cae9
    RDX: 000000000000fce0 RSI: 00000000200002c0 RDI: 0000000000000003
    RBP: 00007fe9accc847a R08: 0000000020000140 R09: 0000000000000014
    R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007fe9acd9bf80 R15: 00007ffd5427ae78
    </TASK>
    
    Allocated by task 22323:
    kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
    kasan_set_track+0x25/0x30 mm/kasan/common.c:52
    ____kasan_kmalloc mm/kasan/common.c:374 [inline]
    __kasan_kmalloc+0xa2/0xb0 mm/kasan/common.c:383
    kasan_kmalloc include/linux/kasan.h:198 [inline]
    __do_kmalloc_node mm/slab_common.c:1007 [inline]
    __kmalloc_node_track_caller+0x5a/0x90 mm/slab_common.c:1027
    kmalloc_reserve+0xef/0x260 net/core/skbuff.c:582
    __alloc_skb+0x12b/0x330 net/core/skbuff.c:651
    alloc_skb include/linux/skbuff.h:1298 [inline]
    alloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331
    sock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780
    packet_alloc_skb net/packet/af_packet.c:2930 [inline]
    packet_snd net/packet/af_packet.c:3024 [inline]
    packet_sendmsg+0x1e2a/0x5200 net/packet/af_packet.c:3113
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190
    __do_sys_sendto net/socket.c:2202 [inline]
    __se_sys_sendto net/socket.c:2198 [inline]
    __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
    do_syscall_x64 arch/x86/entry/common.c:51 [inline]
    do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Freed by task 22323:
    kasan_save_stack+0x33/0x50 mm/kasan/common.c:45
    kasan_set_track+0x25/0x30 mm/kasan/common.c:52
    kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522
    ____kasan_slab_free mm/kasan/common.c:236 [inline]
    ____kasan_slab_free+0x15b/0x1b0 mm/kasan/common.c:200
    kasan_slab_free include/linux/kasan.h:164 [inline]
    slab_free_hook mm/slub.c:1800 [inline]
    slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826
    slab_free mm/slub.c:3809 [inline]
    __kmem_cache_free+0xc0/0x180 mm/slub.c:3822
    skb_kfree_head net/core/skbuff.c:950 [inline]
    skb_free_head+0x110/0x1b0 net/core/skbuff.c:962
    pskb_expand_head+0x3c5/0x1170 net/core/skbuff.c:2130
    __pskb_pull_tail+0xe1/0x1830 net/core/skbuff.c:2655
    pskb_may_pull_reason include/linux/skbuff.h:2685 [inline]
    pskb_may_pull include/linux/skbuff.h:2693 [inline]
    ife_decode+0x394/0x4f0 net/ife/ife.c:82
    tcf_ife_decode net/sched/act_ife.c:727 [inline]
    tcf_ife_act+0x43b/0x1cd0 net/sched/act_ife.c:879
    tc_act include/net/tc_wrapper.h:221 [inline]
    tcf_action_exec+0x1ac/0x620 net/sched/act_api.c:1079
    tcf_exts_exec include/net/pkt_cls.h:344 [inline]
    mall_classify+0x201/0x310 net/sched/cls_matchall.c:42
    tc_classify include/net/tc_wrapper.h:227 [inline]
    __tcf_classify net/sched/cls_api.c:1703 [inline]
    tcf_classify+0x82f/0x1260 net/sched/cls_api.c:1800
    hfsc_classify net/sched/sch_hfsc.c:1147 [inline]
    hfsc_enqueue+0x315/0x1060 net/sched/sch_hfsc.c:1546
    dev_qdisc_enqueue+0x3f/0x230 net/core/dev.c:3739
    __dev_xmit_skb net/core/dev.c:3828 [inline]
    __dev_queue_xmit+0x1de1/0x3d30 net/core/dev.c:4311
    dev_queue_xmit include/linux/netdevice.h:3165 [inline]
    packet_xmit+0x237/0x350 net/packet/af_packet.c:276
    packet_snd net/packet/af_packet.c:3081 [inline]
    packet_sendmsg+0x24aa/0x5200 net/packet/af_packet.c:3113
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190
    __do_sys_sendto net/socket.c:2202 [inline]
    __se_sys_sendto net/socket.c:2198 [inline]
    __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
    do_syscall_x64 arch/x86/entry/common.c:51 [inline]
    do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    The buggy address belongs to the object at ffff88802d730000
    which belongs to the cache kmalloc-8k of size 8192
    The buggy address is located 164 bytes inside of
    freed 8192-byte region [ffff88802d730000, ffff88802d732000)
    
    The buggy address belongs to the physical page:
    page:ffffea0000b5cc00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2d730
    head:ffffea0000b5cc00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    flags: 0xfff00000000840(slab|head|node=0|zone=1|lastcpupid=0x7ff)
    page_type: 0xffffffff()
    raw: 00fff00000000840 ffff888013042280 dead000000000122 0000000000000000
    raw: 0000000000000000 0000000080020002 00000001ffffffff 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 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 22323, tgid 22320 (syz-executor.5), ts 950317230369, free_ts 950233467461
    set_page_owner include/linux/page_owner.h:31 [inline]
    post_alloc_hook+0x2d0/0x350 mm/page_alloc.c:1544
    prep_new_page mm/page_alloc.c:1551 [inline]
    get_page_from_freelist+0xa28/0x3730 mm/page_alloc.c:3319
    __alloc_pages+0x22e/0x2420 mm/page_alloc.c:4575
    alloc_pages_mpol+0x258/0x5f0 mm/mempolicy.c:2133
    alloc_slab_page mm/slub.c:1870 [inline]
    allocate_slab mm/slub.c:2017 [inline]
    new_slab+0x283/0x3c0 mm/slub.c:2070
    ___slab_alloc+0x979/0x1500 mm/slub.c:3223
    __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3322
    __slab_alloc_node mm/slub.c:3375 [inline]
    slab_alloc_node mm/slub.c:3468 [inline]
    __kmem_cache_alloc_node+0x131/0x310 mm/slub.c:3517
    __do_kmalloc_node mm/slab_common.c:1006 [inline]
    __kmalloc_node_track_caller+0x4a/0x90 mm/slab_common.c:1027
    kmalloc_reserve+0xef/0x260 net/core/skbuff.c:582
    __alloc_skb+0x12b/0x330 net/core/skbuff.c:651
    alloc_skb include/linux/skbuff.h:1298 [inline]
    alloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331
    sock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780
    packet_alloc_skb net/packet/af_packet.c:2930 [inline]
    packet_snd net/packet/af_packet.c:3024 [inline]
    packet_sendmsg+0x1e2a/0x5200 net/packet/af_packet.c:3113
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190
    page last free stack trace:
    reset_page_owner include/linux/page_owner.h:24 [inline]
    free_pages_prepare mm/page_alloc.c:1144 [inline]
    free_unref_page_prepare+0x53c/0xb80 mm/page_alloc.c:2354
    free_unref_page+0x33/0x3b0 mm/page_alloc.c:2494
    __unfreeze_partials+0x226/0x240 mm/slub.c:2655
    qlink_free mm/kasan/quarantine.c:168 [inline]
    qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:187
    kasan_quarantine_reduce+0x18e/0x1d0 mm/kasan/quarantine.c:294
    __kasan_slab_alloc+0x65/0x90 mm/kasan/common.c:305
    kasan_slab_alloc include/linux/kasan.h:188 [inline]
    slab_post_alloc_hook mm/slab.h:763 [inline]
    slab_alloc_node mm/slub.c:3478 [inline]
    slab_alloc mm/slub.c:3486 [inline]
    __kmem_cache_alloc_lru mm/slub.c:3493 [inline]
    kmem_cache_alloc_lru+0x219/0x6f0 mm/slub.c:3509
    alloc_inode_sb include/linux/fs.h:2937 [inline]
    ext4_alloc_inode+0x28/0x650 fs/ext4/super.c:1408
    alloc_inode+0x5d/0x220 fs/inode.c:261
    new_inode_pseudo fs/inode.c:1006 [inline]
    new_inode+0x22/0x260 fs/inode.c:1032
    __ext4_new_inode+0x333/0x5200 fs/ext4/ialloc.c:958
    ext4_symlink+0x5d7/0xa20 fs/ext4/namei.c:3398
    vfs_symlink fs/namei.c:4464 [inline]
    vfs_symlink+0x3e5/0x620 fs/namei.c:4448
    do_symlinkat+0x25f/0x310 fs/namei.c:4490
    __do_sys_symlinkat fs/namei.c:4506 [inline]
    __se_sys_symlinkat fs/namei.c:4503 [inline]
    __x64_sys_symlinkat+0x97/0xc0 fs/namei.c:4503
    do_syscall_x64 arch/x86/entry/common.c:51 [inline]
    do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
    
    Fixes: d57493d6d1be ("net: sched: ife: check on metadata length")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Alexander Aring <aahringo@redhat.com>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: fix incorrect flag check in timestamp interrupt [+ + +]
Author: Lai Peter Jun Ann <jun.ann.lai@intel.com>
Date:   Mon Dec 18 15:51:32 2023 +0800

    net: stmmac: fix incorrect flag check in timestamp interrupt
    
    commit bd7f77dae69532ffc027ee50ff99e3792dc30b7f upstream.
    
    The driver should continue get the timestamp if STMMAC_FLAG_EXT_SNAPSHOT_EN
    flag is set.
    
    Fixes: aa5513f5d95f ("net: stmmac: replace the ext_snapshot_en field with a flag")
    Cc: <stable@vger.kernel.org> # 6.6
    Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com>
    Signed-off-by: Lai Peter Jun Ann <jun.ann.lai@intel.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: ax88179_178a: avoid failed operations when device is disconnected [+ + +]
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Thu Dec 7 18:50:07 2023 +0100

    net: usb: ax88179_178a: avoid failed operations when device is disconnected
    
    commit aef05e349bfd81c95adb4489639413fadbb74a83 upstream.
    
    When the device is disconnected we get the following messages showing
    failed operations:
    Nov 28 20:22:11 localhost kernel: usb 2-3: USB disconnect, device number 2
    Nov 28 20:22:11 localhost kernel: ax88179_178a 2-3:1.0 enp2s0u3: unregister 'ax88179_178a' usb-0000:02:00.0-3, ASIX AX88179 USB 3.0 Gigabit Ethernet
    Nov 28 20:22:11 localhost kernel: ax88179_178a 2-3:1.0 enp2s0u3: Failed to read reg index 0x0002: -19
    Nov 28 20:22:11 localhost kernel: ax88179_178a 2-3:1.0 enp2s0u3: Failed to write reg index 0x0002: -19
    Nov 28 20:22:11 localhost kernel: ax88179_178a 2-3:1.0 enp2s0u3 (unregistered): Failed to write reg index 0x0002: -19
    Nov 28 20:22:11 localhost kernel: ax88179_178a 2-3:1.0 enp2s0u3 (unregistered): Failed to write reg index 0x0001: -19
    Nov 28 20:22:11 localhost kernel: ax88179_178a 2-3:1.0 enp2s0u3 (unregistered): Failed to write reg index 0x0002: -19
    
    The reason is that although the device is detached, normal stop and
    unbind operations are commanded from the driver. These operations are
    not necessary in this situation, so avoid these logs when the device is
    detached if the result of the operation is -ENODEV and if the new flag
    informing about the disconnecting status is enabled.
    
    cc:  <stable@vger.kernel.org>
    Fixes: e2ca90c276e1f ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20231207175007.263907-1-jtornosm@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfsd: call nfsd_last_thread() before final nfsd_put() [+ + +]
Author: NeilBrown <neilb@suse.de>
Date:   Fri Dec 15 11:56:31 2023 +1100

    nfsd: call nfsd_last_thread() before final nfsd_put()
    
    commit 2a501f55cd641eb4d3c16a2eab0d678693fac663 upstream.
    
    If write_ports_addfd or write_ports_addxprt fail, they call nfsd_put()
    without calling nfsd_last_thread().  This leaves nn->nfsd_serv pointing
    to a structure that has been freed.
    
    So remove 'static' from nfsd_last_thread() and call it when the
    nfsd_serv is about to be destroyed.
    
    Fixes: ec52361df99b ("SUNRPC: stop using ->sv_nrthreads as a refcount")
    Signed-off-by: NeilBrown <neilb@suse.de>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nvme-pci: fix sleeping function called from interrupt context [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Tue Dec 19 17:48:23 2023 +0100

    nvme-pci: fix sleeping function called from interrupt context
    
    [ Upstream commit f6fe0b2d35457c10ec37acc209d19726bdc16dbd ]
    
    the nvme_handle_cqe() interrupt handler calls nvme_complete_async_event()
    but the latter may call nvme_auth_stop() which is a blocking function.
    Sleeping functions can't be called in interrupt context
    
     BUG: sleeping function called from invalid context
     in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/15
      Call Trace:
         <IRQ>
          __cancel_work_timer+0x31e/0x460
          ? nvme_change_ctrl_state+0xcf/0x3c0 [nvme_core]
          ? nvme_change_ctrl_state+0xcf/0x3c0 [nvme_core]
          nvme_complete_async_event+0x365/0x480 [nvme_core]
          nvme_poll_cq+0x262/0xe50 [nvme]
    
    Fix the bug by moving nvme_auth_stop() to fw_act_work
    (executed by the nvme_wq workqueue)
    
    Fixes: f50fff73d620 ("nvme: implement In-Band authentication")
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmem: brcm_nvram: store a copy of NVRAM content [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Fri Dec 15 11:13:58 2023 +0000

    nvmem: brcm_nvram: store a copy of NVRAM content
    
    commit 1e37bf84afacd5ba17b7a13a18ca2bc78aff05c0 upstream.
    
    This driver uses MMIO access for reading NVRAM from a flash device.
    Underneath there is a flash controller that reads data and provides
    mapping window.
    
    Using MMIO interface affects controller configuration and may break real
    controller driver. It was reported by multiple users of devices with
    NVRAM stored on NAND.
    
    Modify driver to read & cache NVRAM content during init and use that
    copy to provide NVMEM data when requested. On NAND flashes due to their
    alignment NVRAM partitions can be quite big (1 MiB and more) while
    actual NVRAM content stays quite small (usually 16 to 32 KiB). To avoid
    allocating so much memory check for actual data length.
    
    Link: https://lore.kernel.org/linux-mtd/CACna6rwf3_9QVjYcM+847biTX=K0EoWXuXcSMkJO1Vy_5vmVqA@mail.gmail.com/
    Fixes: 3fef9ed0627a ("nvmem: brcm_nvram: new driver exposing Broadcom's NVRAM")
    Cc:  <Stable@vger.kernel.org>
    Cc: Arınç ÜNAL <arinc.unal@arinc9.com>
    Cc: Florian Fainelli <florian.fainelli@broadcom.com>
    Cc: Scott Branden <scott.branden@broadcom.com>
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20231215111358.316727-3-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
octeontx2-pf: Fix graceful exit during PFC configuration failure [+ + +]
Author: Suman Ghosh <sumang@marvell.com>
Date:   Wed Dec 13 23:40:44 2023 +0530

    octeontx2-pf: Fix graceful exit during PFC configuration failure
    
    [ Upstream commit 8c97ab5448f2096daba11edf8d18a44e1eb6f31d ]
    
    During PFC configuration failure the code was not handling a graceful
    exit. This patch fixes the same and add proper code for a graceful exit.
    
    Fixes: 99c969a83d82 ("octeontx2-pf: Add egress PFC support")
    Signed-off-by: Suman Ghosh <sumang@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: at91-pio4: use dedicated lock class for IRQ [+ + +]
Author: Alexis Lothoré <alexis.lothore@bootlin.com>
Date:   Fri Dec 15 22:34:24 2023 +0100

    pinctrl: at91-pio4: use dedicated lock class for IRQ
    
    [ Upstream commit 14694179e561b5f2f7e56a0f590e2cb49a9cc7ab ]
    
    Trying to suspend to RAM on SAMA5D27 EVK leads to the following lockdep
    warning:
    
     ============================================
     WARNING: possible recursive locking detected
     6.7.0-rc5-wt+ #532 Not tainted
     --------------------------------------------
     sh/92 is trying to acquire lock:
     c3cf306c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100
    
     but task is already holding lock:
     c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100
    
     other info that might help us debug this:
      Possible unsafe locking scenario:
    
            CPU0
            ----
       lock(&irq_desc_lock_class);
       lock(&irq_desc_lock_class);
    
      *** DEADLOCK ***
    
      May be due to missing lock nesting notation
    
     6 locks held by sh/92:
      #0: c3aa0258 (sb_writers#6){.+.+}-{0:0}, at: ksys_write+0xd8/0x178
      #1: c4c2df44 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x138/0x284
      #2: c32684a0 (kn->active){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x148/0x284
      #3: c232b6d4 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x13c/0x4e8
      #4: c387b088 (&dev->mutex){....}-{3:3}, at: __device_suspend+0x1e8/0x91c
      #5: c3d7c46c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0xe8/0x100
    
     stack backtrace:
     CPU: 0 PID: 92 Comm: sh Not tainted 6.7.0-rc5-wt+ #532
     Hardware name: Atmel SAMA5
      unwind_backtrace from show_stack+0x18/0x1c
      show_stack from dump_stack_lvl+0x34/0x48
      dump_stack_lvl from __lock_acquire+0x19ec/0x3a0c
      __lock_acquire from lock_acquire.part.0+0x124/0x2d0
      lock_acquire.part.0 from _raw_spin_lock_irqsave+0x5c/0x78
      _raw_spin_lock_irqsave from __irq_get_desc_lock+0xe8/0x100
      __irq_get_desc_lock from irq_set_irq_wake+0xa8/0x204
      irq_set_irq_wake from atmel_gpio_irq_set_wake+0x58/0xb4
      atmel_gpio_irq_set_wake from irq_set_irq_wake+0x100/0x204
      irq_set_irq_wake from gpio_keys_suspend+0xec/0x2b8
      gpio_keys_suspend from dpm_run_callback+0xe4/0x248
      dpm_run_callback from __device_suspend+0x234/0x91c
      __device_suspend from dpm_suspend+0x224/0x43c
      dpm_suspend from dpm_suspend_start+0x9c/0xa8
      dpm_suspend_start from suspend_devices_and_enter+0x1e0/0xa84
      suspend_devices_and_enter from pm_suspend+0x460/0x4e8
      pm_suspend from state_store+0x78/0xe4
      state_store from kernfs_fop_write_iter+0x1a0/0x284
      kernfs_fop_write_iter from vfs_write+0x38c/0x6f4
      vfs_write from ksys_write+0xd8/0x178
      ksys_write from ret_fast_syscall+0x0/0x1c
     Exception stack(0xc52b3fa8 to 0xc52b3ff0)
     3fa0:                   00000004 005a0ae8 00000001 005a0ae8 00000004 00000001
     3fc0: 00000004 005a0ae8 00000001 00000004 00000004 b6c616c0 00000020 0059d190
     3fe0: 00000004 b6c61678 aec5a041 aebf1a26
    
    This warning is raised because pinctrl-at91-pio4 uses chained IRQ. Whenever
    a wake up source configures an IRQ through irq_set_irq_wake, it will
    lock the corresponding IRQ desc, and then call irq_set_irq_wake on "parent"
    IRQ which will do the same on its own IRQ desc, but since those two locks
    share the same class, lockdep reports this as an issue.
    
    Fix lockdep false positive by setting a different class for parent and
    children IRQ
    
    Fixes: 776180848b57 ("pinctrl: introduce driver for Atmel PIO4 controller")
    Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
    Link: https://lore.kernel.org/r/20231215-lockdep_warning-v1-1-8137b2510ed5@bootlin.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: starfive: jh7100: ignore disabled device tree nodes [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Fri Dec 1 10:23:29 2023 +0100

    pinctrl: starfive: jh7100: ignore disabled device tree nodes
    
    commit 5c584f175d32f9cc66c909f851cd905da58b39ea upstream.
    
    The driver always registers pin configurations in device tree. This can
    cause some inconvenience to users, as pin configurations in the base
    device tree cannot be disabled in the device tree overlay, even when the
    relevant devices are not used.
    
    Ignore disabled pin configuration nodes in device tree.
    
    Fixes: ec648f6b7686 ("pinctrl: starfive: Add pinctrl driver for StarFive SoCs")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Link: https://lore.kernel.org/r/fe4c15dcc3074412326b8dc296b0cbccf79c49bf.1701422582.git.namcao@linutronix.de
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pinctrl: starfive: jh7110: ignore disabled device tree nodes [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Fri Dec 1 10:23:28 2023 +0100

    pinctrl: starfive: jh7110: ignore disabled device tree nodes
    
    commit f6e3b40a2c89c1d832ed9cb031dc9825bbf43b7c upstream.
    
    The driver always registers pin configurations in device tree. This can
    cause some inconvenience to users, as pin configurations in the base
    device tree cannot be disabled in the device tree overlay, even when the
    relevant devices are not used.
    
    Ignore disabled pin configuration nodes in device tree.
    
    Fixes: 447976ab62c5 ("pinctrl: starfive: Add StarFive JH7110 sys controller driver")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Link: https://lore.kernel.org/r/fd8bf044799ae50a6291ae150ef87b4f1923cacb.1701422582.git.namcao@linutronix.de
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
platform/x86/intel/pmc: Fix hang in pmc_core_send_ltr_ignore() [+ + +]
Author: Rajvi Jingar <rajvi.jingar@linux.intel.com>
Date:   Fri Dec 15 17:16:50 2023 -0800

    platform/x86/intel/pmc: Fix hang in pmc_core_send_ltr_ignore()
    
    [ Upstream commit fbcf67ce5a9e2831c14bdfb895be05213e611724 ]
    
    For input value 0, PMC stays unassigned which causes crash while trying
    to access PMC for register read/write. Include LTR index 0 in pmc_index
    and ltr_index calculation.
    
    Fixes: 2bcef4529222 ("platform/x86:intel/pmc: Enable debugfs multiple PMC support")
    Signed-off-by: Rajvi Jingar <rajvi.jingar@linux.intel.com>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20231216011650.1973941-1-rajvi.jingar@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
reset: Fix crash when freeing non-existent optional resets [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Nov 29 17:55:33 2023 +0100

    reset: Fix crash when freeing non-existent optional resets
    
    [ Upstream commit 4a6756f56bcf8e64c87144a626ce53aea4899c0e ]
    
    When obtaining one or more optional resets, non-existent resets are
    stored as NULL pointers, and all related error and cleanup paths need to
    take this into account.
    
    Currently only reset_control_put() and reset_control_bulk_put()
    get this right.  All of __reset_control_bulk_get(),
    of_reset_control_array_get(), and reset_control_array_put() lack the
    proper checking, causing NULL pointer dereferences on failure or
    release.
    
    Fix this by moving the existing check from reset_control_bulk_put() to
    __reset_control_put_internal(), so it applies to all callers.
    The double check in reset_control_put() doesn't hurt.
    
    Fixes: 17c82e206d2a3cd8 ("reset: Add APIs to manage array of resets")
    Fixes: 48d71395896d54ee ("reset: Add reset_control_bulk API")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/2440edae7ca8534628cdbaf559ded288f2998178.1701276806.git.geert+renesas@glider.be
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "net/mlx5e: fix double free of encap_header in update funcs" [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Tue Nov 21 13:51:52 2023 +0100

    Revert "net/mlx5e: fix double free of encap_header in update funcs"
    
    [ Upstream commit 66ca8d4deca09bce3fc7bcf8ea7997fa1a51c33c ]
    
    This reverts commit 3a4aa3cb83563df942be49d145ee3b7ddf17d6bb.
    
    This patch is causing a null ptr issue, the proper fix is in the next
    patch.
    
    Fixes: 3a4aa3cb8356 ("net/mlx5e: fix double free of encap_header in update funcs")
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Revert "net/mlx5e: fix double free of encap_header" [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Tue Nov 21 13:52:28 2023 +0100

    Revert "net/mlx5e: fix double free of encap_header"
    
    [ Upstream commit 5d089684dc434a31e08d32f0530066d0025c52e4 ]
    
    This reverts commit 6f9b1a0731662648949a1c0587f6acb3b7f8acf1.
    
    This patch is causing a null ptr issue, the proper fix is in the next
    patch.
    
    Fixes: 6f9b1a073166 ("net/mlx5e: fix double free of encap_header")
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "scsi: aacraid: Reply queue mapping to CPUs based on IRQ affinity" [+ + +]
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Fri Dec 8 12:09:38 2023 -0500

    Revert "scsi: aacraid: Reply queue mapping to CPUs based on IRQ affinity"
    
    commit c5becf57dd5659c687d41d623a69f42d63f59eb2 upstream.
    
    This reverts commit 9dc704dcc09eae7d21b5da0615eb2ed79278f63e.
    
    Several reports have been made indicating that this commit caused
    hangs. Numerous attempts at root causing and fixing the issue have
    been unsuccessful so let's revert for now.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217599
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ring-buffer: Fix 32-bit rb_time_read() race with rb_time_cmpxchg() [+ + +]
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Tue Dec 12 14:30:49 2023 -0500

    ring-buffer: Fix 32-bit rb_time_read() race with rb_time_cmpxchg()
    
    [ Upstream commit dec890089bf79a4954b61482715ee2d084364856 ]
    
    The following race can cause rb_time_read() to observe a corrupted time
    stamp:
    
    rb_time_cmpxchg()
    [...]
            if (!rb_time_read_cmpxchg(&t->msb, msb, msb2))
                    return false;
            if (!rb_time_read_cmpxchg(&t->top, top, top2))
                    return false;
    <interrupted before updating bottom>
    __rb_time_read()
    [...]
            do {
                    c = local_read(&t->cnt);
                    top = local_read(&t->top);
                    bottom = local_read(&t->bottom);
                    msb = local_read(&t->msb);
            } while (c != local_read(&t->cnt));
    
            *cnt = rb_time_cnt(top);
    
            /* If top and msb counts don't match, this interrupted a write */
            if (*cnt != rb_time_cnt(msb))
                    return false;
              ^ this check fails to catch that "bottom" is still not updated.
    
    So the old "bottom" value is returned, which is wrong.
    
    Fix this by checking that all three of msb, top, and bottom 2-bit cnt
    values match.
    
    The reason to favor checking all three fields over requiring a specific
    update order for both rb_time_set() and rb_time_cmpxchg() is because
    checking all three fields is more robust to handle partial failures of
    rb_time_cmpxchg() when interrupted by nested rb_time_set().
    
    Link: https://lore.kernel.org/lkml/20231211201324.652870-1-mathieu.desnoyers@efficios.com/
    Link: https://lore.kernel.org/linux-trace-kernel/20231212193049.680122-1-mathieu.desnoyers@efficios.com
    
    Fixes: f458a1453424e ("ring-buffer: Test last update in 32bit version of __rb_time_read()")
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ring-buffer: Fix slowpath of interrupted event [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Mon Dec 18 23:07:12 2023 -0500

    ring-buffer: Fix slowpath of interrupted event
    
    [ Upstream commit b803d7c664d55705831729d2f2e29c874bcd62ea ]
    
    To synchronize the timestamps with the ring buffer reservation, there are
    two timestamps that are saved in the buffer meta data.
    
    1. before_stamp
    2. write_stamp
    
    When the two are equal, the write_stamp is considered valid, as in, it may
    be used to calculate the delta of the next event as the write_stamp is the
    timestamp of the previous reserved event on the buffer.
    
    This is done by the following:
    
     /*A*/  w = current position on the ring buffer
            before = before_stamp
            after = write_stamp
            ts = read current timestamp
    
            if (before != after) {
                    write_stamp is not valid, force adding an absolute
                    timestamp.
            }
    
     /*B*/  before_stamp = ts
    
     /*C*/  write = local_add_return(event length, position on ring buffer)
    
            if (w == write - event length) {
                    /* Nothing interrupted between A and C */
     /*E*/          write_stamp = ts;
                    delta = ts - after
                    /*
                     * If nothing interrupted again,
                     * before_stamp == write_stamp and write_stamp
                     * can be used to calculate the delta for
                     * events that come in after this one.
                     */
            } else {
    
                    /*
                     * The slow path!
                     * Was interrupted between A and C.
                     */
    
    This is the place that there's a bug. We currently have:
    
                    after = write_stamp
                    ts = read current timestamp
    
     /*F*/          if (write == current position on the ring buffer &&
                        after < ts && cmpxchg(write_stamp, after, ts)) {
    
                            delta = ts - after;
    
                    } else {
                            delta = 0;
                    }
    
    The assumption is that if the current position on the ring buffer hasn't
    moved between C and F, then it also was not interrupted, and that the last
    event written has a timestamp that matches the write_stamp. That is the
    write_stamp is valid.
    
    But this may not be the case:
    
    If a task context event was interrupted by softirq between B and C.
    
    And the softirq wrote an event that got interrupted by a hard irq between
    C and E.
    
    and the hard irq wrote an event (does not need to be interrupted)
    
    We have:
    
     /*B*/ before_stamp = ts of normal context
    
       ---> interrupted by softirq
    
            /*B*/ before_stamp = ts of softirq context
    
              ---> interrupted by hardirq
    
                    /*B*/ before_stamp = ts of hard irq context
                    /*E*/ write_stamp = ts of hard irq context
    
                    /* matches and write_stamp valid */
              <----
    
            /*E*/ write_stamp = ts of softirq context
    
            /* No longer matches before_stamp, write_stamp is not valid! */
    
       <---
    
     w != write - length, go to slow path
    
    // Right now the order of events in the ring buffer is:
    //
    // |-- softirq event --|-- hard irq event --|-- normal context event --|
    //
    
     after = write_stamp (this is the ts of softirq)
     ts = read current timestamp
    
     if (write == current position on the ring buffer [true] &&
         after < ts [true] && cmpxchg(write_stamp, after, ts) [true]) {
    
            delta = ts - after  [Wrong!]
    
    The delta is to be between the hard irq event and the normal context
    event, but the above logic made the delta between the softirq event and
    the normal context event, where the hard irq event is between the two. This
    will shift all the remaining event timestamps on the sub-buffer
    incorrectly.
    
    The write_stamp is only valid if it matches the before_stamp. The cmpxchg
    does nothing to help this.
    
    Instead, the following logic can be done to fix this:
    
            before = before_stamp
            ts = read current timestamp
            before_stamp = ts
    
            after = write_stamp
    
            if (write == current position on the ring buffer &&
                after == before && after < ts) {
    
                    delta = ts - after
    
            } else {
                    delta = 0;
            }
    
    The above will only use the write_stamp if it still matches before_stamp
    and was tested to not have changed since C.
    
    As a bonus, with this logic we do not need any 64-bit cmpxchg() at all!
    
    This means the 32-bit rb_time_t workaround can finally be removed. But
    that's for a later time.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231218175229.58ec3daf@gandalf.local.home/
    Link: https://lore.kernel.org/linux-trace-kernel/20231218230712.3a76b081@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Fixes: dd93942570789 ("ring-buffer: Do not try to put back write_stamp")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ring-buffer: Remove useless update to write_stamp in rb_try_to_discard() [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Fri Dec 15 08:18:10 2023 -0500

    ring-buffer: Remove useless update to write_stamp in rb_try_to_discard()
    
    [ Upstream commit 083e9f65bd215582bf8f6a920db729fadf16704f ]
    
    When filtering is enabled, a temporary buffer is created to place the
    content of the trace event output so that the filter logic can decide
    from the trace event output if the trace event should be filtered out or
    not. If it is to be filtered out, the content in the temporary buffer is
    simply discarded, otherwise it is written into the trace buffer.
    
    But if an interrupt were to come in while a previous event was using that
    temporary buffer, the event written by the interrupt would actually go
    into the ring buffer itself to prevent corrupting the data on the
    temporary buffer. If the event is to be filtered out, the event in the
    ring buffer is discarded, or if it fails to discard because another event
    were to have already come in, it is turned into padding.
    
    The update to the write_stamp in the rb_try_to_discard() happens after a
    fix was made to force the next event after the discard to use an absolute
    timestamp by setting the before_stamp to zero so it does not match the
    write_stamp (which causes an event to use the absolute timestamp).
    
    But there's an effort in rb_try_to_discard() to put back the write_stamp
    to what it was before the event was added. But this is useless and
    wasteful because nothing is going to be using that write_stamp for
    calculations as it still will not match the before_stamp.
    
    Remove this useless update, and in doing so, we remove another
    cmpxchg64()!
    
    Also update the comments to reflect this change as well as remove some
    extra white space in another comment.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231215081810.1f4f38fe@rorschach.local.home
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Joel Fernandes <joel@joelfernandes.org>
    Cc: Vincent Donnefort   <vdonnefort@google.com>
    Fixes: b2dd797543cf ("ring-buffer: Force absolute timestamp on discard of event")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/vx: fix save/restore of fpu kernel context [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Fri Dec 8 15:03:15 2023 +0100

    s390/vx: fix save/restore of fpu kernel context
    
    [ Upstream commit e6b2dab41888332bf83f592131e7ea07756770a4 ]
    
    The KERNEL_FPR mask only contains a flag for the first eight vector
    registers. However floating point registers overlay parts of the first
    sixteen vector registers.
    
    This could lead to vector register corruption if a kernel fpu context uses
    any of the vector registers 8 to 15 and is interrupted or calls a
    KERNEL_FPR context. If that context uses also vector registers 8 to 15,
    their contents will be corrupted on return.
    
    Luckily this is currently not a real bug, since the kernel has only one
    KERNEL_FPR user with s390_adjust_jiffies() and it is only using floating
    point registers 0 to 2.
    
    Fix this by using the correct bits for KERNEL_FPR.
    
    Fixes: 7f79695cc1b6 ("s390/fpu: improve kernel_fpu_[begin|end]")
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: bnx2fc: Fix skb double free in bnx2fc_rcv() [+ + +]
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date:   Mon Nov 14 11:06:26 2022 +0000

    scsi: bnx2fc: Fix skb double free in bnx2fc_rcv()
    
    [ Upstream commit 08c94d80b2da481652fb633e79cbc41e9e326a91 ]
    
    skb_share_check() already drops the reference to the skb when returning
    NULL. Using kfree_skb() in the error handling path leads to an skb double
    free.
    
    Fix this by removing the variable tmp_skb, and return directly when
    skb_share_check() returns NULL.
    
    Fixes: 01a4cc4d0cd6 ("bnx2fc: do not add shared skbs to the fcoe_rx_list")
    Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
    Link: https://lore.kernel.org/r/20221114110626.526643-1-weiyongjun@huaweicloud.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: core: Always send batch on reset or error handling command [+ + +]
Author: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
Date:   Fri Dec 15 14:10:08 2023 +0200

    scsi: core: Always send batch on reset or error handling command
    
    commit 066c5b46b6eaf2f13f80c19500dbb3b84baabb33 upstream.
    
    In commit 8930a6c20791 ("scsi: core: add support for request batching") the
    block layer bd->last flag was mapped to SCMD_LAST and used as an indicator
    to send the batch for the drivers that implement this feature. However, the
    error handling code was not updated accordingly.
    
    scsi_send_eh_cmnd() is used to send error handling commands and request
    sense. The problem is that request sense comes as a single command that
    gets into the batch queue and times out. As a result the device goes
    offline after several failed resets. This was observed on virtio_scsi
    during a device resize operation.
    
    [  496.316946] sd 0:0:4:0: [sdd] tag#117 scsi_eh_0: requesting sense
    [  506.786356] sd 0:0:4:0: [sdd] tag#117 scsi_send_eh_cmnd timeleft: 0
    [  506.787981] sd 0:0:4:0: [sdd] tag#117 abort
    
    To fix this always set SCMD_LAST flag in scsi_send_eh_cmnd() and
    scsi_reset_ioctl().
    
    Fixes: 8930a6c20791 ("scsi: core: add support for request batching")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
    Link: https://lore.kernel.org/r/20231215121008.2881653-1-alexander.atanasov@virtuozzo.com
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: ufs: core: Let the sq_lock protect sq_tail_slot access [+ + +]
Author: Can Guo <quic_cang@quicinc.com>
Date:   Mon Dec 18 07:32:17 2023 -0800

    scsi: ufs: core: Let the sq_lock protect sq_tail_slot access
    
    [ Upstream commit 04c116e2bdfc3969f9819d2cebfdf678353c354c ]
    
    When accessing sq_tail_slot without protection from sq_lock, a race
    condition can cause multiple SQEs to be copied to duplicate SQE slots. This
    can lead to multiple stability issues. Fix this by moving the *dest
    initialization in ufshcd_send_command() back under protection from the
    sq_lock.
    
    Fixes: 3c85f087faec ("scsi: ufs: mcq: Use pointer arithmetic in ufshcd_send_command()")
    Signed-off-by: Can Guo <quic_cang@quicinc.com>
    Link: https://lore.kernel.org/r/1702913550-20631-1-git-send-email-quic_cang@quicinc.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: qcom: Return ufs_qcom_clk_scale_*() errors in ufs_qcom_clk_scale_notify() [+ + +]
Author: ChanWoo Lee <cw9316.lee@samsung.com>
Date:   Fri Dec 15 09:38:12 2023 +0900

    scsi: ufs: qcom: Return ufs_qcom_clk_scale_*() errors in ufs_qcom_clk_scale_notify()
    
    [ Upstream commit 9264fd61e628ce180a168e6b90bde134dd49ec28 ]
    
    In commit 031312dbc695 ("scsi: ufs: ufs-qcom: Remove unnecessary goto
    statements") the error handling was accidentally changed, resulting in the
    error of ufs_qcom_clk_scale_*() calls not being returned.
    
    This is the case I checked:
    
      ufs_qcom_clk_scale_notify ->
        'ufs_qcom_clk_scale_up_/down_pre_change' error ->
          return 0;
    
    Make sure those errors are properly returned.
    
    Fixes: 031312dbc695 ("scsi: ufs: ufs-qcom: Remove unnecessary goto statements")
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: ChanWoo Lee <cw9316.lee@samsung.com>
    Link: https://lore.kernel.org/r/20231215003812.29650-1-cw9316.lee@samsung.com
    Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: mptcp: join: fix subflow_send_ack lookup [+ + +]
Author: Geliang Tang <geliang.tang@linux.dev>
Date:   Fri Dec 15 17:04:24 2023 +0100

    selftests: mptcp: join: fix subflow_send_ack lookup
    
    commit c8f021eec5817601dbd25ab7e3ad5c720965c688 upstream.
    
    MPC backups tests will skip unexpected sometimes (For example, when
    compiling kernel with an older version of gcc, such as gcc-8), since
    static functions like mptcp_subflow_send_ack also be listed in
    /proc/kallsyms, with a 't' in front of it, not 'T' ('T' is for a global
    function):
    
     > grep "mptcp_subflow_send_ack" /proc/kallsyms
    
     0000000000000000 T __pfx___mptcp_subflow_send_ack
     0000000000000000 T __mptcp_subflow_send_ack
     0000000000000000 t __pfx_mptcp_subflow_send_ack
     0000000000000000 t mptcp_subflow_send_ack
    
    In this case, mptcp_lib_kallsyms_doesnt_have "mptcp_subflow_send_ack$"
    will be false, MPC backups tests will skip. This is not what we expected.
    
    The correct logic here should be: if mptcp_subflow_send_ack is not a
    global function in /proc/kallsyms, do these MPC backups tests. So a 'T'
    must be added in front of mptcp_subflow_send_ack.
    
    Fixes: 632978f0a961 ("selftests: mptcp: join: skip MPC backups tests if not supported")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <geliang.tang@linux.dev>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb: client: fix OOB in cifsd when receiving compounded resps [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Wed Dec 13 12:25:56 2023 -0300

    smb: client: fix OOB in cifsd when receiving compounded resps
    
    commit a8f68b11158f09754418de62e6b3e7b9b7a50cc9 upstream.
    
    Validate next header's offset in ->next_header() so that it isn't
    smaller than MID_HEADER_SIZE(server) and then standard_receive3() or
    ->receive() ends up writing off the end of the buffer because
    'pdu_length - MID_HEADER_SIZE(server)' wraps up to a huge length:
    
      BUG: KASAN: slab-out-of-bounds in _copy_to_iter+0x4fc/0x840
      Write of size 701 at addr ffff88800caf407f by task cifsd/1090
    
      CPU: 0 PID: 1090 Comm: cifsd Not tainted 6.7.0-rc4 #5
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
      rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x4a/0x80
       print_report+0xcf/0x650
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __phys_addr+0x46/0x90
       kasan_report+0xd8/0x110
       ? _copy_to_iter+0x4fc/0x840
       ? _copy_to_iter+0x4fc/0x840
       kasan_check_range+0x105/0x1b0
       __asan_memcpy+0x3c/0x60
       _copy_to_iter+0x4fc/0x840
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? hlock_class+0x32/0xc0
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __pfx__copy_to_iter+0x10/0x10
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? lock_is_held_type+0x90/0x100
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __might_resched+0x278/0x360
       ? __pfx___might_resched+0x10/0x10
       ? srso_alias_return_thunk+0x5/0xfbef5
       __skb_datagram_iter+0x2c2/0x460
       ? __pfx_simple_copy_to_iter+0x10/0x10
       skb_copy_datagram_iter+0x6c/0x110
       tcp_recvmsg_locked+0x9be/0xf40
       ? __pfx_tcp_recvmsg_locked+0x10/0x10
       ? mark_held_locks+0x5d/0x90
       ? srso_alias_return_thunk+0x5/0xfbef5
       tcp_recvmsg+0xe2/0x310
       ? __pfx_tcp_recvmsg+0x10/0x10
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? lock_acquire+0x14a/0x3a0
       ? srso_alias_return_thunk+0x5/0xfbef5
       inet_recvmsg+0xd0/0x370
       ? __pfx_inet_recvmsg+0x10/0x10
       ? __pfx_lock_release+0x10/0x10
       ? do_raw_spin_trylock+0xd1/0x120
       sock_recvmsg+0x10d/0x150
       cifs_readv_from_socket+0x25a/0x490 [cifs]
       ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs]
       ? srso_alias_return_thunk+0x5/0xfbef5
       cifs_read_from_socket+0xb5/0x100 [cifs]
       ? __pfx_cifs_read_from_socket+0x10/0x10 [cifs]
       ? __pfx_lock_release+0x10/0x10
       ? do_raw_spin_trylock+0xd1/0x120
       ? _raw_spin_unlock+0x23/0x40
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __smb2_find_mid+0x126/0x230 [cifs]
       cifs_demultiplex_thread+0xd39/0x1270 [cifs]
       ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]
       ? __pfx_lock_release+0x10/0x10
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? mark_held_locks+0x1a/0x90
       ? lockdep_hardirqs_on_prepare+0x136/0x210
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __kthread_parkme+0xce/0xf0
       ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]
       kthread+0x18d/0x1d0
       ? kthread+0xdb/0x1d0
       ? __pfx_kthread+0x10/0x10
       ret_from_fork+0x34/0x60
       ? __pfx_kthread+0x10/0x10
       ret_from_fork_asm+0x1b/0x30
       </TASK>
    
    Fixes: 8ce79ec359ad ("cifs: update multiplex loop to handle compounded responses")
    Cc: stable@vger.kernel.org
    Reported-by: Robert Morris <rtm@csail.mit.edu>
    Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

smb: client: fix OOB in SMB2_query_info_init() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Wed Dec 13 12:25:57 2023 -0300

    smb: client: fix OOB in SMB2_query_info_init()
    
    commit 33eae65c6f49770fec7a662935d4eb4a6406d24b upstream.
    
    A small CIFS buffer (448 bytes) isn't big enough to hold
    SMB2_QUERY_INFO request along with user's input data from
    CIFS_QUERY_INFO ioctl.  That is, if the user passed an input buffer >
    344 bytes, the client will memcpy() off the end of @req->Buffer in
    SMB2_query_info_init() thus causing the following KASAN splat:
    
      BUG: KASAN: slab-out-of-bounds in SMB2_query_info_init+0x242/0x250 [cifs]
      Write of size 1023 at addr ffff88801308c5a8 by task a.out/1240
    
      CPU: 1 PID: 1240 Comm: a.out Not tainted 6.7.0-rc4 #5
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
      rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x4a/0x80
       print_report+0xcf/0x650
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __phys_addr+0x46/0x90
       kasan_report+0xd8/0x110
       ? SMB2_query_info_init+0x242/0x250 [cifs]
       ? SMB2_query_info_init+0x242/0x250 [cifs]
       kasan_check_range+0x105/0x1b0
       __asan_memcpy+0x3c/0x60
       SMB2_query_info_init+0x242/0x250 [cifs]
       ? __pfx_SMB2_query_info_init+0x10/0x10 [cifs]
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? smb_rqst_len+0xa6/0xc0 [cifs]
       smb2_ioctl_query_info+0x4f4/0x9a0 [cifs]
       ? __pfx_smb2_ioctl_query_info+0x10/0x10 [cifs]
       ? __pfx_cifsConvertToUTF16+0x10/0x10 [cifs]
       ? kasan_set_track+0x25/0x30
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __kasan_kmalloc+0x8f/0xa0
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? cifs_strndup_to_utf16+0x12d/0x1a0 [cifs]
       ? __build_path_from_dentry_optional_prefix+0x19d/0x2d0 [cifs]
       ? __pfx_smb2_ioctl_query_info+0x10/0x10 [cifs]
       cifs_ioctl+0x11c7/0x1de0 [cifs]
       ? __pfx_cifs_ioctl+0x10/0x10 [cifs]
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? rcu_is_watching+0x23/0x50
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __rseq_handle_notify_resume+0x6cd/0x850
       ? __pfx___schedule+0x10/0x10
       ? blkcg_iostat_update+0x250/0x290
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? ksys_write+0xe9/0x170
       __x64_sys_ioctl+0xc9/0x100
       do_syscall_64+0x47/0xf0
       entry_SYSCALL_64_after_hwframe+0x6f/0x77
      RIP: 0033:0x7f893dde49cf
      Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48
      89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89>
      c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
      RSP: 002b:00007ffc03ff4160 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00007ffc03ff4378 RCX: 00007f893dde49cf
      RDX: 00007ffc03ff41d0 RSI: 00000000c018cf07 RDI: 0000000000000003
      RBP: 00007ffc03ff4260 R08: 0000000000000410 R09: 0000000000000001
      R10: 00007f893dce7300 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007ffc03ff4388 R14: 00007f893df15000 R15: 0000000000406de0
       </TASK>
    
    Fix this by increasing size of SMB2_QUERY_INFO request buffers and
    validating input length to prevent other callers from overflowing @req
    in SMB2_query_info_init() as well.
    
    Fixes: f5b05d622a3e ("cifs: add IOCTL for QUERY_INFO passthrough to userspace")
    Cc: stable@vger.kernel.org
    Reported-by: Robert Morris <rtm@csail.mit.edu>
    Signed-off-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

smb: client: fix OOB in smbCalcSize() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Fri Dec 15 19:59:14 2023 -0300

    smb: client: fix OOB in smbCalcSize()
    
    commit b35858b3786ddbb56e1c35138ba25d6adf8d0bef upstream.
    
    Validate @smb->WordCount to avoid reading off the end of @smb and thus
    causing the following KASAN splat:
    
      BUG: KASAN: slab-out-of-bounds in smbCalcSize+0x32/0x40 [cifs]
      Read of size 2 at addr ffff88801c024ec5 by task cifsd/1328
    
      CPU: 1 PID: 1328 Comm: cifsd Not tainted 6.7.0-rc5 #9
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
      rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x4a/0x80
       print_report+0xcf/0x650
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __phys_addr+0x46/0x90
       kasan_report+0xd8/0x110
       ? smbCalcSize+0x32/0x40 [cifs]
       ? smbCalcSize+0x32/0x40 [cifs]
       kasan_check_range+0x105/0x1b0
       smbCalcSize+0x32/0x40 [cifs]
       checkSMB+0x162/0x370 [cifs]
       ? __pfx_checkSMB+0x10/0x10 [cifs]
       cifs_handle_standard+0xbc/0x2f0 [cifs]
       ? srso_alias_return_thunk+0x5/0xfbef5
       cifs_demultiplex_thread+0xed1/0x1360 [cifs]
       ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? lockdep_hardirqs_on_prepare+0x136/0x210
       ? __pfx_lock_release+0x10/0x10
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? mark_held_locks+0x1a/0x90
       ? lockdep_hardirqs_on_prepare+0x136/0x210
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __kthread_parkme+0xce/0xf0
       ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]
       kthread+0x18d/0x1d0
       ? kthread+0xdb/0x1d0
       ? __pfx_kthread+0x10/0x10
       ret_from_fork+0x34/0x60
       ? __pfx_kthread+0x10/0x10
       ret_from_fork_asm+0x1b/0x30
       </TASK>
    
    This fixes CVE-2023-6606.
    
    Reported-by: j51569436@gmail.com
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218218
    Cc: stable@vger.kernel.org
    Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

smb: client: fix potential OOB in cifs_dump_detail() [+ + +]
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Sat Dec 16 01:10:04 2023 -0300

    smb: client: fix potential OOB in cifs_dump_detail()
    
    commit b50492b05fd02887b46aef079592207fb5c97a4c upstream.
    
    Validate SMB message with ->check_message() before calling
    ->calc_smb_size().
    
    Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
spi: atmel: Do not cancel a transfer upon any signal [+ + +]
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Mon Nov 27 10:58:41 2023 +0100

    spi: atmel: Do not cancel a transfer upon any signal
    
    commit 1ca2761a7734928ffe0678f88789266cf3d05362 upstream.
    
    The intended move from wait_for_completion_*() to
    wait_for_completion_interruptible_*() was to allow (very) long spi memory
    transfers to be stopped upon user request instead of freezing the
    machine forever as the timeout value could now be significantly bigger.
    
    However, depending on the user logic, applications can receive many
    signals for their own "internal" purpose and have nothing to do with the
    requested kernel operations, hence interrupting spi transfers upon any
    signal is probably not a wise choice. Instead, let's switch to
    wait_for_completion_killable_*() to only catch the "important"
    signals. This was likely the intended behavior anyway.
    
    Fixes: e0205d6203c2 ("spi: atmel: Prevent false timeouts on long transfers")
    Cc: stable@vger.kernel.org
    Reported-by: Ronald Wahl <ronald.wahl@raritan.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20231127095842.389631-1-miquel.raynal@bootlin.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: atmel: Fix clock issue when using devices with different polarities [+ + +]
Author: Louis Chauvet <louis.chauvet@bootlin.com>
Date:   Mon Dec 4 16:49:03 2023 +0100

    spi: atmel: Fix clock issue when using devices with different polarities
    
    commit fc70d643a2f6678cbe0f5c86433c1aeb4d613fcc upstream.
    
    The current Atmel SPI controller driver (v2) behaves incorrectly when
    using two SPI devices with different clock polarities and GPIO CS.
    
    When switching from one device to another, the controller driver first
    enables the CS and then applies whatever configuration suits the targeted
    device (typically, the polarities). The side effect of such order is the
    apparition of a spurious clock edge after enabling the CS when the clock
    polarity needs to be inverted wrt. the previous configuration of the
    controller.
    
    This parasitic clock edge is problematic when the SPI device uses that edge
    for internal processing, which is perfectly legitimate given that its CS
    was asserted. Indeed, devices such as HVS8080 driven by driver gpio-sr in
    the kernel are shift registers and will process this first clock edge to
    perform a first register shift. In this case, the first bit gets lost and
    the whole data block that will later be read by the kernel is all shifted
    by one.
    
        Current behavior:
          The actual switching of the clock polarity only occurs after the CS
          when the controller sends the first message:
    
        CLK ------------\   /-\ /-\
                        |   | | | |    . . .
                        \---/ \-/ \
        CS  -----\
                 |
                 \------------------
    
                 ^      ^   ^
                 |      |   |
                 |      |   Actual clock of the message sent
                 |      |
                 |      Change of clock polarity, which occurs with the first
                 |      write to the bus. This edge occurs when the CS is
                 |      already asserted, and can be interpreted as
                 |      the first clock edge by the receiver.
                 |
                 GPIO CS toggle
    
    This issue is specific to this controller because while the SPI core
    performs the operations in the right order, the controller however does
    not. In practice, the controller only applies the clock configuration right
    before the first transmission.
    
    So this is not a problem when using the controller's dedicated CS, as the
    controller does things correctly, but it becomes a problem when you need to
    change the clock polarity and use an external GPIO for the CS.
    
    One possible approach to solve this problem is to send a dummy message
    before actually activating the CS, so that the controller applies the clock
    polarity beforehand.
    
    New behavior:
    
    CLK     ------\      /-\     /-\      /-\     /-\
                  |      | | ... | |      | | ... | |
                  \------/ \-   -/ \------/ \-   -/ \------
    
    CS      -\/-----------------------\
             ||                       |
             \/                       \---------------------
             ^    ^       ^           ^    ^
             |    |       |           |    |
             |    |       |           |    Expected clock cycles when
             |    |       |           |    sending the message
             |    |       |           |
             |    |       |           Actual GPIO CS activation, occurs inside
             |    |       |           the driver
             |    |       |
             |    |       Dummy message, to trigger clock polarity
             |    |       reconfiguration. This message is not received and
             |    |       processed by the device because CS is low.
             |    |
             |    Change of clock polarity, forced by the dummy message. This
             |    time, the edge is not detected by the receiver.
             |
             This small spike in CS activation is due to the fact that the
             spi-core activates the CS gpio before calling the driver's
             set_cs callback, which deactivates this gpio again until the
             clock polarity is correct.
    
    To avoid having to systematically send a dummy packet, the driver keeps
    track of the clock's current polarity. In this way, it only sends the dummy
    packet when necessary, ensuring that the clock will have the correct
    polarity when the CS is toggled.
    
    There could be two hardware problems with this patch:
    1- Maybe the small CS activation peak can confuse SPI devices
    2- If on a design, a single wire is used to select two devices depending
    on its state, the dummy message may disturb them.
    
    Fixes: 5ee36c989831 ("spi: atmel_spi update chipselect handling")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
    Link: https://msgid.link/r/20231204154903.11607-1-louis.chauvet@bootlin.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: atmel: Prevent spi transfers from being killed [+ + +]
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Tue Dec 5 09:31:02 2023 +0100

    spi: atmel: Prevent spi transfers from being killed
    
    commit 890188d2d7e4ac6c131ba166ca116cb315e752ee upstream.
    
    Upstream commit e0205d6203c2 ("spi: atmel: Prevent false timeouts on
    long transfers") has tried to mitigate the problem of getting spi
    transfers canceled because they were lasting too long. On slow buses,
    transfers in the MiB range can take more than one second and thus a
    calculation was added to progressively increment the timeout value. In
    order to not be too problematic from a user point of view (waiting dozen
    of seconds or even minutes), the wait call was turned interruptible.
    
    Turning the wait interruptible was a mistake as what we really wanted to
    do was to be able to kill a transfer. Any signal interrupting our
    transfer would not be suitable at all so a second attempt was made at
    turning the wait killable instead.
    
    Link: https://lore.kernel.org/linux-spi/20231127095842.389631-1-miquel.raynal@bootlin.com/
    
    All being well, it was reported that JFFS2 was showing a splat when
    interrupting a transfer. After some more debate about whether JFFS2
    should be fixed and how, it was also pointed out that the whole
    consistency of the filesystem in case of parallel I/O would be
    compromised. Changing JFFS2 behavior would in theory be possible but
    nobody has the energy and time and knowledge to do this now, so better
    prevent spi transfers to be interrupted by the user.
    
    Partially revert the blamed commit to no longer use the interruptible
    nor the killable variant of wait_for_completion().
    
    Fixes: e0205d6203c2 ("spi: atmel: Prevent false timeouts on long transfers")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Tested-by: Ronald Wahl <ronald.wahl@raritan.com>
    Link: https://lore.kernel.org/r/20231205083102.16946-1-miquel.raynal@bootlin.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: cadence: revert "Add SPI transfer delays" [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Wed Dec 6 15:52:33 2023 +0100

    spi: cadence: revert "Add SPI transfer delays"
    
    commit 7a733e060bd20edb63b1f27f0b29cf9b184e0e8b upstream.
    
    The commit 855a40cd8ccc ("spi: cadence: Add SPI transfer delays") adds a
    delay after each transfer into the driver's transfer_one(). However,
    the delay is already done in SPI core. So this commit unnecessarily
    doubles the delay amount. Revert this commit.
    
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Link: https://lore.kernel.org/r/20231206145233.74982-1-namcao@linutronix.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: spi-imx: correctly configure burst length when using dma [+ + +]
Author: Benjamin Bigler <benjamin@bigler.one>
Date:   Sat Dec 9 23:23:26 2023 +0100

    spi: spi-imx: correctly configure burst length when using dma
    
    [ Upstream commit e9b220aeacf109684cce36a94fc24ed37be92b05 ]
    
    If DMA is used, burst length should be set to the bus width of the DMA.
    Otherwise, the SPI hardware will transmit/receive one word per DMA
    request.
    Since this issue affects both transmission and reception, it cannot be
    detected with a loopback test.
    Replace magic numbers 512 and 0xfff with MX51_ECSPI_CTRL_MAX_BURST.
    
    Reported-by Stefan Bigler <linux@bigler.io>
    
    Signed-off-by: Benjamin Bigler <benjamin@bigler.one>
    Fixes: 15a6af94a277 ("spi: Increase imx51 ecspi burst length based on transfer length")
    Link: https://lore.kernel.org/r/8a415902c751cdbb4b20ce76569216ed@mail.infomaniak.com
    Link: https://lore.kernel.org/r/20231209222338.5564-1-benjamin@bigler.one
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
SUNRPC: Revert 5f7fc5d69f6e92ec0b38774c387f5cf7812c5806 [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Dec 18 17:05:40 2023 -0500

    SUNRPC: Revert 5f7fc5d69f6e92ec0b38774c387f5cf7812c5806
    
    [ Upstream commit bd018b98ba84ca0c80abac1ef23ce726a809e58c ]
    
    Guillaume says:
    > I believe commit 5f7fc5d69f6e ("SUNRPC: Resupply rq_pages from
    > node-local memory") in Linux 6.5+ is incorrect. It passes
    > unconditionally rq_pool->sp_id as the NUMA node.
    >
    > While the comment in the svc_pool declaration in sunrpc/svc.h says
    > that sp_id is also the NUMA node id, it might not be the case if
    > the svc is created using svc_create_pooled(). svc_created_pooled()
    > can use the per-cpu pool mode therefore in this case sp_id would
    > be the cpu id.
    
    Fix this by reverting now. At a later point this minor optimization,
    and the deceptive labeling of the sp_id field, can be revisited.
    
    Reported-by: Guillaume Morin <guillaume@morinfr.org>
    Closes: https://lore.kernel.org/linux-nfs/ZYC9rsno8qYggVt9@bender.morinfr.org/T/#u
    Fixes: 5f7fc5d69f6e ("SUNRPC: Resupply rq_pages from node-local memory")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thunderbolt: Fix memory leak in margining_port_remove() [+ + +]
Author: Yaxiong Tian <tianyaxiong@kylinos.cn>
Date:   Wed Nov 22 16:02:43 2023 +0800

    thunderbolt: Fix memory leak in margining_port_remove()
    
    commit ac43c9122e4287bbdbe91e980fc2528acb72cc1e upstream.
    
    The dentry returned by debugfs_lookup() needs to be released by calling
    dput() which is missing in margining_port_remove(). Fix this by calling
    debugfs_lookup_and_remove() that combines both and avoids the memory leak.
    
    Fixes: d0f1e0c2a699 ("thunderbolt: Add support for receiver lane margining")
    Cc: stable@vger.kernel.org
    Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing / synthetic: Disable events after testing in synth_event_gen_test_init() [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Wed Dec 20 11:15:25 2023 -0500

    tracing / synthetic: Disable events after testing in synth_event_gen_test_init()
    
    commit 88b30c7f5d27e1594d70dc2bd7199b18f2b57fa9 upstream.
    
    The synth_event_gen_test module can be built in, if someone wants to run
    the tests at boot up and not have to load them.
    
    The synth_event_gen_test_init() function creates and enables the synthetic
    events and runs its tests.
    
    The synth_event_gen_test_exit() disables the events it created and
    destroys the events.
    
    If the module is builtin, the events are never disabled. The issue is, the
    events should be disable after the tests are run. This could be an issue
    if the rest of the boot up tests are enabled, as they expect the events to
    be in a known state before testing. That known state happens to be
    disabled.
    
    When CONFIG_SYNTH_EVENT_GEN_TEST=y and CONFIG_EVENT_TRACE_STARTUP_TEST=y
    a warning will trigger:
    
     Running tests on trace events:
     Testing event create_synth_test:
     Enabled event during self test!
     ------------[ cut here ]------------
     WARNING: CPU: 2 PID: 1 at kernel/trace/trace_events.c:4150 event_trace_self_tests+0x1c2/0x480
     Modules linked in:
     CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-test-00031-gb803d7c664d5-dirty #276
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
     RIP: 0010:event_trace_self_tests+0x1c2/0x480
     Code: bb e8 a2 ab 5d fc 48 8d 7b 48 e8 f9 3d 99 fc 48 8b 73 48 40 f6 c6 01 0f 84 d6 fe ff ff 48 c7 c7 20 b6 ad bb e8 7f ab 5d fc 90 <0f> 0b 90 48 89 df e8 d3 3d 99 fc 48 8b 1b 4c 39 f3 0f 85 2c ff ff
     RSP: 0000:ffffc9000001fdc0 EFLAGS: 00010246
     RAX: 0000000000000029 RBX: ffff88810399ca80 RCX: 0000000000000000
     RDX: 0000000000000000 RSI: ffffffffb9f19478 RDI: ffff88823c734e64
     RBP: ffff88810399f300 R08: 0000000000000000 R09: fffffbfff79eb32a
     R10: ffffffffbcf59957 R11: 0000000000000001 R12: ffff888104068090
     R13: ffffffffbc89f0a0 R14: ffffffffbc8a0f08 R15: 0000000000000078
     FS:  0000000000000000(0000) GS:ffff88823c700000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 00000001f6282001 CR4: 0000000000170ef0
     Call Trace:
      <TASK>
      ? __warn+0xa5/0x200
      ? event_trace_self_tests+0x1c2/0x480
      ? report_bug+0x1f6/0x220
      ? handle_bug+0x6f/0x90
      ? exc_invalid_op+0x17/0x50
      ? asm_exc_invalid_op+0x1a/0x20
      ? tracer_preempt_on+0x78/0x1c0
      ? event_trace_self_tests+0x1c2/0x480
      ? __pfx_event_trace_self_tests_init+0x10/0x10
      event_trace_self_tests_init+0x27/0xe0
      do_one_initcall+0xd6/0x3c0
      ? __pfx_do_one_initcall+0x10/0x10
      ? kasan_set_track+0x25/0x30
      ? rcu_is_watching+0x38/0x60
      kernel_init_freeable+0x324/0x450
      ? __pfx_kernel_init+0x10/0x10
      kernel_init+0x1f/0x1e0
      ? _raw_spin_unlock_irq+0x33/0x50
      ret_from_fork+0x34/0x60
      ? __pfx_kernel_init+0x10/0x10
      ret_from_fork_asm+0x1b/0x30
      </TASK>
    
    This is because the synth_event_gen_test_init() left the synthetic events
    that it created enabled. By having it disable them after testing, the
    other selftests will run fine.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231220111525.2f0f49b0@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Tom Zanussi <zanussi@kernel.org>
    Fixes: 9fe41efaca084 ("tracing: Add synth event generation test module")
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Reported-by: Alexander Graf <graf@amazon.com>
    Tested-by: Alexander Graf <graf@amazon.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb-storage: Add quirk for incorrect WP on Kingston DT Ultimate 3.0 G3 [+ + +]
Author: Tasos Sahanidis <tasos@tasossah.com>
Date:   Thu Dec 7 15:44:41 2023 +0200

    usb-storage: Add quirk for incorrect WP on Kingston DT Ultimate 3.0 G3
    
    commit 772685c14743ad565bb271041ad3c262298cd6fc upstream.
    
    This flash drive reports write protect during the first mode sense.
    
    In the past this was not an issue as the kernel called revalidate twice,
    thus asking the device for its write protect status twice, with write
    protect being disabled in the second mode sense.
    
    However, since commit 1e029397d12f ("scsi: sd: Reorganize DIF/DIX code to
    avoid calling revalidate twice") that is no longer the case, thus the
    device shows up read only.
    
    [490891.289495] sd 12:0:0:0: [sdl] Write Protect is on
    [490891.289497] sd 12:0:0:0: [sdl] Mode Sense: 2b 00 80 08
    
    This does not appear to be a timing issue, as enabling the usbcore quirk
    USB_QUIRK_DELAY_INIT has no effect on write protect.
    
    Fixes: 1e029397d12f ("scsi: sd: Reorganize DIF/DIX code to avoid calling revalidate twice")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Link: https://lore.kernel.org/r/20231207134441.298131-1-tasos@tasossah.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: fotg210-hcd: delete an incorrect bounds test [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Dec 13 16:22:43 2023 +0300

    usb: fotg210-hcd: delete an incorrect bounds test
    
    commit 7fbcd195e2b8cc952e4aeaeb50867b798040314c upstream.
    
    Here "temp" is the number of characters that we have written and "size"
    is the size of the buffer.  The intent was clearly to say that if we have
    written to the end of the buffer then stop.
    
    However, for that to work the comparison should have been done on the
    original "size" value instead of the "size -= temp" value.  Not only
    will that not trigger when we want to, but there is a small chance that
    it will trigger incorrectly before we want it to and we break from the
    loop slightly earlier than intended.
    
    This code was recently changed from using snprintf() to scnprintf().  With
    snprintf() we likely would have continued looping and passed a negative
    size parameter to snprintf().  This would have triggered an annoying
    WARN().  Now that we have converted to scnprintf() "size" will never
    drop below 1 and there is no real need for this test.  We could change
    the condition to "if (temp <= 1) goto done;" but just deleting the test
    is cleanest.
    
    Fixes: 7d50195f6c50 ("usb: host: Faraday fotg210-hcd driver")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Lee Jones <lee@kernel.org>
    Link: https://lore.kernel.org/r/ZXmwIwHe35wGfgzu@suswa
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: ftdi_sio: update Actisense PIDs constant names [+ + +]
Author: Mark Glover <mark.glover@actisense.com>
Date:   Wed Dec 20 13:57:40 2023 +0000

    USB: serial: ftdi_sio: update Actisense PIDs constant names
    
    commit 513d88a88e0203188a38f4647dd08170aebd85df upstream.
    
    Update the constant names for unused USB PIDs (product identifiers) to
    reflect the new products now using the PIDs.
    
    Signed-off-by: Mark Glover <mark.glover@actisense.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Foxconn T99W265 with new baseline [+ + +]
Author: Slark Xiao <slark_xiao@163.com>
Date:   Fri Dec 1 10:09:50 2023 +0800

    USB: serial: option: add Foxconn T99W265 with new baseline
    
    commit 13fde9ac23ca8c6d1ac13cc9eefe1f1ac3ee30a4 upstream.
    
    This ID was added based on latest SDX12 code base line, and we
    made some changes with previous 0489:e0db.
    
    Test evidence as below:
    T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  2
    P:  Vendor=0489 ProdID=e0da Rev=05.04
    S:  Manufacturer=Qualcomm
    S:  Product=Qualcomm Snapdragon X12
    S:  SerialNumber=2bda65fb
    C:  #Ifs= 6 Cfg#= 2 Atr=a0 MxPwr=896mA
    I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    I:  If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    I:  If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    
    0&1: MBIM, 2: Modem, 3:GNSS, 4:Diag, 5:ADB
    
    Signed-off-by: Slark Xiao <slark_xiao@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EG912Y module support [+ + +]
Author: Alper Ak <alperyasinak1@gmail.com>
Date:   Tue Aug 8 13:51:58 2023 +0300

    USB: serial: option: add Quectel EG912Y module support
    
    commit 6d79d9434c69bb8ffa8a631050eb0ad6b83d3e90 upstream.
    
    Add Quectel EG912Y "DIAG, AT, MODEM"
    
    0x6001: ECM / RNDIS + DIAG + AT + MODEM
    
    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=6001 Rev= 3.18
    S:  Manufacturer=Android
    S:  Product=Android
    S:  SerialNumber=0000
    C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
    E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=4096ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Alper Ak <alperyasinak1@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel RM500Q R13 firmware support [+ + +]
Author: Reinhard Speyerer <rspmn@arcor.de>
Date:   Tue Dec 12 18:15:38 2023 +0100

    USB: serial: option: add Quectel RM500Q R13 firmware support
    
    commit 06f22cd6635bdae7d73566fca9879b2026a08e00 upstream.
    
    Add support for Quectel RM500Q R13 firmware which uses Prot=40 for the
    NMEA port:
    
    T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  8 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0800 Rev= 4.14
    S:  Manufacturer=Quectel
    S:  Product=RM500Q-AE
    S:  SerialNumber=xxxxxxxx
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=88(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: Reinhard Speyerer <rspmn@arcor.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: typec: ucsi: fix gpio-based orientation detection [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Dec 8 13:36:02 2023 +0100

    usb: typec: ucsi: fix gpio-based orientation detection
    
    commit c994cb596bf7ef5928f06331c76f46e071b16f09 upstream.
    
    Fix the recently added connector sanity check which was off by one and
    prevented orientation notifications from being handled correctly for the
    second port when using GPIOs to determine orientation.
    
    Fixes: c6165ed2f425 ("usb: ucsi: glink: use the connector orientation GPIO to provide switch events")
    Cc: stable <stable@kernel.org>
    Cc: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20231208123603.29957-1-johan+linaro@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: cfg80211: Add my certificate [+ + +]
Author: Chen-Yu Tsai <wens@kernel.org>
Date:   Thu Dec 7 21:20:50 2023 +0800

    wifi: cfg80211: Add my certificate
    
    commit fb768d3b13ffa325b7e84480d488ac799c9d2cd7 upstream.
    
    As announced [1][2], I have taken over maintainership of the
    wireless-regdb project.
    
    Add my certificate so that newer releases are valid to the kernel.
    Seth's certificate should be kept around for awhile, at least until
    a few new releases by me happen.
    
    This should also be applied to stable trees so that stable kernels
    can utilize newly released database binaries.
    
    [1] https://lore.kernel.org/linux-wireless/CAGb2v657baNMPKU3QADijx7hZa=GUcSv2LEDdn6N=QQaFX8r-g@mail.gmail.com/
    [2] https://lore.kernel.org/linux-wireless/ZWmRR5ul7EDfxCan@wens.tw/
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
    Acked-by: Seth Forshee <sforshee@kernel.org>
    Link: https://msgid.link/ZXHGsqs34qZyzZng@wens.tw
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: cfg80211: fix certs build to not depend on file order [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Dec 14 09:08:16 2023 +0100

    wifi: cfg80211: fix certs build to not depend on file order
    
    commit 3c2a8ebe3fe66a5f77d4c164a0bea8e2ff37b455 upstream.
    
    The file for the new certificate (Chen-Yu Tsai's) didn't
    end with a comma, so depending on the file order in the
    build rule, we'd end up with invalid C when concatenating
    the (now two) certificates. Fix that.
    
    Cc: stable@vger.kernel.org
    Reported-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Fixes: fb768d3b13ff ("wifi: cfg80211: Add my certificate")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: ieee80211: don't require protected vendor action frames [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Dec 6 22:37:57 2023 +0100

    wifi: ieee80211: don't require protected vendor action frames
    
    [ Upstream commit 98fb9b9680c9f3895ced02d6a73e27f5d7b5892b ]
    
    For vendor action frames, whether a protected one should be
    used or not is clearly up to the individual vendor and frame,
    so even though a protected dual is defined, it may not get
    used. Thus, don't require protection for vendor action frames
    when they're used in a connection.
    
    Since we obviously don't process frames unknown to the kernel
    in the kernel, it may makes sense to invert this list to have
    all the ones the kernel processes and knows to be requiring
    protection, but that'd be a different change.
    
    Fixes: 91535613b609 ("wifi: mac80211: don't drop all unprotected public action frames")
    Reported-by: Jouni Malinen <j@w1.fi>
    Link: https://msgid.link/20231206223801.f6a2cf4e67ec.Ifa6acc774bd67801d3dafb405278f297683187aa@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: pcie: add another missing bh-disable for rxq->lock [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Dec 8 18:32:02 2023 +0200

    wifi: iwlwifi: pcie: add another missing bh-disable for rxq->lock
    
    [ Upstream commit a4754182dc936b97ec7e9f6b08cdf7ed97ef9069 ]
    
    Evidently I had only looked at all the ones in rx.c, and missed this.
    Add bh-disable to this use of the rxq->lock as well.
    
    Fixes: 25edc8f259c7 ("iwlwifi: pcie: properly implement NAPI")
    Reported-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20231208183100.e79ad3dae649.I8f19713c4383707f8be7fc20ff5cc1ecf12429bb@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: check defragmentation succeeded [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Dec 11 09:05:30 2023 +0200

    wifi: mac80211: check defragmentation succeeded
    
    [ Upstream commit 98849ba2aa9db46e62720fb686a9d63ed9887806 ]
    
    We need to check that cfg80211_defragment_element()
    didn't return an error, since it can fail due to bad
    input, and we didn't catch that before.
    
    Fixes: 8eb8dd2ffbbb ("wifi: mac80211: Support link removal using Reconfiguration ML element")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20231211085121.8595a6b67fc0.I1225edd8f98355e007f96502e358e476c7971d8c@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: check if the existing link config remains unchanged [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Wed Nov 29 20:17:47 2023 +0800

    wifi: mac80211: check if the existing link config remains unchanged
    
    [ Upstream commit c1393c132b906fbdf91f6d1c9eb2ef7a00cce64e ]
    
    [Syz report]
    WARNING: CPU: 1 PID: 5067 at net/mac80211/rate.c:48 rate_control_rate_init+0x540/0x690 net/mac80211/rate.c:48
    Modules linked in:
    CPU: 1 PID: 5067 Comm: syz-executor413 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
    RIP: 0010:rate_control_rate_init+0x540/0x690 net/mac80211/rate.c:48
    Code: 48 c7 c2 00 46 0c 8c be 08 03 00 00 48 c7 c7 c0 45 0c 8c c6 05 70 79 0b 05 01 e8 1b a0 6f f7 e9 e0 fd ff ff e8 61 b3 8f f7 90 <0f> 0b 90 e9 36 ff ff ff e8 53 b3 8f f7 e8 5e 0b 78 f7 31 ff 89 c3
    RSP: 0018:ffffc90003c57248 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: ffff888016bc4000 RCX: ffffffff89f7d519
    RDX: ffff888076d43b80 RSI: ffffffff89f7d6df RDI: 0000000000000005
    RBP: ffff88801daaae20 R08: 0000000000000005 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000002 R12: 0000000000000001
    R13: 0000000000000000 R14: ffff888020030e20 R15: ffff888078f08000
    FS:  0000555556b94380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000005fdeb8 CR3: 0000000076d22000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     sta_apply_auth_flags.constprop.0+0x4b7/0x510 net/mac80211/cfg.c:1674
     sta_apply_parameters+0xaf1/0x16c0 net/mac80211/cfg.c:2002
     ieee80211_add_station+0x3fa/0x6c0 net/mac80211/cfg.c:2068
     rdev_add_station net/wireless/rdev-ops.h:201 [inline]
     nl80211_new_station+0x13ba/0x1a70 net/wireless/nl80211.c:7603
     genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
     genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
     genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
     netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2545
     genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
     netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
     netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1368
     netlink_sendmsg+0x93c/0xe40 net/netlink/af_netlink.c:1910
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0xd5/0x180 net/socket.c:745
     ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
     ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
     __sys_sendmsg+0x117/0x1e0 net/socket.c:2667
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    [Analysis]
    It is inappropriate to make a link configuration change judgment on an
    non-existent and non new link.
    
    [Fix]
    Quickly exit when there is a existent link and the link configuration has not
    changed.
    
    Fixes: b303835dabe0 ("wifi: mac80211: accept STA changes without link changes")
    Reported-and-tested-by: syzbot+62d7eef57b09bfebcd84@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Link: https://msgid.link/tencent_DE67FF86DB92ED465489A36ECD2EDDCC8C06@qq.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: don't re-add debugfs during reconfig [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Dec 11 09:05:19 2023 +0200

    wifi: mac80211: don't re-add debugfs during reconfig
    
    [ Upstream commit 63bafd9d5421959b2124dd940ed8d7462d99f449 ]
    
    If we're doing reconfig, then we cannot add the debugfs
    files that are already there from before the reconfig.
    Skip that in drv_change_sta_links() during reconfig.
    
    Fixes: d2caad527c19 ("wifi: mac80211: add API to show the link STAs in debugfs")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
    Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20231211085121.88a950f43e16.Id71181780994649219685887c0fcad33d387cc78@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: mesh: check element parsing succeeded [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Dec 11 09:05:32 2023 +0200

    wifi: mac80211: mesh: check element parsing succeeded
    
    [ Upstream commit 1fc4a3eec50d726f4663ad3c0bb0158354d6647a ]
    
    ieee802_11_parse_elems() can return NULL, so we must
    check for the return value.
    
    Fixes: 5d24828d05f3 ("mac80211: always allocate struct ieee802_11_elems")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20231211085121.93dea364f3d3.Ie87781c6c48979fb25a744b90af4a33dc2d83a28@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: mesh_plink: fix matches_local logic [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Dec 11 09:05:31 2023 +0200

    wifi: mac80211: mesh_plink: fix matches_local logic
    
    [ Upstream commit 8c386b166e2517cf3a123018e77941ec22625d0f ]
    
    During refactoring the "else" here got lost, add it back.
    
    Fixes: c99a89edb106 ("mac80211: factor out plink event gathering")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20231211085121.795480fa0e0b.I017d501196a5bbdcd9afd33338d342d6fe1edd79@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mt76: fix crash with WED rx support enabled [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Fri Dec 8 08:50:04 2023 +0100

    wifi: mt76: fix crash with WED rx support enabled
    
    commit cd607f2cbbbec90682b2f6d6b85e1525d0f43b19 upstream.
    
    If WED rx is enabled, rx buffers are added to a buffer pool that can be
    filled from multiple page pools. Because buffers freed from rx poll are
    not guaranteed to belong to the processed queue's page pool, lockless
    caching must not be used in this case.
    
    Cc: stable@vger.kernel.org
    Fixes: 2f5c3c77fc9b ("wifi: mt76: switch to page_pool allocator")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20231208075004.69843-1-nbd@nbd.name
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/alternatives: Disable interrupts and sync when optimizing NOPs in place [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Dec 7 20:49:26 2023 +0100

    x86/alternatives: Disable interrupts and sync when optimizing NOPs in place
    
    commit 2dc4196138055eb0340231aecac4d78c2ec2bea5 upstream.
    
    apply_alternatives() treats alternatives with the ALT_FLAG_NOT flag set
    special as it optimizes the existing NOPs in place.
    
    Unfortunately, this happens with interrupts enabled and does not provide any
    form of core synchronization.
    
    So an interrupt hitting in the middle of the update and using the affected code
    path will observe a half updated NOP and crash and burn. The following
    3 NOP sequence was observed to expose this crash halfway reliably under QEMU
      32bit:
    
       0x90 0x90 0x90
    
    which is replaced by the optimized 3 byte NOP:
    
       0x8d 0x76 0x00
    
    So an interrupt can observe:
    
       1) 0x90 0x90 0x90            nop nop nop
       2) 0x8d 0x90 0x90            undefined
       3) 0x8d 0x76 0x90            lea    -0x70(%esi),%esi
       4) 0x8d 0x76 0x00            lea     0x0(%esi),%esi
    
    Where only #1 and #4 are true NOPs. The same problem exists for 64bit obviously.
    
    Disable interrupts around this NOP optimization and invoke sync_core()
    before re-enabling them.
    
    Fixes: 270a69c4485d ("x86/alternative: Support relocations in alternatives")
    Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/ZT6narvE%2BLxX%2B7Be@windriver.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/alternatives: Sync core before enabling interrupts [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Thu Dec 7 20:49:24 2023 +0100

    x86/alternatives: Sync core before enabling interrupts
    
    commit 3ea1704a92967834bf0e64ca1205db4680d04048 upstream.
    
    text_poke_early() does:
    
       local_irq_save(flags);
       memcpy(addr, opcode, len);
       local_irq_restore(flags);
       sync_core();
    
    That's not really correct because the synchronization should happen before
    interrupts are re-enabled to ensure that a pending interrupt observes the
    complete update of the opcodes.
    
    It's not entirely clear whether the interrupt entry provides enough
    serialization already, but moving the sync_core() invocation into interrupt
    disabled region does no harm and is obviously correct.
    
    Fixes: 6fffacb30349 ("x86/alternatives, jumplabel: Use text_poke_early() before mm_init()")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/ZT6narvE%2BLxX%2B7Be@windriver.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/smpboot/64: Handle X2APIC BIOS inconsistency gracefully [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Dec 15 09:58:58 2023 +0100

    x86/smpboot/64: Handle X2APIC BIOS inconsistency gracefully
    
    commit 69a7386c1ec25476a0c78ffeb59de08a2a08f495 upstream.
    
    Chris reported that a Dell PowerEdge T340 system stopped to boot when upgrading
    to a kernel which contains the parallel hotplug changes.  Disabling parallel
    hotplug on the kernel command line makes it boot again.
    
    It turns out that the Dell BIOS has x2APIC enabled and the boot CPU comes up in
    X2APIC mode, but the APs come up inconsistently in xAPIC mode.
    
    Parallel hotplug requires that the upcoming CPU reads out its APIC ID from the
    local APIC in order to map it to the Linux CPU number.
    
    In this particular case the readout on the APs uses the MMIO mapped registers
    because the BIOS failed to enable x2APIC mode. That readout results in a page
    fault because the kernel does not have the APIC MMIO space mapped when X2APIC
    mode was enabled by the BIOS on the boot CPU and the kernel switched to X2APIC
    mode early. That page fault can't be handled on the upcoming CPU that early and
    results in a silent boot failure.
    
    If parallel hotplug is disabled the system boots because in that case the APIC
    ID read is not required as the Linux CPU number is provided to the AP in the
    smpboot control word. When the kernel uses x2APIC mode then the APs are
    switched to x2APIC mode too slightly later in the bringup process, but there is
    no reason to do it that late.
    
    Cure the BIOS bogosity by checking in the parallel bootup path whether the
    kernel uses x2APIC mode and if so switching over the APs to x2APIC mode before
    the APIC ID readout.
    
    Fixes: 0c7ffa32dbd6 ("x86/smpboot/64: Implement arch_cpuhp_init_parallel_bringup() and enable it")
    Reported-by: Chris Lindee <chris.lindee@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Ashok Raj <ashok.raj@intel.com>
    Tested-by: Chris Lindee <chris.lindee@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/CA%2B2tU59853R49EaU_tyvOZuOTDdcU0RshGyydccp9R1NX9bEeQ@mail.gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/xen: add CPU dependencies for 32-bit build [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Dec 4 09:47:01 2023 +0100

    x86/xen: add CPU dependencies for 32-bit build
    
    [ Upstream commit 93cd0597649844a0fe7989839a3202735fb3ae67 ]
    
    Xen only supports modern CPUs even when running a 32-bit kernel, and it now
    requires a kernel built for a 64 byte (or larger) cache line:
    
    In file included from <command-line>:
    In function 'xen_vcpu_setup',
        inlined from 'xen_vcpu_setup_restore' at arch/x86/xen/enlighten.c:111:3,
        inlined from 'xen_vcpu_restore' at arch/x86/xen/enlighten.c:141:3:
    include/linux/compiler_types.h:435:45: error: call to '__compiletime_assert_287' declared with attribute error: BUILD_BUG_ON failed: sizeof(*vcpup) > SMP_CACHE_BYTES
    arch/x86/xen/enlighten.c:166:9: note: in expansion of macro 'BUILD_BUG_ON'
      166 |         BUILD_BUG_ON(sizeof(*vcpup) > SMP_CACHE_BYTES);
          |         ^~~~~~~~~~~~
    
    Enforce the dependency with a whitelist of CPU configurations. In normal
    distro kernels, CONFIG_X86_GENERIC is enabled, and this works fine. When this
    is not set, still allow Xen to be built on kernels that target a 64-bit
    capable CPU.
    
    Fixes: db2832309a82 ("x86/xen: fix percpu vcpu_info allocation")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Tested-by: Alyssa Ross <hi@alyssa.is>
    Link: https://lore.kernel.org/r/20231204084722.3789473-1-arnd@kernel.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>