提交 · b765edbdfb543ddc77840523be9bbd4ba11a8b68 · openeuler / Kernel

19 10月, 2021 40 次提交

net: xfrm: Fix end of loop tests for list_for_each_entry · b765edbd

由 Harshvardhan Jha 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit 505884a0c7a1c44e66690b975601220eace0868c
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=505884a0c7a1c44e66690b975601220eace0868c

--------------------------------

[ Upstream commit 480e93e1 ]

The list_for_each_entry() iterator, "pos" in this code, can never be
NULL so the warning will never be printed.
Signed-off-by: NHarshvardhan Jha <harshvardhan.jha@oracle.com>
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b765edbd

spi: spi-mux: Add module info needed for autoloading · ac1fd0da

由 Uwe Kleine-König 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit f1c0533fae5956d49f232255799b725c4b810abd
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f1c0533fae5956d49f232255799b725c4b810abd

--------------------------------

[ Upstream commit 1d5ccab9 ]

With the spi device table udev can autoload the spi-mux module in
the presence of an spi-mux device.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20210721095321.2165453-1-u.kleine-koenig@pengutronix.deSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ac1fd0da

dmaengine: usb-dmac: Fix PM reference leak in usb_dmac_probe() · e74a73b8

由 Yu Kuai 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit b618a32142c727c6d20240cc174900f1c08a71f9
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b618a32142c727c6d20240cc174900f1c08a71f9

--------------------------------

[ Upstream commit 1da569fa ]

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by moving the error_pm label above the pm_runtime_put() in
the error path.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20210706124521.1371901-1-yukuai3@huawei.comSigned-off-by: NVinod Koul <vkoul@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

e74a73b8

dmaengine: xilinx_dma: Fix read-after-free bug when terminating transfers · 879a5c41

由 Adrian Larumbe 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit c160df90b0ca35341341ee19d2430c9fb8847bfa
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c160df90b0ca35341341ee19d2430c9fb8847bfa

--------------------------------

[ Upstream commit 7dd2dd4f ]

When user calls dmaengine_terminate_sync, the driver will clean up any
remaining descriptors for all the pending or active transfers that had
previously been submitted. However, this might happen whilst the tasklet is
invoking the DMA callback for the last finished transfer, so by the time it
returns and takes over the channel's spinlock, the list of completed
descriptors it was traversing is no longer valid. This leads to a
read-after-free situation.

Fix it by signalling whether a user-triggered termination has happened by
means of a boolean variable.
Signed-off-by: NAdrian Larumbe <adrian.martinezlarumbe@imgtec.com>
Link: https://lore.kernel.org/r/20210706234338.7696-3-adrian.martinezlarumbe@imgtec.comSigned-off-by: NVinod Koul <vkoul@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

879a5c41

USB: core: Fix incorrect pipe calculation in do_proc_control() · 1822c2af

由 Alan Stern 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit d4930271a4096769c43eb103aaf7d3a043ae138e
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d4930271a4096769c43eb103aaf7d3a043ae138e

--------------------------------

[ Upstream commit b0863f19 ]

When the user submits a control URB via usbfs, the user supplies the
bRequestType value and the kernel uses it to compute the pipe value.
However, do_proc_control() performs this computation incorrectly in
the case where the bRequestType direction bit is set to USB_DIR_IN and
the URB's transfer length is 0: The pipe's direction is also set to IN
but it should be OUT, which is the direction the actual transfer will
use regardless of bRequestType.

Commit 5cc59c41 ("USB: core: WARN if pipe direction != setup
packet direction") added a check to compare the direction bit in the
pipe value to a control URB's actual direction and to WARN if they are
different.  This can be triggered by the incorrect computation
mentioned above, as found by syzbot.

This patch fixes the computation, thus avoiding the WARNing.

Reported-and-tested-by: syzbot+72af3105289dcb4c055b@syzkaller.appspotmail.com
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20210712185436.GB326369@rowland.harvard.eduSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

1822c2af

USB: core: Avoid WARNings for 0-length descriptor requests · 795769e3

由 Alan Stern 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit ba6c1b004ac5aaee418ce84acbecdc4d89a67bbe
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ba6c1b004ac5aaee418ce84acbecdc4d89a67bbe

--------------------------------

[ Upstream commit 60dfe484 ]

The USB core has utility routines to retrieve various types of
descriptors.  These routines will now provoke a WARN if they are asked
to retrieve 0 bytes (USB "receive" requests must not have zero
length), so avert this by checking the size argument at the start.

CC: Johan Hovold <johan@kernel.org>
Reported-and-tested-by: syzbot+7dbcd9ff34dc4ed45240@syzkaller.appspotmail.com
Reviewed-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20210607152307.GD1768031@rowland.harvard.eduSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

795769e3

KVM: X86: Fix warning caused by stale emulation context · 696d0b3f

由 Wanpeng Li 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit 8e100c72b6ded07d5900c20ca5ee5d0c6d9c4293
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8e100c72b6ded07d5900c20ca5ee5d0c6d9c4293

--------------------------------

[ Upstream commit da6393cd ]

Reported by syzkaller:

  WARNING: CPU: 7 PID: 10526 at linux/arch/x86/kvm//x86.c:7621 x86_emulate_instruction+0x41b/0x510 [kvm]
  RIP: 0010:x86_emulate_instruction+0x41b/0x510 [kvm]
  Call Trace:
   kvm_mmu_page_fault+0x126/0x8f0 [kvm]
   vmx_handle_exit+0x11e/0x680 [kvm_intel]
   vcpu_enter_guest+0xd95/0x1b40 [kvm]
   kvm_arch_vcpu_ioctl_run+0x377/0x6a0 [kvm]
   kvm_vcpu_ioctl+0x389/0x630 [kvm]
   __x64_sys_ioctl+0x8e/0xd0
   do_syscall_64+0x3c/0xb0
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Commit 4a1e10d5 ("KVM: x86: handle hardware breakpoints during emulation())
adds hardware breakpoints check before emulation the instruction and parts of
emulation context initialization, actually we don't have the EMULTYPE_NO_DECODE flag
here and the emulation context will not be reused. Commit c8848cee ("KVM: x86:
set ctxt->have_exception in x86_decode_insn()) triggers the warning because it
catches the stale emulation context has #UD, however, it is not during instruction
decoding which should result in EMULATION_FAILED. This patch fixes it by moving
the second part emulation context initialization into init_emulate_ctxt() and
before hardware breakpoints check. The ctxt->ud will be dropped by a follow-up
patch.

syzkaller source: https://syzkaller.appspot.com/x/repro.c?x=134683fdd00000

Reported-by: syzbot+71271244f206d17f6441@syzkaller.appspotmail.com
Fixes: 4a1e10d5 (KVM: x86: handle hardware breakpoints during emulation)
Signed-off-by: NWanpeng Li <wanpengli@tencent.com>
Reviewed-by: NSean Christopherson <seanjc@google.com>
Message-Id: <1622160097-37633-1-git-send-email-wanpengli@tencent.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

696d0b3f

KVM: x86: Factor out x86 instruction emulation with decoding · 0d7b3af7

由 Wei Huang 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit 47d4c799979996e512730de23a08c1d17dc373db
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=47d4c799979996e512730de23a08c1d17dc373db

--------------------------------

[ Upstream commit 4aa2691d ]

Move the instruction decode part out of x86_emulate_instruction() for it
to be used in other places. Also kvm_clear_exception_queue() is moved
inside the if-statement as it doesn't apply when KVM are coming back from
userspace.
Co-developed-by: NBandan Das <bsd@redhat.com>
Signed-off-by: NBandan Das <bsd@redhat.com>
Signed-off-by: NWei Huang <wei.huang2@amd.com>
Message-Id: <20210126081831.570253-2-wei.huang2@amd.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0d7b3af7

media: drivers/media/usb: fix memory leak in zr364xx_probe · 24d67ac8

由 Pavel Skripkin 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit ff2fc9e4aaa6551f5b4a4ba0a3a7ea89771694ac
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ff2fc9e4aaa6551f5b4a4ba0a3a7ea89771694ac

--------------------------------

[ Upstream commit 9c39be40 ]

syzbot reported memory leak in zr364xx_probe()[1].
The problem was in invalid error handling order.
All error conditions rigth after v4l2_ctrl_handler_init()
must call v4l2_ctrl_handler_free().

Reported-by: syzbot+efe9aefc31ae1e6f7675@syzkaller.appspotmail.com
Signed-off-by: NPavel Skripkin <paskripkin@gmail.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

24d67ac8

media: zr364xx: fix memory leaks in probe() · b3e997df

由 Dan Carpenter 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit 56320b1ad4d0c6a67ab42198c40b9f43a0ed8756
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=56320b1ad4d0c6a67ab42198c40b9f43a0ed8756

--------------------------------

[ Upstream commit ea354b6d ]

Syzbot discovered that the probe error handling doesn't clean up the
resources allocated in zr364xx_board_init().  There are several
related bugs in this code so I have re-written the error handling.

1)  Introduce a new function zr364xx_board_uninit() which cleans up
    the resources in zr364xx_board_init().
2)  In zr364xx_board_init() if the call to zr364xx_start_readpipe()
    fails then release the "cam->buffer.frame[i].lpvbits" memory
    before returning.  This way every function either allocates
    everything successfully or it cleans up after itself.
3)  Re-write the probe function so that each failure path goto frees
    the most recent allocation.  That way we don't free anything
    before it has been allocated and we can also verify that
    everything is freed.
4)  Originally, in the probe function the "cam->v4l2_dev.release"
    pointer was set to "zr364xx_release" near the start but I moved
    that assignment to the end, after everything had succeeded.  The
    release function was never actually called during the probe cleanup
    process, but with this change I wanted to make it clear that we
    don't want to call zr364xx_release() until everything is
    allocated successfully.

Next I re-wrote the zr364xx_release() function.  Ideally this would
have been a simple matter of copy and pasting the cleanup code from
probe and adding an additional call to video_unregister_device().  But
there are a couple quirks to note.

1)  The probe function does not call videobuf_mmap_free() and I don't
    know where the videobuf_mmap is allocated.  I left the code as-is to
    avoid introducing a bug in code I don't understand.
2)  The zr364xx_board_uninit() has a call to zr364xx_stop_readpipe()
    which is a change from the original behavior with regards to
    unloading the driver.  Calling zr364xx_stop_readpipe() on a stopped
    pipe is not a problem so this is safe and is potentially a bugfix.

Reported-by: syzbot+b4d54814b339b5c6bbd4@syzkaller.appspotmail.com
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b3e997df

media: zr364xx: propagate errors from zr364xx_start_readpipe() · 07a1e2f5

由 Evgeny Novikov 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit b5c7ec6d15af79c910a0b5b9acbf60016d8c344d
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b5c7ec6d15af79c910a0b5b9acbf60016d8c344d

--------------------------------

[ Upstream commit af0321a5 ]

zr364xx_start_readpipe() can fail but callers do not care about that.
This can result in various negative consequences. The patch adds missed
error handling.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NEvgeny Novikov <novikov@ispras.ru>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

07a1e2f5

mtd: cfi_cmdset_0002: fix crash when erasing/writing AMD cards · cefbc781

由 Andreas Persson 提交于 10月 19, 2021

stable inclusion
from stable-5.10.61
commit 779a0f4347a474cf4b503350f3eef682404b6779
bugzilla: 177029 https://gitee.com/openeuler/kernel/issues/I4EAXD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=779a0f4347a474cf4b503350f3eef682404b6779

--------------------------------

commit 2394e628 upstream.

Erasing an AMD linear flash card (AM29F016D) crashes after the first
sector has been erased. Likewise, writing to it crashes after two bytes
have been written. The reason is a missing check for a null pointer -
the cmdset_priv field is not set for this type of card.

Fixes: 4844ef80 ("mtd: cfi_cmdset_0002: Add support for polling status register")
Signed-off-by: NAndreas Persson <andreasp56@outlook.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/DB6P189MB05830B3530B8087476C5CFE4C1159@DB6P189MB0583.EURP189.PROD.OUTLOOK.COMSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

cefbc781

ath9k: Postpone key cache entry deletion for TXQ frames reference it · 7981126b