commit 8ee0807eedf3bc60c8a47a7dd95387102bcfd063
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Dec 22 09:18:02 2021 +0100

    Linux 4.14.259
    
    Link: https://lore.kernel.org/r/20211220143022.266532675@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.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>

commit 9bebb2eedf679b3be4acaa20efda97f32c999d74
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Nov 30 08:36:12 2021 +0100

    xen/netback: don't queue unlimited number of packages
    
    commit be81992f9086b230623ae3ebbc85ecee4d00a3d3 upstream.
    
    In case a guest isn't consuming incoming network traffic as fast as it
    is coming in, xen-netback is buffering network packages in unlimited
    numbers today. This can result in host OOM situations.
    
    Commit f48da8b14d04ca8 ("xen-netback: fix unlimited guest Rx internal
    queue and carrier flapping") meant to introduce a mechanism to limit
    the amount of buffered data by stopping the Tx queue when reaching the
    data limit, but this doesn't work for cases like UDP.
    
    When hitting the limit don't queue further SKBs, but drop them instead.
    In order to be able to tell Rx packages have been dropped increment the
    rx_dropped statistics counter in this case.
    
    It should be noted that the old solution to continue queueing SKBs had
    the additional problem of an overflow of the 32-bit rx_queue_len value
    would result in intermittent Tx queue enabling.
    
    This is part of XSA-392
    
    Fixes: f48da8b14d04ca8 ("xen-netback: fix unlimited guest Rx internal queue and carrier flapping")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eae85b8c6e17d3e3888d9159205390e8dbcff6a8
Author: Juergen Gross <jgross@suse.com>
Date:   Thu Dec 16 08:25:12 2021 +0100

    xen/netback: fix rx queue stall detection
    
    commit 6032046ec4b70176d247a71836186d47b25d1684 upstream.
    
    Commit 1d5d48523900a4b ("xen-netback: require fewer guest Rx slots when
    not using GSO") introduced a security problem in netback, as an
    interface would only be regarded to be stalled if no slot is available
    in the rx queue ring page. In case the SKB at the head of the queued
    requests will need more than one rx slot and only one slot is free the
    stall detection logic will never trigger, as the test for that is only
    looking for at least one slot to be free.
    
    Fix that by testing for the needed number of slots instead of only one
    slot being available.
    
    In order to not have to take the rx queue lock that often, store the
    number of needed slots in the queue data. As all SKB dequeue operations
    happen in the rx queue kernel thread this is safe, as long as the
    number of needed slots is accessed via READ/WRITE_ONCE() only and
    updates are always done with the rx queue lock held.
    
    Add a small helper for obtaining the number of free slots.
    
    This is part of XSA-392
    
    Fixes: 1d5d48523900a4b ("xen-netback: require fewer guest Rx slots when not using GSO")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68b78f976ca47d52c03c41eded207a312e46b934
Author: Juergen Gross <jgross@suse.com>
Date:   Thu Dec 16 08:24:08 2021 +0100

    xen/console: harden hvc_xen against event channel storms
    
    commit fe415186b43df0db1f17fa3a46275fd92107fe71 upstream.
    
    The Xen console driver is still vulnerable for an attack via excessive
    number of events sent by the backend. Fix that by using a lateeoi event
    channel.
    
    For the normal domU initial console this requires the introduction of
    bind_evtchn_to_irq_lateeoi() as there is no xenbus device available
    at the time the event channel is bound to the irq.
    
    As the decision whether an interrupt was spurious or not requires to
    test for bytes having been read from the backend, move sending the
    event into the if statement, as sending an event without having found
    any bytes to be read is making no sense at all.
    
    This is part of XSA-391
    
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4bf81386e3d6e5083c93d51eff70260bcec091bb
Author: Juergen Gross <jgross@suse.com>
Date:   Thu Dec 16 08:24:08 2021 +0100

    xen/netfront: harden netfront against event channel storms
    
    commit b27d47950e481f292c0a5ad57357edb9d95d03ba upstream.
    
    The Xen netfront driver is still vulnerable for an attack via excessive
    number of events sent by the backend. Fix that by using lateeoi event
    channels.
    
    For being able to detect the case of no rx responses being added while
    the carrier is down a new lock is needed in order to update and test
    rsp_cons and the number of seen unconsumed responses atomically.
    
    This is part of XSA-391
    
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ac3b68b79c9e964dd6f3cf80ff825518e502b79
Author: Juergen Gross <jgross@suse.com>
Date:   Thu Dec 16 08:24:08 2021 +0100

    xen/blkfront: harden blkfront against event channel storms
    
    commit 0fd08a34e8e3b67ec9bd8287ac0facf8374b844a upstream.
    
    The Xen blkfront driver is still vulnerable for an attack via excessive
    number of events sent by the backend. Fix that by using lateeoi event
    channels.
    
    This is part of XSA-391
    
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 423f6acc3cc18f3528a2077290146c6d651c7be6
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Fri Oct 15 13:13:06 2021 -0700

    Input: touchscreen - avoid bitwise vs logical OR warning
    
    commit a02dcde595f7cbd240ccd64de96034ad91cffc40 upstream.
    
    A new warning in clang points out a few places in this driver where a
    bitwise OR is being used with boolean types:
    
    drivers/input/touchscreen.c:81:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
            data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    This use of a bitwise OR is intentional, as bitwise operations do not
    short circuit, which allows all the calls to touchscreen_get_prop_u32()
    to happen so that the last parameter is initialized while coalescing the
    results of the calls to make a decision after they are all evaluated.
    
    To make this clearer to the compiler, use the '|=' operator to assign
    the result of each touchscreen_get_prop_u32() call to data_present,
    which keeps the meaning of the code the same but makes it obvious that
    every one of these calls is expected to happen.
    
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reported-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/r/20211014205757.3474635-1-nathan@kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48c2461f28feaf09f969b537a2f58d8f4f5da429
Author: Stefan Agner <stefan@agner.ch>
Date:   Sun Sep 30 23:02:33 2018 +0100

    ARM: 8800/1: use choice for kernel unwinders
    
    commit f9b58e8c7d031b0daa5c9a9ee27f5a4028ba53ac upstream.
    
    While in theory multiple unwinders could be compiled in, it does
    not make sense in practise. Use a choice to make the unwinder
    selection mutually exclusive and mandatory.
    
    Already before this commit it has not been possible to deselect
    FRAME_POINTER. Remove the obsolete comment.
    
    Furthermore, to produce a meaningful backtrace with FRAME_POINTER
    enabled the kernel needs a specific function prologue:
        mov    ip, sp
        stmfd    sp!, {fp, ip, lr, pc}
        sub    fp, ip, #4
    
    To get to the required prologue gcc uses apcs and no-sched-prolog.
    This compiler options are not available on clang, and clang is not
    able to generate the required prologue. Make the FRAME_POINTER
    config symbol depending on !clang.
    
    Suggested-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c76bce990ac5afa483c4e63689f2dc5f93a71ffc
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Sep 1 00:08:34 2020 -0700

    mwifiex: Remove unnecessary braces from HostCmd_SET_SEQ_NO_BSS_INFO
    
    commit 6a953dc4dbd1c7057fb765a24f37a5e953c85fb0 upstream.
    
    A new warning in clang points out when macro expansion might result in a
    GNU C statement expression. There is an instance of this in the mwifiex
    driver:
    
    drivers/net/wireless/marvell/mwifiex/cmdevt.c:217:34: warning: '}' and
    ')' tokens terminating statement expression appear in different macro
    expansion contexts [-Wcompound-token-split-by-macro]
            host_cmd->seq_num = cpu_to_le16(HostCmd_SET_SEQ_NO_BSS_INFO
                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/net/wireless/marvell/mwifiex/fw.h:519:46: note: expanded from
    macro 'HostCmd_SET_SEQ_NO_BSS_INFO'
            (((type) & 0x000f) << 12);                  }
                                                        ^
    
    This does not appear to be a real issue. Removing the braces and
    replacing them with parentheses will fix the warning and not change the
    meaning of the code.
    
    Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
    Link: https://github.com/ClangBuiltLinux/linux/issues/1146
    Reported-by: Andy Lavr <andy.lavr@gmail.com>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20200901070834.1015754-1-natechancellor@gmail.com
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83587397e758ee5822a690c31cadd8f2a43f2104
Author: Nicolas Pitre <nico@fluxnic.net>
Date:   Wed Nov 7 17:49:00 2018 +0100

    ARM: 8805/2: remove unneeded naked function usage
    
    commit b99afae1390140f5b0039e6b37a7380de31ae874 upstream.
    
    The naked attribute is known to confuse some old gcc versions when
    function arguments aren't explicitly listed as inline assembly operands
    despite the gcc documentation. That resulted in commit 9a40ac86152c
    ("ARM: 6164/1: Add kto and kfrom to input operands list.").
    
    Yet that commit has problems of its own by having assembly operand
    constraints completely wrong. If the generated code has been OK since
    then, it is due to luck rather than correctness. So this patch also
    provides proper assembly operand constraints, and removes two instances
    of redundant register usages in the implementation while at it.
    
    Inspection of the generated code with this patch doesn't show any
    obvious quality degradation either, so not relying on __naked at all
    will make the code less fragile, and avoid some issues with clang.
    
    The only remaining __naked instances (excluding the kprobes test cases)
    are exynos_pm_power_up_setup(), tc2_pm_power_up_setup() and
    
    cci_enable_port_for_self(. But in the first two cases, only the function
    address is used by the compiler with no chance of inlining it by
    mistake, and the third case is called from assembly code only. And the
    fact that no stack is available when the corresponding code is executed
    does warrant the __naked usage in those cases.
    
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Reviewed-by: Stefan Agner <stefan@agner.ch>
    Tested-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a899eeca5e8432a44d4cae9a7d44a0e862aff67
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Thu Sep 20 15:48:30 2018 -0700

    net: lan78xx: Avoid unnecessary self assignment
    
    commit 94e7c844990f0db92418586b107be135b4963b66 upstream.
    
    Clang warns when a variable is assigned to itself.
    
    drivers/net/usb/lan78xx.c:940:11: warning: explicitly assigning value of
    variable of type 'u32' (aka 'unsigned int') to itself [-Wself-assign]
                            offset = offset;
                            ~~~~~~ ^ ~~~~~~
    1 warning generated.
    
    Reorder the if statement to acheive the same result and avoid a self
    assignment warning.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/129
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90491283b4064220682e4b0687d07b05df01e3bf
Author: George Kennedy <george.kennedy@oracle.com>
Date:   Thu Nov 18 14:03:28 2021 -0500

    scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()
    
    commit e0a2c28da11e2c2b963fc01d50acbf03045ac732 upstream.
    
    In resp_mode_select() sanity check the block descriptor len to avoid UAF.
    
    BUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509
    Read of size 1 at addr ffff888026670f50 by task scsicmd/15032
    
    CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    Call Trace:
     <TASK>
     dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107
     print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257
     kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443
     __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306
     resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509
     schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483
     scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537
     scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521
     blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640
     __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325
     blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358
     __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1762
     __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839
     blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891
     blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474
     blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:63
     sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837
     sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775
     sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941
     sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166
     __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52
     do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50
     entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113
    
    Link: https://lore.kernel.org/r/1637262208-28850-1-git-send-email-george.kennedy@oracle.com
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: George Kennedy <george.kennedy@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5751a4cdee1fb8b6ec6c6f5f6f4fee210d3c1b9
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Fri Oct 22 17:03:01 2021 +0200

    fuse: annotate lock in fuse_reverse_inval_entry()
    
    commit bda9a71980e083699a0360963c0135657b73f47a upstream.
    
    Add missing inode lock annotatation; found by syzbot.
    
    Reported-and-tested-by: syzbot+9f747458f5990eaa8d43@syzkaller.appspotmail.com
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8d3e074336323dbbd71aeece684212e579ba829
Author: Fabio Estevam <festevam@gmail.com>
Date:   Wed Nov 24 15:45:41 2021 -0300

    ARM: dts: imx6ull-pinfunc: Fix CSI_DATA07__ESAI_TX0 pad name
    
    commit 737e65c7956795b3553781fb7bc82fce1c39503f upstream.
    
    According to the i.MX6ULL Reference Manual, pad CSI_DATA07 may
    have the ESAI_TX0 functionality, not ESAI_T0.
    
    Also, NXP's i.MX Config Tools 10.0 generates dtsi with the
    MX6ULL_PAD_CSI_DATA07__ESAI_TX0 naming, so fix it accordingly.
    
    There are no devicetree users in mainline that use the old name,
    so just remove the old entry.
    
    Fixes: c201369d4aa5 ("ARM: dts: imx6ull: add imx6ull support")
    Reported-by: George Makarov <georgemakarov1@gmail.com>
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4694b1ec425a2d20d6f8ca3db594829fdf5f2672
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Thu Dec 9 12:04:56 2021 +0000

    firmware: arm_scpi: Fix string overflow in SCPI genpd driver
    
    commit 865ed67ab955428b9aa771d8b4f1e4fb7fd08945 upstream.
    
    Without the bound checks for scpi_pd->name, it could result in the buffer
    overflow when copying the SCPI device name from the corresponding device
    tree node as the name string is set at maximum size of 30.
    
    Let us fix it by using devm_kasprintf so that the string buffer is
    allocated dynamically.
    
    Fixes: 8bec4337ad40 ("firmware: scpi: add device power domain support using genpd")
    Reported-by: Pedro Batista <pedbap.g@gmail.com>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Cc: stable@vger.kernel.org
    Cc: Cristian Marussi <cristian.marussi@arm.com>
    Link: https://lore.kernel.org/r/20211209120456.696879-1-sudeep.holla@arm.com'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3fde37d3f0d429f0fcce214cb52588a9e21260e
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Wed Dec 15 12:24:49 2021 -0800

    net: systemport: Add global locking for descriptor lifecycle
    
    commit 8b8e6e782456f1ce02a7ae914bbd5b1053f0b034 upstream.
    
    The descriptor list is a shared resource across all of the transmit queues, and
    the locking mechanism used today only protects concurrency across a given
    transmit queue between the transmit and reclaiming. This creates an opportunity
    for the SYSTEMPORT hardware to work on corrupted descriptors if we have
    multiple producers at once which is the case when using multiple transmit
    queues.
    
    This was particularly noticeable when using multiple flows/transmit queues and
    it showed up in interesting ways in that UDP packets would get a correct UDP
    header checksum being calculated over an incorrect packet length. Similarly TCP
    packets would get an equally correct checksum computed by the hardware over an
    incorrect packet length.
    
    The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges
    when the driver produces a new descriptor anytime it writes to the
    WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to
    re-organize its descriptors and it is possible that concurrent TX queues
    eventually break this internal allocation scheme to the point where the
    length/status part of the descriptor gets used for an incorrect data buffer.
    
    The fix is to impose a global serialization for all TX queues in the short
    section where we are writing to the WRITE_PORT_{HI,LO} registers which solves
    the corruption even with multiple concurrent TX queues being used.
    
    Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20211215202450.4086240-1-f.fainelli@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99a15fd89ba84fd1680b750b304275f64d6affb3
Author: George Kennedy <george.kennedy@oracle.com>
Date:   Tue Dec 14 09:45:10 2021 -0500

    libata: if T_LENGTH is zero, dma direction should be DMA_NONE
    
    commit 5da5231bb47864e5dd6c6731151e98b6ee498827 upstream.
    
    Avoid data corruption by rejecting pass-through commands where
    T_LENGTH is zero (No data is transferred) and the dma direction
    is not DMA_NONE.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: syzkaller<syzkaller@googlegroups.com>
    Signed-off-by: George Kennedy<george.kennedy@oracle.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0b25c6d1b91da64069c3c364e68775ad6d5437c
Author: Yu Liao <liaoyu15@huawei.com>
Date:   Mon Dec 13 21:57:27 2021 +0800

    timekeeping: Really make sure wall_to_monotonic isn't positive
    
    commit 4e8c11b6b3f0b6a283e898344f154641eda94266 upstream.
    
    Even after commit e1d7ba873555 ("time: Always make sure wall_to_monotonic
    isn't positive") it is still possible to make wall_to_monotonic positive
    by running the following code:
    
        int main(void)
        {
            struct timespec time;
    
            clock_gettime(CLOCK_MONOTONIC, &time);
            time.tv_nsec = 0;
            clock_settime(CLOCK_REALTIME, &time);
            return 0;
        }
    
    The reason is that the second parameter of timespec64_compare(), ts_delta,
    may be unnormalized because the delta is calculated with an open coded
    substraction which causes the comparison of tv_sec to yield the wrong
    result:
    
      wall_to_monotonic = { .tv_sec = -10, .tv_nsec =  900000000 }
      ts_delta          = { .tv_sec =  -9, .tv_nsec = -900000000 }
    
    That makes timespec64_compare() claim that wall_to_monotonic < ts_delta,
    but actually the result should be wall_to_monotonic > ts_delta.
    
    After normalization, the result of timespec64_compare() is correct because
    the tv_sec comparison is not longer misleading:
    
      wall_to_monotonic = { .tv_sec = -10, .tv_nsec =  900000000 }
      ts_delta          = { .tv_sec = -10, .tv_nsec =  100000000 }
    
    Use timespec64_sub() to ensure that ts_delta is normalized, which fixes the
    issue.
    
    Fixes: e1d7ba873555 ("time: Always make sure wall_to_monotonic isn't positive")
    Signed-off-by: Yu Liao <liaoyu15@huawei.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20211213135727.1656662-1-liaoyu15@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8e7f147380cff656a739a1883c2c540b6f250ab
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Fri Dec 10 11:07:14 2021 +0100

    USB: serial: option: add Telit FN990 compositions
    
    commit 2b503c8598d1b232e7fc7526bce9326d92331541 upstream.
    
    Add the following Telit FN990 compositions:
    
    0x1070: tty, adb, rmnet, tty, tty, tty, tty
    0x1071: tty, adb, mbim, tty, tty, tty, tty
    0x1072: rndis, tty, adb, tty, tty, tty, tty
    0x1073: tty, adb, ecm, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Link: https://lore.kernel.org/r/20211210100714.22587-1-dnlplm@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3c032b3ba09051ccbaec25856379570d5bd7b16
Author: Stefan Roese <sr@denx.de>
Date:   Tue Dec 14 12:49:32 2021 +0100

    PCI/MSI: Mask MSI-X vectors only on success
    
    commit 83dbf898a2d45289be875deb580e93050ba67529 upstream.
    
    Masking all unused MSI-X entries is done to ensure that a crash kernel
    starts from a clean slate, which correponds to the reset state of the
    device as defined in the PCI-E specificion 3.0 and later:
    
     Vector Control for MSI-X Table Entries
     --------------------------------------
    
     "00: Mask bit:  When this bit is set, the function is prohibited from
                     sending a message using this MSI-X Table entry.
                     ...
                     This bit’s state after reset is 1 (entry is masked)."
    
    A Marvell NVME device fails to deliver MSI interrupts after trying to
    enable MSI-X interrupts due to that masking. It seems to take the MSI-X
    mask bits into account even when MSI-X is disabled.
    
    While not specification compliant, this can be cured by moving the masking
    into the success path, so that the MSI-X table entries stay in device reset
    state when the MSI-X setup fails.
    
    [ tglx: Move it into the success path, add comment and amend changelog ]
    
    Fixes: aa8092c1d1f1 ("PCI/MSI: Mask all unused MSI-X entries")
    Signed-off-by: Stefan Roese <sr@denx.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-pci@vger.kernel.org
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Michal Simek <michal.simek@xilinx.com>
    Cc: Marek Vasut <marex@denx.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20211210161025.3287927-1-sr@denx.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9b5c1d450ac722572f158034b4167b490e9307e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Dec 14 12:42:14 2021 +0100

    PCI/MSI: Clear PCI_MSIX_FLAGS_MASKALL on error
    
    commit 94185adbfad56815c2c8401e16d81bdb74a79201 upstream.
    
    PCI_MSIX_FLAGS_MASKALL is set in the MSI-X control register at MSI-X
    interrupt setup time. It's cleared on success, but the error handling path
    only clears the PCI_MSIX_FLAGS_ENABLE bit.
    
    That's incorrect as the reset state of the PCI_MSIX_FLAGS_MASKALL bit is
    zero. That can be observed via lspci:
    
            Capabilities: [b0] MSI-X: Enable- Count=67 Masked+
    
    Clear the bit in the error path to restore the reset state.
    
    Fixes: 438553958ba1 ("PCI/MSI: Enable and mask MSI-X early")
    Reported-by: Stefan Roese <sr@denx.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Stefan Roese <sr@denx.de>
    Cc: linux-pci@vger.kernel.org
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Michal Simek <michal.simek@xilinx.com>
    Cc: Marek Vasut <marex@denx.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/87tufevoqx.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b3a3a363591aa002cd5abedbdca098f398eddd5
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Dec 14 19:46:21 2021 +0100

    USB: gadget: bRequestType is a bitfield, not a enum
    
    [ Upstream commit f08adf5add9a071160c68bb2a61d697f39ab0758 ]
    
    Szymon rightly pointed out that the previous check for the endpoint
    direction in bRequestType was not looking at only the bit involved, but
    rather the whole value.  Normally this is ok, but for some request
    types, bits other than bit 8 could be set and the check for the endpoint
    length could not stall correctly.
    
    Fix that up by only checking the single bit.
    
    Fixes: 153a2d7e3350 ("USB: gadget: detect too-big endpoint 0 requests")
    Cc: Felipe Balbi <balbi@kernel.org>
    Reported-by: Szymon Heidrich <szymon.heidrich@gmail.com>
    Link: https://lore.kernel.org/r/20211214184621.385828-1-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e1797914d8f223726ff6ae5ece4f97d73f21bab
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Dec 16 03:17:41 2021 -0800

    sit: do not call ipip6_dev_free() from sit_init_net()
    
    [ Upstream commit e28587cc491ef0f3c51258fdc87fbc386b1d4c59 ]
    
    ipip6_dev_free is sit dev->priv_destructor, already called
    by register_netdevice() if something goes wrong.
    
    Alternative would be to make ipip6_dev_free() robust against
    multiple invocations, but other drivers do not implement this
    strategy.
    
    syzbot reported:
    
    dst_release underflow
    WARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173
    Modules linked in:
    CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173
    Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48
    RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246
    RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000
    RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000
    RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c
    R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358
    R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000
    FS:  00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160
     ipip6_dev_free net/ipv6/sit.c:1414 [inline]
     sit_init_net+0x229/0x550 net/ipv6/sit.c:1936
     ops_init+0x313/0x430 net/core/net_namespace.c:140
     setup_net+0x35b/0x9d0 net/core/net_namespace.c:326
     copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470
     create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110
     unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226
     ksys_unshare+0x57d/0xb50 kernel/fork.c:3075
     __do_sys_unshare kernel/fork.c:3146 [inline]
     __se_sys_unshare kernel/fork.c:3144 [inline]
     __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f66c882ce99
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
    RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200
    RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000
     </TASK>
    
    Fixes: cf124db566e6 ("net: Fix inconsistent teardown and release of private netdev state.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Link: https://lore.kernel.org/r/20211216111741.1387540-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a829ff7c8ec494eca028824628a964cde543dc76
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Dec 15 09:39:37 2021 -0500

    net/packet: rx_owner_map depends on pg_vec
    
    [ Upstream commit ec6af094ea28f0f2dda1a6a33b14cd57e36a9755 ]
    
    Packet sockets may switch ring versions. Avoid misinterpreting state
    between versions, whose fields share a union. rx_owner_map is only
    allocated with a packet ring (pg_vec) and both are swapped together.
    If pg_vec is NULL, meaning no packet ring was allocated, then neither
    was rx_owner_map. And the field may be old state from a tpacket_v3.
    
    Fixes: 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition")
    Reported-by: Syzbot <syzbot+1ac0994a0a0c55151121@syzkaller.appspotmail.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20211215143937.106178-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e64772209baf3870a000bcc2893a6ff6763b92aa
Author: Cyril Novikov <cnovikov@lynx.com>
Date:   Mon Nov 1 18:39:36 2021 -0700

    ixgbe: set X550 MDIO speed before talking to PHY
    
    [ Upstream commit bf0a375055bd1afbbf02a0ef45f7655da7b71317 ]
    
    The MDIO bus speed must be initialized before talking to the PHY the first
    time in order to avoid talking to it using a speed that the PHY doesn't
    support.
    
    This fixes HW initialization error -17 (IXGBE_ERR_PHY_ADDR_INVALID) on
    Denverton CPUs (a.k.a. the Atom C3000 family) on ports with a 10Gb network
    plugged in. On those devices, HLREG0[MDCSPD] resets to 1, which combined
    with the 10Gb network results in a 24MHz MDIO speed, which is apparently
    too fast for the connected PHY. PHY register reads over MDIO bus return
    garbage, leading to initialization failure.
    
    Reproduced with Linux kernel 4.19 and 5.15-rc7. Can be reproduced using
    the following setup:
    
    * Use an Atom C3000 family system with at least one X552 LAN on the SoC
    * Disable PXE or other BIOS network initialization if possible
      (the interface must not be initialized before Linux boots)
    * Connect a live 10Gb Ethernet cable to an X550 port
    * Power cycle (not reset, doesn't always work) the system and boot Linux
    * Observe: ixgbe interfaces w/ 10GbE cables plugged in fail with error -17
    
    Fixes: e84db7272798 ("ixgbe: Introduce function to control MDIO speed")
    Signed-off-by: Cyril Novikov <cnovikov@lynx.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d0c927a9fb2b4065230936b77b54f857a3754fc
Author: Letu Ren <fantasquex@gmail.com>
Date:   Sat Nov 13 11:42:34 2021 +0800

    igbvf: fix double free in `igbvf_probe`
    
    [ Upstream commit b6d335a60dc624c0d279333b22c737faa765b028 ]
    
    In `igbvf_probe`, if register_netdev() fails, the program will go to
    label err_hw_init, and then to label err_ioremap. In free_netdev() which
    is just below label err_ioremap, there is `list_for_each_entry_safe` and
    `netif_napi_del` which aims to delete all entries in `dev->napi_list`.
    The program has added an entry `adapter->rx_ring->napi` which is added by
    `netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has
    been freed below label err_hw_init. So this a UAF.
    
    In terms of how to patch the problem, we can refer to igbvf_remove() and
    delete the entry before `adapter->rx_ring`.
    
    The KASAN logs are as follows:
    
    [   35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450
    [   35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366
    [   35.128360]
    [   35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14
    [   35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    [   35.131749] Call Trace:
    [   35.132199]  dump_stack_lvl+0x59/0x7b
    [   35.132865]  print_address_description+0x7c/0x3b0
    [   35.133707]  ? free_netdev+0x1fd/0x450
    [   35.134378]  __kasan_report+0x160/0x1c0
    [   35.135063]  ? free_netdev+0x1fd/0x450
    [   35.135738]  kasan_report+0x4b/0x70
    [   35.136367]  free_netdev+0x1fd/0x450
    [   35.137006]  igbvf_probe+0x121d/0x1a10 [igbvf]
    [   35.137808]  ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]
    [   35.138751]  local_pci_probe+0x13c/0x1f0
    [   35.139461]  pci_device_probe+0x37e/0x6c0
    [   35.165526]
    [   35.165806] Allocated by task 366:
    [   35.166414]  ____kasan_kmalloc+0xc4/0xf0
    [   35.167117]  foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]
    [   35.168078]  igbvf_probe+0x9c5/0x1a10 [igbvf]
    [   35.168866]  local_pci_probe+0x13c/0x1f0
    [   35.169565]  pci_device_probe+0x37e/0x6c0
    [   35.179713]
    [   35.179993] Freed by task 366:
    [   35.180539]  kasan_set_track+0x4c/0x80
    [   35.181211]  kasan_set_free_info+0x1f/0x40
    [   35.181942]  ____kasan_slab_free+0x103/0x140
    [   35.182703]  kfree+0xe3/0x250
    [   35.183239]  igbvf_probe+0x1173/0x1a10 [igbvf]
    [   35.184040]  local_pci_probe+0x13c/0x1f0
    
    Fixes: d4e0fe01a38a0 (igbvf: add new driver to support 82576 virtual functions)
    Reported-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Letu Ren <fantasquex@gmail.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d48ad66a55effcbea40e5764a1367b0059144fd3
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Fri Dec 10 09:55:29 2021 -0700

    soc/tegra: fuse: Fix bitwise vs. logical OR warning
    
    [ Upstream commit a7083763619f7485ccdade160deb81737cf2732f ]
    
    A new warning in clang points out two instances where boolean
    expressions are being used with a bitwise OR instead of logical OR:
    
    drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
                    reg = tegra_fuse_read_spare(i) |
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~
                                                   ||
    drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: note: cast one or both operands to int to silence this warning
    drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
                    reg = tegra_fuse_read_spare(i) |
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~
                                                   ||
    drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: note: cast one or both operands to int to silence this warning
    2 warnings generated.
    
    The motivation for the warning is that logical operations short circuit
    while bitwise operations do not.
    
    In this instance, tegra_fuse_read_spare() is not semantically returning
    a boolean, it is returning a bit value. Use u32 for its return type so
    that it can be used with either bitwise or boolean operators without any
    warnings.
    
    Fixes: 25cd5a391478 ("ARM: tegra: Add speedo-based process identification")
    Link: https://github.com/ClangBuiltLinux/linux/issues/1488
    Suggested-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2566c2530497a67112d8742c1935ad51ca5eb5de
Author: Alyssa Ross <hi@alyssa.is>
Date:   Thu Nov 25 15:44:38 2021 +0000

    dmaengine: st_fdma: fix MODULE_ALIAS
    
    [ Upstream commit 822c9f2b833c53fc67e8adf6f63ecc3ea24d502c ]
    
    modprobe can't handle spaces in aliases.
    
    Fixes: 6b4cd727eaf1 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support")
    Signed-off-by: Alyssa Ross <hi@alyssa.is>
    Link: https://lore.kernel.org/r/20211125154441.2626214-1-hi@alyssa.is
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b708e44d478ad98c2131e6539908143e9144796d
Author: Dinh Nguyen <dinguyen@kernel.org>
Date:   Mon Nov 1 19:36:30 2021 -0500

    ARM: socfpga: dts: fix qspi node compatible
    
    [ Upstream commit cb25b11943cbcc5a34531129952870420f8be858 ]
    
    The QSPI flash node needs to have the required "jedec,spi-nor" in the
    compatible string.
    
    Fixes: 1df99da8953 ("ARM: dts: socfpga: Enable QSPI in Arria10 devkit")
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9885c565d944261d2b006d475803b510105fd320
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Wed Oct 20 13:02:11 2021 -0500

    x86/sme: Explicitly map new EFI memmap table as encrypted
    
    commit 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 upstream.
    
    Reserving memory using efi_mem_reserve() calls into the x86
    efi_arch_mem_reserve() function. This function will insert a new EFI
    memory descriptor into the EFI memory map representing the area of
    memory to be reserved and marking it as EFI runtime memory. As part
    of adding this new entry, a new EFI memory map is allocated and mapped.
    The mapping is where a problem can occur. This new memory map is mapped
    using early_memremap() and generally mapped encrypted, unless the new
    memory for the mapping happens to come from an area of memory that is
    marked as EFI_BOOT_SERVICES_DATA memory. In this case, the new memory will
    be mapped unencrypted. However, during replacement of the old memory map,
    efi_mem_type() is disabled, so the new memory map will now be long-term
    mapped encrypted (in efi.memmap), resulting in the map containing invalid
    data and causing the kernel boot to crash.
    
    Since it is known that the area will be mapped encrypted going forward,
    explicitly map the new memory map as encrypted using early_memremap_prot().
    
    Cc: <stable@vger.kernel.org> # 4.14.x
    Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear")
    Link: https://lore.kernel.org/all/ebf1eb2940405438a09d51d121ec0d02c8755558.1634752931.git.thomas.lendacky@amd.com/
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    [ardb: incorporate Kconfig fix by Arnd]
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fe4d9ba5c921adc168076eb1f0eb80ef9315d75
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Sat Feb 2 10:41:17 2019 +0100

    x86: Make ARCH_USE_MEMREMAP_PROT a generic Kconfig symbol
    
    commit ce9084ba0d1d8030adee7038ace32f8d9d423d0f upstream.
    
    Turn ARCH_USE_MEMREMAP_PROT into a generic Kconfig symbol, and fix the
    dependency expression to reflect that AMD_MEM_ENCRYPT depends on it,
    instead of the other way around. This will permit ARCH_USE_MEMREMAP_PROT
    to be selected by other architectures.
    
    Note that the encryption related early memremap routines in
    arch/x86/mm/ioremap.c cannot be built for 32-bit x86 without triggering
    the following warning:
    
         arch/x86//mm/ioremap.c: In function 'early_memremap_encrypted':
      >> arch/x86/include/asm/pgtable_types.h:193:27: warning: conversion from
                         'long long unsigned int' to 'long unsigned int' changes
                         value from '9223372036854776163' to '355' [-Woverflow]
          #define __PAGE_KERNEL_ENC (__PAGE_KERNEL | _PAGE_ENC)
                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
         arch/x86//mm/ioremap.c:713:46: note: in expansion of macro '__PAGE_KERNEL_ENC'
           return early_memremap_prot(phys_addr, size, __PAGE_KERNEL_ENC);
    
    which essentially means they are 64-bit only anyway. However, we cannot
    make them dependent on CONFIG_ARCH_HAS_MEM_ENCRYPT, since that is always
    defined, even for i386 (and changing that results in a slew of build errors)
    
    So instead, build those routines only if CONFIG_AMD_MEM_ENCRYPT is
    defined.
    
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
    Cc: Alexander Graf <agraf@suse.de>
    Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
    Cc: Jeffrey Hugo <jhugo@codeaurora.org>
    Cc: Lee Jones <lee.jones@linaro.org>
    Cc: Leif Lindholm <leif.lindholm@linaro.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Matt Fleming <matt@codeblueprint.co.uk>
    Cc: Peter Jones <pjones@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-efi@vger.kernel.org
    Link: http://lkml.kernel.org/r/20190202094119.13230-9-ard.biesheuvel@linaro.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33645d3e22720cac1e4548f8fef57bf0649536ee
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Mon Nov 29 15:08:00 2021 -0500

    nfsd: fix use-after-free due to delegation race
    
    commit 548ec0805c399c65ed66c6641be467f717833ab5 upstream.
    
    A delegation break could arrive as soon as we've called vfs_setlease.  A
    delegation break runs a callback which immediately (in
    nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru.  If we
    then exit nfs4_set_delegation without hashing the delegation, it will be
    freed as soon as the callback is done with it, without ever being
    removed from del_recall_lru.
    
    Symptoms show up later as use-after-free or list corruption warnings,
    usually in the laundromat thread.
    
    I suspect aba2072f4523 "nfsd: grant read delegations to clients holding
    writes" made this bug easier to hit, but I looked as far back as v3.0
    and it looks to me it already had the same problem.  So I'm not sure
    where the bug was introduced; it may have been there from the beginning.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    [Salvatore Bonaccorso: Backport for context changes to versions which do
    not have 20b7d86f29d3 ("nfsd: use boottime for lease expiry calculation")]
    Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75fdb751f84727d614deea0571a1490c3225d83a
Author: Paul Moore <paul@paul-moore.com>
Date:   Thu Dec 9 11:46:07 2021 -0500

    audit: improve robustness of the audit queue handling
    
    commit f4b3ee3c85551d2d343a3ba159304066523f730f upstream.
    
    If the audit daemon were ever to get stuck in a stopped state the
    kernel's kauditd_thread() could get blocked attempting to send audit
    records to the userspace audit daemon.  With the kernel thread
    blocked it is possible that the audit queue could grow unbounded as
    certain audit record generating events must be exempt from the queue
    limits else the system enter a deadlock state.
    
    This patch resolves this problem by lowering the kernel thread's
    socket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks
    the kauditd_send_queue() function to better manage the various audit
    queues when connection problems occur between the kernel and the
    audit daemon.  With this patch, the backlog may temporarily grow
    beyond the defined limits when the audit daemon is stopped and the
    system is under heavy audit pressure, but kauditd_thread() will
    continue to make progress and drain the queues as it would for other
    connection problems.  For example, with the audit daemon put into a
    stopped state and the system configured to audit every syscall it
    was still possible to shutdown the system without a kernel panic,
    deadlock, etc.; granted, the system was slow to shutdown but that is
    to be expected given the extreme pressure of recording every syscall.
    
    The timeout value of HZ/10 was chosen primarily through
    experimentation and this developer's "gut feeling".  There is likely
    no one perfect value, but as this scenario is limited in scope (root
    privileges would be needed to send SIGSTOP to the audit daemon), it
    is likely not worth exposing this as a tunable at present.  This can
    always be done at a later date if it proves necessary.
    
    Cc: stable@vger.kernel.org
    Fixes: 5b52330bbfe63 ("audit: fix auditd/kernel connection state tracking")
    Reported-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Tested-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Reviewed-by: Richard Guy Briggs <rgb@redhat.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b03abd0aa09c05099f537cb05b8460c4298f0861
Author: Joe Thornber <ejt@redhat.com>
Date:   Wed Nov 24 12:07:39 2021 -0500

    dm btree remove: fix use after free in rebalance_children()
    
    commit 1b8d2789dad0005fd5e7d35dab26a8e1203fb6da upstream.
    
    Move dm_tm_unlock() after dm_tm_dec().
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 724b98b292187634e45af4e14a0803203e8ac62a
Author: Jerome Marchand <jmarchan@redhat.com>
Date:   Fri Dec 10 10:38:27 2021 +0100

    recordmcount.pl: look for jgnop instruction as well as bcrl on s390
    
    commit 85bf17b28f97ca2749968d8786dc423db320d9c2 upstream.
    
    On s390, recordmcount.pl is looking for "bcrl 0,<xxx>" instructions in
    the objdump -d outpout. However since binutils 2.37, objdump -d
    display "jgnop <xxx>" for the same instruction. Update the
    mcount_regex so that it accepts both.
    
    Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
    Reviewed-by: Miroslav Benes <mbenes@suse.cz>
    Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20211210093827.1623286-1-jmarchan@redhat.com
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0b2b958b9d8ea1f23209592590990398f9716f1
Author: Felix Fietkau <nbd@nbd.name>
Date:   Thu Dec 2 13:45:33 2021 +0100

    mac80211: send ADDBA requests using the tid/queue of the aggregation session
    
    commit 1fe98f5690c4219d419ea9cc190f94b3401cf324 upstream.
    
    Sending them out on a different queue can cause a race condition where a
    number of packets in the queue may be discarded by the receiver, because
    the ADDBA request is sent too early.
    This affects any driver with software A-MPDU setup which does not allocate
    packet seqno in hardware on tx, regardless of whether iTXQ is used or not.
    The only driver I've seen that explicitly deals with this issue internally
    is mwl8k.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://lore.kernel.org/r/20211202124533.80388-1-nbd@nbd.name
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cb8663544d85bd2c401f6e3a0bc651c3ef67b9f
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Fri Nov 12 18:14:40 2021 +0100

    hwmon: (dell-smm) Fix warning on /proc/i8k creation error
    
    commit dbd3e6eaf3d813939b28e8a66e29d81cdc836445 upstream.
    
    The removal function is called regardless of whether
    /proc/i8k was created successfully or not, the later
    causing a WARN() on module removal.
    Fix that by only registering the removal function
    if /proc/i8k was created successfully.
    
    Tested on a Inspiron 3505.
    
    Fixes: 039ae58503f3 ("hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Acked-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/20211112171440.59006-1-W_Armin@gmx.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20fdf274472998123a8d173ba4cb6282ff6b63bd
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Wed Jul 11 15:30:14 2018 +0200

    bpf: fix panic due to oob in bpf_prog_test_run_skb
    
    commit 6e6fddc78323533be570873abb728b7e0ba7e024 upstream.
    
    sykzaller triggered several panics similar to the below:
    
      [...]
      [  248.851531] BUG: KASAN: use-after-free in _copy_to_user+0x5c/0x90
      [  248.857656] Read of size 985 at addr ffff8808017ffff2 by task a.out/1425
      [...]
      [  248.865902] CPU: 1 PID: 1425 Comm: a.out Not tainted 4.18.0-rc4+ #13
      [  248.865903] Hardware name: Supermicro SYS-5039MS-H12TRF/X11SSE-F, BIOS 2.1a 03/08/2018
      [  248.865905] Call Trace:
      [  248.865910]  dump_stack+0xd6/0x185
      [  248.865911]  ? show_regs_print_info+0xb/0xb
      [  248.865913]  ? printk+0x9c/0xc3
      [  248.865915]  ? kmsg_dump_rewind_nolock+0xe4/0xe4
      [  248.865919]  print_address_description+0x6f/0x270
      [  248.865920]  kasan_report+0x25b/0x380
      [  248.865922]  ? _copy_to_user+0x5c/0x90
      [  248.865924]  check_memory_region+0x137/0x190
      [  248.865925]  kasan_check_read+0x11/0x20
      [  248.865927]  _copy_to_user+0x5c/0x90
      [  248.865930]  bpf_test_finish.isra.8+0x4f/0xc0
      [  248.865932]  bpf_prog_test_run_skb+0x6a0/0xba0
      [...]
    
    After scrubbing the BPF prog a bit from the noise, turns out it called
    bpf_skb_change_head() for the lwt_xmit prog with headroom of 2. Nothing
    wrong in that, however, this was run with repeat >> 0 in bpf_prog_test_run_skb()
    and the same skb thus keeps changing until the pskb_expand_head() called
    from skb_cow() keeps bailing out in atomic alloc context with -ENOMEM.
    So upon return we'll basically have 0 headroom left yet blindly do the
    __skb_push() of 14 bytes and keep copying data from there in bpf_test_finish()
    out of bounds. Fix to check if we have enough headroom and if pskb_expand_head()
    fails, bail out with error.
    
    Another bug independent of this fix (but related in triggering above) is
    that BPF_PROG_TEST_RUN should be reworked to reset the skb/xdp buffer to
    it's original state from input as otherwise repeating the same test in a
    loop won't work for benchmarking when underlying input buffer is getting
    changed by the prog each time and reused for the next run leading to
    unexpected results.
    
    Fixes: 1cf1cae963c2 ("bpf: introduce BPF_PROG_TEST_RUN command")
    Reported-by: syzbot+709412e651e55ed96498@syzkaller.appspotmail.com
    Reported-by: syzbot+54f39d6ab58f39720a55@syzkaller.appspotmail.com
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    [connoro: drop test_verifier.c changes not applicable to 4.14]
    Signed-off-by: Connor O'Brien <connoro@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06f629fc209e1c7668d7ddec391d19a56b3ebd11
Author: Chen Jun <chenjun102@huawei.com>
Date:   Wed Nov 24 14:08:01 2021 +0000

    tracing: Fix a kmemleak false positive in tracing_map
    
    [ Upstream commit f25667e5980a4333729cac3101e5de1bb851f71a ]
    
    Doing the command:
      echo 'hist:key=common_pid.execname,common_timestamp' > /sys/kernel/debug/tracing/events/xxx/trigger
    
    Triggers many kmemleak reports:
    
    unreferenced object 0xffff0000c7ea4980 (size 128):
      comm "bash", pid 338, jiffies 4294912626 (age 9339.324s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<00000000f3469921>] kmem_cache_alloc_trace+0x4c0/0x6f0
        [<0000000054ca40c3>] hist_trigger_elt_data_alloc+0x140/0x178
        [<00000000633bd154>] tracing_map_init+0x1f8/0x268
        [<000000007e814ab9>] event_hist_trigger_func+0xca0/0x1ad0
        [<00000000bf8520ed>] trigger_process_regex+0xd4/0x128
        [<00000000f549355a>] event_trigger_write+0x7c/0x120
        [<00000000b80f898d>] vfs_write+0xc4/0x380
        [<00000000823e1055>] ksys_write+0x74/0xf8
        [<000000008a9374aa>] __arm64_sys_write+0x24/0x30
        [<0000000087124017>] do_el0_svc+0x88/0x1c0
        [<00000000efd0dcd1>] el0_svc+0x1c/0x28
        [<00000000dbfba9b3>] el0_sync_handler+0x88/0xc0
        [<00000000e7399680>] el0_sync+0x148/0x180
    unreferenced object 0xffff0000c7ea4980 (size 128):
      comm "bash", pid 338, jiffies 4294912626 (age 9339.324s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<00000000f3469921>] kmem_cache_alloc_trace+0x4c0/0x6f0
        [<0000000054ca40c3>] hist_trigger_elt_data_alloc+0x140/0x178
        [<00000000633bd154>] tracing_map_init+0x1f8/0x268
        [<000000007e814ab9>] event_hist_trigger_func+0xca0/0x1ad0
        [<00000000bf8520ed>] trigger_process_regex+0xd4/0x128
        [<00000000f549355a>] event_trigger_write+0x7c/0x120
        [<00000000b80f898d>] vfs_write+0xc4/0x380
        [<00000000823e1055>] ksys_write+0x74/0xf8
        [<000000008a9374aa>] __arm64_sys_write+0x24/0x30
        [<0000000087124017>] do_el0_svc+0x88/0x1c0
        [<00000000efd0dcd1>] el0_svc+0x1c/0x28
        [<00000000dbfba9b3>] el0_sync_handler+0x88/0xc0
        [<00000000e7399680>] el0_sync+0x148/0x180
    
    The reason is elts->pages[i] is alloced by get_zeroed_page.
    and kmemleak will not scan the area alloced by get_zeroed_page.
    The address stored in elts->pages will be regarded as leaked.
    
    That is, the elts->pages[i] will have pointers loaded onto it as well, and
    without telling kmemleak about it, those pointers will look like memory
    without a reference.
    
    To fix this, call kmemleak_alloc to tell kmemleak to scan elts->pages[i]
    
    Link: https://lkml.kernel.org/r/20211124140801.87121-1-chenjun102@huawei.com
    
    Signed-off-by: Chen Jun <chenjun102@huawei.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54e785f7d5c197bc06dbb8053700df7e2a093ced
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Mon Nov 29 09:53:27 2021 -0800

    net: netlink: af_netlink: Prevent empty skb by adding a check on len.
    
    [ Upstream commit f123cffdd8fe8ea6c7fded4b88516a42798797d0 ]
    
    Adding a check on len parameter to avoid empty skb. This prevents a
    division error in netem_enqueue function which is caused when skb->len=0
    and skb->data_len=0 in the randomized corruption step as shown below.
    
    skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);
    
    Crash Report:
    [  343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family
    0 port 6081 - 0
    [  343.216110] netem: version 1.3
    [  343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
    [  343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+
    [  343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS 1.11.0-2.el7 04/01/2014
    [  343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]
    [  343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff
    ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f
    74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03
    [  343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246
    [  343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:
    0000000000000000
    [  343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:
    ffff88800f8eda40
    [  343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:
    ffffffff94fb8445
    [  343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:
    0000000000000000
    [  343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:
    0000000000000020
    [  343.247291] FS:  00007fdde2bd7700(0000) GS:ffff888109780000(0000)
    knlGS:0000000000000000
    [  343.248350] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:
    00000000000006e0
    [  343.250076] Call Trace:
    [  343.250423]  <TASK>
    [  343.250713]  ? memcpy+0x4d/0x60
    [  343.251162]  ? netem_init+0xa0/0xa0 [sch_netem]
    [  343.251795]  ? __sanitizer_cov_trace_pc+0x21/0x60
    [  343.252443]  netem_enqueue+0xe28/0x33c0 [sch_netem]
    [  343.253102]  ? stack_trace_save+0x87/0xb0
    [  343.253655]  ? filter_irq_stacks+0xb0/0xb0
    [  343.254220]  ? netem_init+0xa0/0xa0 [sch_netem]
    [  343.254837]  ? __kasan_check_write+0x14/0x20
    [  343.255418]  ? _raw_spin_lock+0x88/0xd6
    [  343.255953]  dev_qdisc_enqueue+0x50/0x180
    [  343.256508]  __dev_queue_xmit+0x1a7e/0x3090
    [  343.257083]  ? netdev_core_pick_tx+0x300/0x300
    [  343.257690]  ? check_kcov_mode+0x10/0x40
    [  343.258219]  ? _raw_spin_unlock_irqrestore+0x29/0x40
    [  343.258899]  ? __kasan_init_slab_obj+0x24/0x30
    [  343.259529]  ? setup_object.isra.71+0x23/0x90
    [  343.260121]  ? new_slab+0x26e/0x4b0
    [  343.260609]  ? kasan_poison+0x3a/0x50
    [  343.261118]  ? kasan_unpoison+0x28/0x50
    [  343.261637]  ? __kasan_slab_alloc+0x71/0x90
    [  343.262214]  ? memcpy+0x4d/0x60
    [  343.262674]  ? write_comp_data+0x2f/0x90
    [  343.263209]  ? __kasan_check_write+0x14/0x20
    [  343.263802]  ? __skb_clone+0x5d6/0x840
    [  343.264329]  ? __sanitizer_cov_trace_pc+0x21/0x60
    [  343.264958]  dev_queue_xmit+0x1c/0x20
    [  343.265470]  netlink_deliver_tap+0x652/0x9c0
    [  343.266067]  netlink_unicast+0x5a0/0x7f0
    [  343.266608]  ? netlink_attachskb+0x860/0x860
    [  343.267183]  ? __sanitizer_cov_trace_pc+0x21/0x60
    [  343.267820]  ? write_comp_data+0x2f/0x90
    [  343.268367]  netlink_sendmsg+0x922/0xe80
    [  343.268899]  ? netlink_unicast+0x7f0/0x7f0
    [  343.269472]  ? __sanitizer_cov_trace_pc+0x21/0x60
    [  343.270099]  ? write_comp_data+0x2f/0x90
    [  343.270644]  ? netlink_unicast+0x7f0/0x7f0
    [  343.271210]  sock_sendmsg+0x155/0x190
    [  343.271721]  ____sys_sendmsg+0x75f/0x8f0
    [  343.272262]  ? kernel_sendmsg+0x60/0x60
    [  343.272788]  ? write_comp_data+0x2f/0x90
    [  343.273332]  ? write_comp_data+0x2f/0x90
    [  343.273869]  ___sys_sendmsg+0x10f/0x190
    [  343.274405]  ? sendmsg_copy_msghdr+0x80/0x80
    [  343.274984]  ? slab_post_alloc_hook+0x70/0x230
    [  343.275597]  ? futex_wait_setup+0x240/0x240
    [  343.276175]  ? security_file_alloc+0x3e/0x170
    [  343.276779]  ? write_comp_data+0x2f/0x90
    [  343.277313]  ? __sanitizer_cov_trace_pc+0x21/0x60
    [  343.277969]  ? write_comp_data+0x2f/0x90
    [  343.278515]  ? __fget_files+0x1ad/0x260
    [  343.279048]  ? __sanitizer_cov_trace_pc+0x21/0x60
    [  343.279685]  ? write_comp_data+0x2f/0x90
    [  343.280234]  ? __sanitizer_cov_trace_pc+0x21/0x60
    [  343.280874]  ? sockfd_lookup_light+0xd1/0x190
    [  343.281481]  __sys_sendmsg+0x118/0x200
    [  343.281998]  ? __sys_sendmsg_sock+0x40/0x40
    [  343.282578]  ? alloc_fd+0x229/0x5e0
    [  343.283070]  ? write_comp_data+0x2f/0x90
    [  343.283610]  ? write_comp_data+0x2f/0x90
    [  343.284135]  ? __sanitizer_cov_trace_pc+0x21/0x60
    [  343.284776]  ? ktime_get_coarse_real_ts64+0xb8/0xf0
    [  343.285450]  __x64_sys_sendmsg+0x7d/0xc0
    [  343.285981]  ? syscall_enter_from_user_mode+0x4d/0x70
    [  343.286664]  do_syscall_64+0x3a/0x80
    [  343.287158]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [  343.287850] RIP: 0033:0x7fdde24cf289
    [  343.288344] Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00
    48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f
    05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b7 db 2c 00 f7 d8 64 89 01 48
    [  343.290729] RSP: 002b:00007fdde2bd6d98 EFLAGS: 00000246 ORIG_RAX:
    000000000000002e
    [  343.291730] RAX: ffffffffffffffda RBX: 0000000000000000 RCX:
    00007fdde24cf289
    [  343.292673] RDX: 0000000000000000 RSI: 00000000200000c0 RDI:
    0000000000000004
    [  343.293618] RBP: 00007fdde2bd6e20 R08: 0000000100000001 R09:
    0000000000000000
    [  343.294557] R10: 0000000100000001 R11: 0000000000000246 R12:
    0000000000000000
    [  343.295493] R13: 0000000000021000 R14: 0000000000000000 R15:
    00007fdde2bd7700
    [  343.296432]  </TASK>
    [  343.296735] Modules linked in: sch_netem ip6_vti ip_vti ip_gre ipip
    sit ip_tunnel geneve macsec macvtap tap ipvlan macvlan 8021q garp mrp
    hsr wireguard libchacha20poly1305 chacha_x86_64 poly1305_x86_64
    ip6_udp_tunnel udp_tunnel libblake2s blake2s_x86_64 libblake2s_generic
    curve25519_x86_64 libcurve25519_generic libchacha xfrm_interface
    xfrm6_tunnel tunnel4 veth netdevsim psample batman_adv nlmon dummy team
    bonding tls vcan ip6_gre ip6_tunnel tunnel6 gre tun ip6t_rpfilter
    ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set
    ebtable_nat ebtable_broute ip6table_nat ip6table_mangle
    ip6table_security ip6table_raw iptable_nat nf_nat nf_conntrack
    nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_security
    iptable_raw ebtable_filter ebtables rfkill ip6table_filter ip6_tables
    iptable_filter ppdev bochs drm_vram_helper drm_ttm_helper ttm
    drm_kms_helper cec parport_pc drm joydev floppy parport sg syscopyarea
    sysfillrect sysimgblt i2c_piix4 qemu_fw_cfg fb_sys_fops pcspkr
    [  343.297459]  ip_tables xfs virtio_net net_failover failover sd_mod
    sr_mod cdrom t10_pi ata_generic pata_acpi ata_piix libata virtio_pci
    virtio_pci_legacy_dev serio_raw virtio_pci_modern_dev dm_mirror
    dm_region_hash dm_log dm_mod
    [  343.311074] Dumping ftrace buffer:
    [  343.311532]    (ftrace buffer empty)
    [  343.312040] ---[ end trace a2e3db5a6ae05099 ]---
    [  343.312691] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]
    [  343.313481] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff
    ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f
    74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03
    [  343.315893] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246
    [  343.316622] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:
    0000000000000000
    [  343.317585] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:
    ffff88800f8eda40
    [  343.318549] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:
    ffffffff94fb8445
    [  343.319503] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:
    0000000000000000
    [  343.320455] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:
    0000000000000020
    [  343.321414] FS:  00007fdde2bd7700(0000) GS:ffff888109780000(0000)
    knlGS:0000000000000000
    [  343.322489] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  343.323283] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:
    00000000000006e0
    [  343.324264] Kernel panic - not syncing: Fatal exception in interrupt
    [  343.333717] Dumping ftrace buffer:
    [  343.334175]    (ftrace buffer empty)
    [  343.334653] Kernel Offset: 0x13600000 from 0xffffffff81000000
    (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
    [  343.336027] Rebooting in 86400 seconds..
    
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Link: https://lore.kernel.org/r/20211129175328.55339-1-harshit.m.mogalapalli@oracle.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bcb50fff91e3527f47fa2f058c1cc0d4eb2a014
Author: Ondrej Jirman <megous@megous.com>
Date:   Fri Sep 24 13:15:27 2021 +0200

    i2c: rk3x: Handle a spurious start completion interrupt flag
    
    [ Upstream commit 02fe0fbd8a21e183687925c3a266ae27dda9840f ]
    
    In a typical read transfer, start completion flag is being set after
    read finishes (notice ipd bit 4 being set):
    
    trasnfer poll=0
    i2c start
    rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
    i2c read
    rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
    i2c stop
    rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 33
    
    This causes I2C transfer being aborted in polled mode from a stop completion
    handler:
    
    trasnfer poll=1
    i2c start
    rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
    i2c read
    rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 0
    rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
    i2c stop
    rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 13
    i2c stop
    rk3x-i2c fdd40000.i2c: unexpected irq in STOP: 0x10
    
    Clearing the START flag after read fixes the issue without any obvious
    side effects.
    
    This issue was dicovered on RK3566 when adding support for powering
    off the RK817 PMIC.
    
    Signed-off-by: Ondrej Jirman <megous@megous.com>
    Reviewed-by: John Keeping <john@metanate.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cfaadcef4debd31e3160d05c2860624d9b737c30
Author: Helge Deller <deller@gmx.de>
Date:   Fri Nov 26 16:45:59 2021 +0100

    parisc/agp: Annotate parisc agp init functions with __init
    
    [ Upstream commit 8d88382b7436551a9ebb78475c546b670790cbf6 ]
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5da2faee7e9796593a5de84791684b9c28ca4e4b
Author: Erik Ekman <erik@kryo.se>
Date:   Sun Nov 28 13:37:11 2021 +0100

    net/mlx4_en: Update reported link modes for 1/10G
    
    [ Upstream commit 2191b1dfef7d45f44b5008d2148676d9f2c82874 ]
    
    When link modes were initially added in commit 2c762679435dc
    ("net/mlx4_en: Use PTYS register to query ethtool settings") and
    later updated for the new ethtool API in commit 3d8f7cc78d0eb
    ("net: mlx4: use new ETHTOOL_G/SSETTINGS API") the only 1/10G non-baseT
    link modes configured were 1000baseKX, 10000baseKX4 and 10000baseKR.
    It looks like these got picked to represent other modes since nothing
    better was available.
    
    Switch to using more specific link modes added in commit 5711a98221443
    ("net: ethtool: add support for 1000BaseX and missing 10G link modes").
    
    Tested with MCX311A-XCAT connected via DAC.
    Before:
    
    % sudo ethtool enp3s0
    Settings for enp3s0:
            Supported ports: [ FIBRE ]
            Supported link modes:   1000baseKX/Full
                                    10000baseKR/Full
            Supported pause frame use: Symmetric Receive-only
            Supports auto-negotiation: No
            Supported FEC modes: Not reported
            Advertised link modes:  1000baseKX/Full
                                    10000baseKR/Full
            Advertised pause frame use: Symmetric
            Advertised auto-negotiation: No
            Advertised FEC modes: Not reported
            Speed: 10000Mb/s
            Duplex: Full
            Auto-negotiation: off
            Port: Direct Attach Copper
            PHYAD: 0
            Transceiver: internal
            Supports Wake-on: d
            Wake-on: d
            Current message level: 0x00000014 (20)
                                   link ifdown
            Link detected: yes
    
    With this change:
    
    % sudo ethtool enp3s0
            Settings for enp3s0:
            Supported ports: [ FIBRE ]
            Supported link modes:   1000baseX/Full
                                    10000baseCR/Full
                                    10000baseSR/Full
            Supported pause frame use: Symmetric Receive-only
            Supports auto-negotiation: No
            Supported FEC modes: Not reported
            Advertised link modes:  1000baseX/Full
                                    10000baseCR/Full
                                    10000baseSR/Full
            Advertised pause frame use: Symmetric
            Advertised auto-negotiation: No
            Advertised FEC modes: Not reported
            Speed: 10000Mb/s
            Duplex: Full
            Auto-negotiation: off
            Port: Direct Attach Copper
            PHYAD: 0
            Transceiver: internal
            Supports Wake-on: d
            Wake-on: d
            Current message level: 0x00000014 (20)
                                   link ifdown
            Link detected: yes
    
    Tested-by: Michael Stapelberg <michael@stapelberg.ch>
    Signed-off-by: Erik Ekman <erik@kryo.se>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a8358e0bfc1d074e757948ac5103ab5ed1689d0
Author: Philip Chen <philipchen@chromium.org>
Date:   Sat Oct 30 10:08:50 2021 -0700

    drm/msm/dsi: set default num_data_lanes
    
    [ Upstream commit cd92cc187c053ab010a1570e2d61d68394a5c725 ]
    
    If "data_lanes" property of the dsi output endpoint is missing in
    the DT, num_data_lanes would be 0 by default, which could cause
    dsi_host_attach() to fail if dsi->lanes is set to a non-zero value
    by the bridge driver.
    
    According to the binding document of msm dsi controller, the
    input/output endpoint of the controller is expected to have 4 lanes.
    So let's set num_data_lanes to 4 by default.
    
    Signed-off-by: Philip Chen <philipchen@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20211030100812.1.I6cd9af36b723fed277d34539d3b2ba4ca233ad2d@changeid
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6644989642844de830f9b072cd65c553cb55946c
Author: Tadeusz Struk <tadeusz.struk@linaro.org>
Date:   Wed Dec 8 10:27:42 2021 -0800

    nfc: fix segfault in nfc_genl_dump_devices_done
    
    commit fd79a0cbf0b2e34bcc45b13acf962e2032a82203 upstream.
    
    When kmalloc in nfc_genl_dump_devices() fails then
    nfc_genl_dump_devices_done() segfaults as below
    
    KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
    CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014
    Workqueue: events netlink_sock_destruct_work
    RIP: 0010:klist_iter_exit+0x26/0x80
    Call Trace:
    <TASK>
    class_dev_iter_exit+0x15/0x20
    nfc_genl_dump_devices_done+0x3b/0x50
    genl_lock_done+0x84/0xd0
    netlink_sock_destruct+0x8f/0x270
    __sk_destruct+0x64/0x3b0
    sk_destruct+0xa8/0xd0
    __sk_free+0x2e8/0x3d0
    sk_free+0x51/0x90
    netlink_sock_destruct_work+0x1c/0x20
    process_one_work+0x411/0x710
    worker_thread+0x6fd/0xa80
    
    Link: https://syzkaller.appspot.com/bug?id=fc0fa5a53db9edd261d56e74325419faf18bd0df
    Reported-by: syzbot+f9f76f4a0766420b4a02@syzkaller.appspotmail.com
    Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20211208182742.340542-1-tadeusz.struk@linaro.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>