commit 424a46ea058e160ae6fdd0693092ba79da533f26
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jul 12 16:27:29 2022 +0200

    Linux 4.14.288
    
    Link: https://lore.kernel.org/r/20220711090536.245939953@linuxfoundation.org
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83b1e3ca6a30f8731c0a40acc9f46e2b9a19e6db
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 08:27:22 2022 +0400

    dmaengine: ti: Add missing put_device in ti_dra7_xbar_route_allocate
    
    commit 615a4bfc426e11dba05c2cf343f9ac752fb381d2 upstream.
    
    of_find_device_by_node() takes reference, we should use put_device()
    to release it when not need anymore.
    
    Fixes: a074ae38f859 ("dmaengine: Add driver for TI DMA crossbar on DRA7x")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Link: https://lore.kernel.org/r/20220605042723.17668-1-linmq006@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61b4ef19c346dc21ab1d4f39f5c412e3037b2bdc
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 08:27:23 2022 +0400

    dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate
    
    commit c132fe78ad7b4ce8b5d49a501a15c29d08eeb23a upstream.
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not needed anymore.
    
    Add missing of_node_put() in to fix this.
    
    Fixes: ec9bfa1e1a79 ("dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220605042723.17668-2-linmq006@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bce1b24d66af1e19b0483816013c5345fd96eae7
Author: Michael Walle <michael@walle.cc>
Date:   Thu May 26 15:51:11 2022 +0200

    dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() correctly
    
    commit 3770d92bd5237d686e49da7b2fb86f53ee6ed259 upstream.
    
    It seems that it is valid to have less than the requested number of
    descriptors. But what is not valid and leads to subsequent errors is to
    have zero descriptors. In that case, abort the probing.
    
    Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Link: https://lore.kernel.org/r/20220526135111.1470926-1-michael@walle.cc
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b91312b50751a1289fb2ec7ea6453a1961455cee
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jul 10 13:55:49 2022 -0700

    ida: don't use BUG_ON() for debugging
    
    commit fc82bbf4dede758007763867d0282353c06d1121 upstream.
    
    This is another old BUG_ON() that just shouldn't exist (see also commit
    a382f8fee42c: "signal handling: don't use BUG_ON() for debugging").
    
    In fact, as Matthew Wilcox points out, this condition shouldn't really
    even result in a warning, since a negative id allocation result is just
    a normal allocation failure:
    
      "I wonder if we should even warn here -- sure, the caller is trying to
       free something that wasn't allocated, but we don't warn for
       kfree(NULL)"
    
    and goes on to point out how that current error check is only causing
    people to unnecessarily do their own index range checking before freeing
    it.
    
    This was noted by Itay Iellin, because the bluetooth HCI socket cookie
    code does *not* do that range checking, and ends up just freeing the
    error case too, triggering the BUG_ON().
    
    The HCI code requires CAP_NET_RAW, and seems to just result in an ugly
    splat, but there really is no reason to BUG_ON() here, and we have
    generally striven for allocation models where it's always ok to just do
    
        free(alloc());
    
    even if the allocation were to fail for some random reason (usually
    obviously that "random" reason being some resource limit).
    
    Fixes: 88eca0207cf1 ("ida: simplified functions for id allocation")
    Reported-by: Itay Iellin <ieitayie@gmail.com>
    Suggested-by: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cebc792be06338ae2a3f71bffd8ac84c28771493
Author: Satish Nagireddy <satish.nagireddy@getcruise.com>
Date:   Tue Jun 28 12:12:16 2022 -0700

    i2c: cadence: Unregister the clk notifier in error path
    
    [ Upstream commit 3501f0c663063513ad604fb1b3f06af637d3396d ]
    
    This patch ensures that the clock notifier is unregistered
    when driver probe is returning error.
    
    Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller")
    Signed-off-by: Satish Nagireddy <satish.nagireddy@getcruise.com>
    Tested-by: Lars-Peter Clausen <lars@metafoo.de>
    Reviewed-by: Michal Simek <michal.simek@amd.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54896239f03db50a66a1c4376ea14dc46073f980
Author: Samuel Holland <samuel@sholland.org>
Date:   Wed May 25 21:49:56 2022 -0500

    pinctrl: sunxi: a83t: Fix NAND function name for some pins
    
    [ Upstream commit aaefa29270d9551b604165a08406543efa9d16f5 ]
    
    The other NAND pins on Port C use the "nand0" function name.
    "nand0" also matches all of the other Allwinner SoCs.
    
    Fixes: 4730f33f0d82 ("pinctrl: sunxi: add allwinner A83T PIO controller support")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Link: https://lore.kernel.org/r/20220526024956.49500-1-samuel@sholland.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9989c726f588d1fc5f2879d66ba0ab7ea7aa44f
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Thu Jul 7 16:07:53 2022 -0700

    xfs: remove incorrect ASSERT in xfs_rename
    
    commit e445976537ad139162980bee015b7364e5b64fff upstream.
    
    This ASSERT in xfs_rename is a) incorrect, because
    (RENAME_WHITEOUT|RENAME_NOREPLACE) is a valid combination, and
    b) unnecessary, because actual invalid flag combinations are already
    handled at the vfs level in do_renameat2() before we get called.
    So, remove it.
    
    Reported-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Fixes: 7dcf5c3e4527 ("xfs: add RENAME_WHITEOUT support")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Acked-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62f4859de70ed0f2ed097d6833820e9522aa314f
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Jun 30 14:16:54 2022 +0200

    powerpc/powernv: delay rng platform device creation until later in boot
    
    commit 887502826549caa7e4215fd9e628f48f14c0825a upstream.
    
    The platform device for the rng must be created much later in boot.
    Otherwise it tries to connect to a parent that doesn't yet exist,
    resulting in this splat:
    
      [    0.000478] kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is being called.
      [    0.002925] [c000000002a0fb30] [c00000000073b0bc] kobject_get+0x8c/0x100 (unreliable)
      [    0.003071] [c000000002a0fba0] [c00000000087e464] device_add+0xf4/0xb00
      [    0.003194] [c000000002a0fc80] [c000000000a7f6e4] of_device_add+0x64/0x80
      [    0.003321] [c000000002a0fcb0] [c000000000a800d0] of_platform_device_create_pdata+0xd0/0x1b0
      [    0.003476] [c000000002a0fd00] [c00000000201fa44] pnv_get_random_long_early+0x240/0x2e4
      [    0.003623] [c000000002a0fe20] [c000000002060c38] random_init+0xc0/0x214
    
    This patch fixes the issue by doing the platform device creation inside
    of machine_subsys_initcall.
    
    Fixes: f3eac426657d ("powerpc/powernv: wire up rng during setup_arch")
    Cc: stable@vger.kernel.org
    Reported-by: Sachin Sant <sachinp@linux.ibm.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Tested-by: Sachin Sant <sachinp@linux.ibm.com>
    [mpe: Change "of node" to "platform device" in change log]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220630121654.1939181-1-Jason@zx2c4.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dac29e2bef4518d01764fa43ee8396a3a4d13770
Author: Hsin-Yi Wang <hsinyi@chromium.org>
Date:   Fri Jul 1 01:33:29 2022 +0800

    video: of_display_timing.h: include errno.h
    
    commit 3663a2fb325b8782524f3edb0ae32d6faa615109 upstream.
    
    If CONFIG_OF is not enabled, default of_get_display_timing() returns an
    errno, so include the header.
    
    Fixes: 422b67e0b31a ("videomode: provide dummy inline functions for !CONFIG_OF")
    Suggested-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7e7c2ad446f359f54f4ea6a0a30b218e5edf134
Author: Helge Deller <deller@gmx.de>
Date:   Sat Jun 25 12:56:49 2022 +0200

    fbcon: Disallow setting font bigger than screen size
    
    commit 65a01e601dbba8b7a51a2677811f70f783766682 upstream.
    
    Prevent that users set a font size which is bigger than the physical screen.
    It's unlikely this may happen (because screens are usually much larger than the
    fonts and each font char is limited to 32x32 pixels), but it may happen on
    smaller screens/LCD displays.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: stable@vger.kernel.org # v4.14+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dc85f33d96bfdf37c33044abfcdd51fbfe1f50b
Author: Yian Chen <yian.chen@intel.com>
Date:   Fri May 20 17:21:15 2022 -0700

    iommu/vt-d: Fix PCI bus rescan device hot add
    
    commit 316f92a705a4c2bf4712135180d56f3cca09243a upstream.
    
    Notifier calling chain uses priority to determine the execution
    order of the notifiers or listeners registered to the chain.
    PCI bus device hot add utilizes the notification mechanism.
    
    The current code sets low priority (INT_MIN) to Intel
    dmar_pci_bus_notifier and postpones DMAR decoding after adding
    new device into IOMMU. The result is that struct device pointer
    cannot be found in DRHD search for the new device's DMAR/IOMMU.
    Subsequently, the device is put under the "catch-all" IOMMU
    instead of the correct one. This could cause system hang when
    device TLB invalidation is sent to the wrong IOMMU. Invalidation
    timeout error and hard lockup have been observed and data
    inconsistency/crush may occur as well.
    
    This patch fixes the issue by setting a positive priority(1) for
    dmar_pci_bus_notifier while the priority of IOMMU bus notifier
    uses the default value(0), therefore DMAR decoding will be in
    advance of DRHD search for a new device to find the correct IOMMU.
    
    Following is a 2-step example that triggers the bug by simulating
    PCI device hot add behavior in Intel Sapphire Rapids server.
    
    echo 1 > /sys/bus/pci/devices/0000:6a:01.0/remove
    echo 1 > /sys/bus/pci/rescan
    
    Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope")
    Cc: stable@vger.kernel.org # v3.15+
    Reported-by: Zhang, Bernice <bernice.zhang@intel.com>
    Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Signed-off-by: Yian Chen <yian.chen@intel.com>
    Link: https://lore.kernel.org/r/20220521002115.1624069-1-yian.chen@intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f89c7ae9025dd547b233089e8f928903ef2cbf6a
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Tue Jul 5 20:56:10 2022 +0800

    net: rose: fix UAF bug caused by rose_t0timer_expiry
    
    commit 148ca04518070910739dfc4eeda765057856403d upstream.
    
    There are UAF bugs caused by rose_t0timer_expiry(). The
    root cause is that del_timer() could not stop the timer
    handler that is running and there is no synchronization.
    One of the race conditions is shown below:
    
        (thread 1)             |        (thread 2)
                               | rose_device_event
                               |   rose_rt_device_down
                               |     rose_remove_neigh
    rose_t0timer_expiry        |       rose_stop_t0timer(rose_neigh)
      ...                      |         del_timer(&neigh->t0timer)
                               |         kfree(rose_neigh) //[1]FREE
      neigh->dce_mode //[2]USE |
    
    The rose_neigh is deallocated in position [1] and use in
    position [2].
    
    The crash trace triggered by POC is like below:
    
    BUG: KASAN: use-after-free in expire_timers+0x144/0x320
    Write of size 8 at addr ffff888009b19658 by task swapper/0/0
    ...
    Call Trace:
     <IRQ>
     dump_stack_lvl+0xbf/0xee
     print_address_description+0x7b/0x440
     print_report+0x101/0x230
     ? expire_timers+0x144/0x320
     kasan_report+0xed/0x120
     ? expire_timers+0x144/0x320
     expire_timers+0x144/0x320
     __run_timers+0x3ff/0x4d0
     run_timer_softirq+0x41/0x80
     __do_softirq+0x233/0x544
     ...
    
    This patch changes rose_stop_ftimer() and rose_stop_t0timer()
    in rose_remove_neigh() to del_timer_sync() in order that the
    timer handler could be finished before the resources such as
    rose_neigh and so on are deallocated. As a result, the UAF
    bugs could be mitigated.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220705125610.77971-1-duoming@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5269209f54dd8dfd15f9383f3a3a1fe8370764f8
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Jul 5 14:53:51 2022 +0200

    usbnet: fix memory leak in error case
    
    commit b55a21b764c1e182014630fa5486d717484ac58f upstream.
    
    usbnet_write_cmd_async() mixed up which buffers
    need to be freed in which error case.
    
    v2: add Fixes tag
    v3: fix uninitialized buf pointer
    
    Fixes: 877bd862f32b8 ("usbnet: introduce usbnet 3 command helpers")
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20220705125351.17309-1-oneukum@suse.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1d806bc29ff7ffe0e2a023583c8720ed96cb0b0
Author: Rhett Aultman <rhett.aultman@samsara.com>
Date:   Sun Jul 3 19:33:06 2022 +0200

    can: gs_usb: gs_usb_open/close(): fix memory leak
    
    commit 2bda24ef95c0311ab93bda00db40486acf30bd0a upstream.
    
    The gs_usb driver appears to suffer from a malady common to many USB
    CAN adapter drivers in that it performs usb_alloc_coherent() to
    allocate a number of USB request blocks (URBs) for RX, and then later
    relies on usb_kill_anchored_urbs() to free them, but this doesn't
    actually free them. As a result, this may be leaking DMA memory that's
    been used by the driver.
    
    This commit is an adaptation of the techniques found in the esd_usb2
    driver where a similar design pattern led to a memory leak. It
    explicitly frees the RX URBs and their DMA memory via a call to
    usb_free_coherent(). Since the RX URBs were allocated in the
    gs_can_open(), we remove them in gs_can_close() rather than in the
    disconnect function as was done in esd_usb2.
    
    For more information, see the 928150fad41b ("can: esd_usb2: fix memory
    leak").
    
    Link: https://lore.kernel.org/all/alpine.DEB.2.22.394.2206031547001.1630869@thelappy
    Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
    Cc: stable@vger.kernel.org
    Signed-off-by: Rhett Aultman <rhett.aultman@samsara.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e92fc73066e80b6fff179c07f879a24e2702afb
Author: Liang He <windhl@126.com>
Date:   Sun Jun 19 15:02:57 2022 +0800

    can: grcan: grcan_probe(): remove extra of_node_get()
    
    commit 562fed945ea482833667f85496eeda766d511386 upstream.
    
    In grcan_probe(), of_find_node_by_path() has already increased the
    refcount. There is no need to call of_node_get() again, so remove it.
    
    Link: https://lore.kernel.org/all/20220619070257.4067022-1-windhl@126.com
    Fixes: 1e93ed26acf0 ("can: grcan: grcan_probe(): fix broken system id check for errata workaround needs")
    Cc: stable@vger.kernel.org # v5.18
    Cc: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d6a597450e686d4c6388bd3cdcb17224b4dae7f0
Author: Jann Horn <jannh@google.com>
Date:   Wed Jun 8 20:22:05 2022 +0200

    mm/slub: add missing TID updates on slab deactivation
    
    commit eeaa345e128515135ccb864c04482180c08e3259 upstream.
    
    The fastpath in slab_alloc_node() assumes that c->slab is stable as long as
    the TID stays the same. However, two places in __slab_alloc() currently
    don't update the TID when deactivating the CPU slab.
    
    If multiple operations race the right way, this could lead to an object
    getting lost; or, in an even more unlikely situation, it could even lead to
    an object being freed onto the wrong slab's freelist, messing up the
    `inuse` counter and eventually causing a page to be freed to the page
    allocator while it still contains slab objects.
    
    (I haven't actually tested these cases though, this is just based on
    looking at the code. Writing testcases for this stuff seems like it'd be
    a pain...)
    
    The race leading to state inconsistency is (all operations on the same CPU
    and kmem_cache):
    
     - task A: begin do_slab_free():
        - read TID
        - read pcpu freelist (==NULL)
        - check `slab == c->slab` (true)
     - [PREEMPT A->B]
     - task B: begin slab_alloc_node():
        - fastpath fails (`c->freelist` is NULL)
        - enter __slab_alloc()
        - slub_get_cpu_ptr() (disables preemption)
        - enter ___slab_alloc()
        - take local_lock_irqsave()
        - read c->freelist as NULL
        - get_freelist() returns NULL
        - write `c->slab = NULL`
        - drop local_unlock_irqrestore()
        - goto new_slab
        - slub_percpu_partial() is NULL
        - get_partial() returns NULL
        - slub_put_cpu_ptr() (enables preemption)
     - [PREEMPT B->A]
     - task A: finish do_slab_free():
        - this_cpu_cmpxchg_double() succeeds()
        - [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL]
    
    From there, the object on c->freelist will get lost if task B is allowed to
    continue from here: It will proceed to the retry_load_slab label,
    set c->slab, then jump to load_freelist, which clobbers c->freelist.
    
    But if we instead continue as follows, we get worse corruption:
    
     - task A: run __slab_free() on object from other struct slab:
        - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial)
     - task A: run slab_alloc_node() with NUMA node constraint:
        - fastpath fails (c->slab is NULL)
        - call __slab_alloc()
        - slub_get_cpu_ptr() (disables preemption)
        - enter ___slab_alloc()
        - c->slab is NULL: goto new_slab
        - slub_percpu_partial() is non-NULL
        - set c->slab to slub_percpu_partial(c)
        - [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects
          from slab-2]
        - goto redo
        - node_match() fails
        - goto deactivate_slab
        - existing c->freelist is passed into deactivate_slab()
        - inuse count of slab-1 is decremented to account for object from
          slab-2
    
    At this point, the inuse count of slab-1 is 1 lower than it should be.
    This means that if we free all allocated objects in slab-1 except for one,
    SLUB will think that slab-1 is completely unused, and may free its page,
    leading to use-after-free.
    
    Fixes: c17dda40a6a4e ("slub: Separate out kmem_cache_cpu processing from deactivate_slab")
    Fixes: 03e404af26dc2 ("slub: fast release on full slab")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: Christoph Lameter <cl@linux.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Reviewed-by: Muchun Song <songmuchun@bytedance.com>
    Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Link: https://lore.kernel.org/r/20220608182205.2945720-1-jannh@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c66b0c95bb0aa7652ba1eba293d0d5993b35a38
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Wed Apr 13 10:10:50 2022 +0200

    esp: limit skb_page_frag_refill use to a single page
    
    commit 5bd8baab087dff657e05387aee802e70304cc813 upstream.
    
    Commit ebe48d368e97 ("esp: Fix possible buffer overflow in ESP
    transformation") tried to fix skb_page_frag_refill usage in ESP by
    capping allocsize to 32k, but that doesn't completely solve the issue,
    as skb_page_frag_refill may return a single page. If that happens, we
    will write out of bounds, despite the check introduced in the previous
    patch.
    
    This patch forces COW in cases where we would end up calling
    skb_page_frag_refill with a size larger than a page (first in
    esp_output_head with tailen, then in esp_output_tail with
    skb->data_len).
    
    Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
    Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>