[sync] PR-372: Backport 5.10.141 LTS · Pull Request !373 · openEuler/kernel

### 1. Origin pull request:
https://gitee.com/openeuler/kernel/pulls/372

### 2. Original pull request related issue(s):
https://gitee.com/openeuler/kernel/issues/I685FC

### 3. Original pull request related commit(s):
| Sha | Datetime | Message |
|---|---|---|
|[4d958c70](https://gitee.com/openeuler/kernel/commits/4d958c7087e4cd50827c21992a06007cf179bf78)|2023-01-31 21:28:17 +0800 CST|net: neigh: don't call kfree_skb() under spin_lock_irqsave() stable inclusion from stable-v5.10.141 commit bdc786d737ec0eac92131d76372cd7f29c1e02e6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bdc786d737ec0eac92131d76372cd7f29c1e02e6 -------------------------------- commit d5485d9dd24e1d04e5509916515260186eb1455c upstream. It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So add all skb to a tmp list, then free them after spin_unlock_irqrestore() at once. Fixes: 66ba215cb513 ("neigh: fix possible DoS due to net iface start/stop loop") Suggested-by: Denis V. Lunev <den@openvz.org> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[de35b02b](https://gitee.com/openeuler/kernel/commits/de35b02b735709c5a222923c16da6638f369c837)|2023-01-31 21:28:16 +0800 CST|net/af_packet: check len when min_header_len equals to 0 stable inclusion from stable-v5.10.141 commit 4931af31c402b20c528b43d90f98bc6f4bcb5810 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4931af31c402b20c528b43d90f98bc6f4bcb5810 -------------------------------- commit dc633700f00f726e027846a318c5ffeb8deaaeda upstream. User can use AF_PACKET socket to send packets with the length of 0. When min_header_len equals to 0, packet_snd will call __dev_queue_xmit to send packets, and sock->type can be any type. Reported-by: syzbot+5ea725c25d06fb9114c4@syzkaller.appspotmail.com Fixes: fd1894224407 ("bpf: Don't redirect packets with invalid pkt_len") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[eb6b523c](https://gitee.com/openeuler/kernel/commits/eb6b523c1af155404d032955c37a2b2a8b68b399)|2023-01-31 21:28:15 +0800 CST|lib/vdso: Mark do_hres_timens() and do_coarse_timens() __always_inline() stable inclusion from stable-v5.10.141 commit 8c70cce8923187693a608d2b56600ec529915f7b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c70cce8923187693a608d2b56600ec529915f7b -------------------------------- [ Upstream commit 58efe9f696cf908f40d6672aeca81cb2ad2bc762 ] In the same spirit as commit c966533f8c6c ("lib/vdso: Mark do_hres() and do_coarse() as __always_inline"), mark do_hres_timens() and do_coarse_timens() __always_inline. The measurement below in on a non timens process, ie on the fastest path. On powerpc32, without the patch: clock-gettime-monotonic-raw: vdso: 1155 nsec/call clock-gettime-monotonic-coarse: vdso: 813 nsec/call clock-gettime-monotonic: vdso: 1076 nsec/call With the patch: clock-gettime-monotonic-raw: vdso: 1100 nsec/call clock-gettime-monotonic-coarse: vdso: 667 nsec/call clock-gettime-monotonic: vdso: 1025 nsec/call Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/90dcf45ebadfd5a07f24241551c62f619d1cb930.1617209142.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[c5d6b429](https://gitee.com/openeuler/kernel/commits/c5d6b429a4ab852251ccabce1ea5eed7ac110852)|2023-01-31 21:28:14 +0800 CST|netfilter: conntrack: NF_CONNTRACK_PROCFS should no longer default to y stable inclusion from stable-v5.10.141 commit 6ba9e8fb47f6300a9245dff61256cd476a58838b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6ba9e8fb47f6300a9245dff61256cd476a58838b -------------------------------- [ Upstream commit aa5762c34213aba7a72dc58e70601370805fa794 ] NF_CONNTRACK_PROCFS was marked obsolete in commit 54b07dca68557b09 ("netfilter: provide config option to disable ancient procfs parts") in v3.3. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[9d5526da](https://gitee.com/openeuler/kernel/commits/9d5526da5206719a3c25cb1d22bb74404a10fc42)|2023-01-31 21:28:13 +0800 CST|drm/amdgpu: Increase tlb flush timeout for sriov stable inclusion from stable-v5.10.141 commit afa169f79d479edb23f1a727a37265a25d5a1e8e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=afa169f79d479edb23f1a727a37265a25d5a1e8e -------------------------------- [ Upstream commit 373008bfc9cdb0f050258947fa5a095f0657e1bc ] [Why] During multi-vf executing benchmark (Luxmark) observed kiq error timeout. It happenes because all of VFs do the tlb invalidation at the same time. Although each VF has the invalidate register set, from hardware side the invalidate requests are queue to execute. [How] In case of 12 VF increase timeout on 12*100ms Signed-off-by: Dusica Milinkovic <Dusica.Milinkovic@amd.com> Acked-by: Shaoyun Liu <shaoyun.liu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[162ee5e0](https://gitee.com/openeuler/kernel/commits/162ee5e0b0a36c4ca25d1c8be4b24fb75f6bd6ff)|2023-01-31 21:28:12 +0800 CST|drm/amd/display: Fix pixel clock programming stable inclusion from stable-v5.10.141 commit f08a3712bac80bbf73dfc064c064b427804dcf3e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f08a3712bac80bbf73dfc064c064b427804dcf3e -------------------------------- [ Upstream commit 04fb918bf421b299feaee1006e82921d7d381f18 ] [Why] Some pixel clock values could cause HDMI TMDS SSCPs to be misaligned between different HDMI lanes when using YCbCr420 10-bit pixel format. BIOS functions for transmitter/encoder control take pixel clock in kHz increments, whereas the function for setting the pixel clock is in 100Hz increments. Setting pixel clock to a value that is not on a kHz boundary will cause the issue. [How] Round pixel clock down to nearest kHz in 10/12-bpc cases. Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Brian Chang <Brian.Chang@amd.com> Signed-off-by: Ilya Bakoulin <Ilya.Bakoulin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[487d5e36](https://gitee.com/openeuler/kernel/commits/487d5e36ecc7999718c4d6a37ef59bca3bb82f8a)|2023-01-31 21:28:11 +0800 CST|drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid stable inclusion from stable-v5.10.141 commit 60d522f317078381ff8a3599fe808f96fc256cd5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=60d522f317078381ff8a3599fe808f96fc256cd5 -------------------------------- [ Upstream commit 0a2d922a5618377cdf8fa476351362733ef55342 ] To avoid any potential memory leak. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[e5160b5e](https://gitee.com/openeuler/kernel/commits/e5160b5e02b7064121ab2c72e7a67d6fe0a6433a)|2023-01-31 21:28:10 +0800 CST|s390/hypfs: avoid error message under KVM stable inclusion from stable-v5.10.141 commit f2b7b8b1c4139d0c3de9e90a30a9259eee8a8f34 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f2b7b8b1c4139d0c3de9e90a30a9259eee8a8f34 -------------------------------- [ Upstream commit 7b6670b03641ac308aaa6fa2e6f964ac993b5ea3 ] When booting under KVM the following error messages are issued: hypfs.7f5705: The hardware system does not support hypfs hypfs.7a79f0: Initialization of hypfs failed with rc=-61 Demote the severity of first message from "error" to "info" and issue the second message only in other error cases. Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Link: https://lore.kernel.org/r/20220620094534.18967-1-jgross@suse.com [arch/s390/hypfs/hypfs_diag.c changed description] Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[f15147a7](https://gitee.com/openeuler/kernel/commits/f15147a7f2d449fa2641e843846267e4d4eebb02)|2023-01-31 21:28:09 +0800 CST|neigh: fix possible DoS due to net iface start/stop loop stable inclusion from stable-v5.10.141 commit c35adafe42bd6c3bf2aca0a3f523dabc38fc23c8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c35adafe42bd6c3bf2aca0a3f523dabc38fc23c8 -------------------------------- [ Upstream commit 66ba215cb51323e4e55e38fd5f250e0fae0cbc94 ] Normal processing of ARP request (usually this is Ethernet broadcast packet) coming to the host is looking like the following: * the packet comes to arp_process() call and is passed through routing procedure * the request is put into the queue using pneigh_enqueue() if corresponding ARP record is not local (common case for container records on the host) * the request is processed by timer (within 80 jiffies by default) and ARP reply is sent from the same arp_process() using NEIGH_CB(skb)->flags & LOCALLY_ENQUEUED condition (flag is set inside pneigh_enqueue()) And here the problem comes. Linux kernel calls pneigh_queue_purge() which destroys the whole queue of ARP requests on ANY network interface start/stop event through __neigh_ifdown(). This is actually not a problem within the original world as network interface start/stop was accessible to the host 'root' only, which could do more destructive things. But the world is changed and there are Linux containers available. Here container 'root' has an access to this API and could be considered as untrusted user in the hosting (container's) world. Thus there is an attack vector to other containers on node when container's root will endlessly start/stop interfaces. We have observed similar situation on a real production node when docker container was doing such activity and thus other containers on the node become not accessible. The patch proposed doing very simple thing. It drops only packets from the same namespace in the pneigh_queue_purge() where network interface state change is detected. This is enough to prevent the problem for the whole node preserving original semantics of the code. v2: 	- do del_timer_sync() if queue is empty after pneigh_queue_purge() v3: 	- rebase to net tree Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: David Ahern <dsahern@kernel.org> Cc: Yajun Deng <yajun.deng@linux.dev> Cc: Roopa Prabhu <roopa@nvidia.com> Cc: Christian Brauner <brauner@kernel.org> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com> Cc: Konstantin Khorenko <khorenko@virtuozzo.com> Cc: kernel@openvz.org Cc: devel@openvz.org Investigated-by: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[0669b3dd](https://gitee.com/openeuler/kernel/commits/0669b3dd59f5f53d43328469a45a91caec7d7d4a)|2023-01-31 21:28:08 +0800 CST|drm/amd/display: clear optc underflow before turn off odm clock stable inclusion from stable-v5.10.141 commit 3c1dfeaeb3b4e3ea656041da1241e6ee3c3b3202 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3c1dfeaeb3b4e3ea656041da1241e6ee3c3b3202 -------------------------------- [ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ] [Why] After ODM clock off, optc underflow bit will be kept there always and clear not work. We need to clear that before clock off. [How] Clear that if have when clock off. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Fudong Wang <Fudong.Wang@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[0ab44b5d](https://gitee.com/openeuler/kernel/commits/0ab44b5d26054b07a7666d53710584c5eb24e56d)|2023-01-31 21:28:07 +0800 CST|drm/amd/display: For stereo keep "FLIP_ANY_FRAME" stable inclusion from stable-v5.10.141 commit 4e5e67b13a040baff5ec265ae32b754e4776d723 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4e5e67b13a040baff5ec265ae32b754e4776d723 -------------------------------- [ Upstream commit 84ef99c728079dfd21d6bc70b4c3e4af20602b3c ] [Description] Observed in stereomode that programming FLIP_LEFT_EYE can cause hangs. Keep FLIP_ANY_FRAME in stereo mode so the surface flip can take place before left or right eye Reviewed-by: Martin Leung <Martin.Leung@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Alvin Lee <alvin.lee2@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[aefb6ed3](https://gitee.com/openeuler/kernel/commits/aefb6ed3384fb3674f2725ce003f060520f1cc7a)|2023-01-31 21:28:06 +0800 CST|drm/amd/display: Avoid MPC infinite loop stable inclusion from stable-v5.10.141 commit 828b2a5399aa46a44b7be2615240016d7883fa0b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=828b2a5399aa46a44b7be2615240016d7883fa0b -------------------------------- [ Upstream commit 8de297dc046c180651c0500f8611663ae1c3828a ] [why] In some cases MPC tree bottom pipe ends up point to itself. This causes iterating from top to bottom to hang the system in an infinite loop. [how] When looping to next MPC bottom pipe, check that the pointer is not same as current to avoid infinite loop. Reviewed-by: Josip Pavic <Josip.Pavic@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[a12e69f4](https://gitee.com/openeuler/kernel/commits/a12e69f4eee35afea97cf81f5eedad6758ec03dc)|2023-01-31 21:28:05 +0800 CST|mmc: mtk-sd: Clear interrupts when cqe off/disable stable inclusion from stable-v5.10.141 commit 9d36e2c264f7c7be02b0fb903871220782f041c0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9d36e2c264f7c7be02b0fb903871220782f041c0 -------------------------------- [ Upstream commit cc5d1692600613e72f32af60e27330fe0c79f4fe ] Currently we don't clear MSDC interrupts when cqe off/disable, which led to the data complete interrupt will be reserved for the next command. If the next command with data transfer after cqe off/disable, we process the CMD ready interrupt and trigger DMA start for data, but the data complete interrupt is already exists, then SW assume that the data transfer is complete, SW will trigger DMA stop, but the data may not be transmitted yet or is transmitting, so we may encounter the following error: mtk-msdc 11230000.mmc: CMD bus busy detected. Signed-off-by: Wenbin Mei <wenbin.mei@mediatek.com> Fixes: 88bd652b3c74 ("mmc: mediatek: command queue support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220728080048.21336-1-wenbin.mei@mediatek.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[bfe5e2e4](https://gitee.com/openeuler/kernel/commits/bfe5e2e4b9157206d5cfbadde027fb07fd522343)|2023-01-31 21:28:04 +0800 CST|ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead stable inclusion from stable-v5.10.141 commit dbd8c8fc60480e3faa3ae7e27ebe03371ecd1b77 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=dbd8c8fc60480e3faa3ae7e27ebe03371ecd1b77 -------------------------------- commit c3b0f72e805f0801f05fa2aa52011c4bfc694c44 upstream. ftrace_startup does not remove ops from ftrace_ops_list when ftrace_startup_enable fails: register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&ftrace_ops_list, ops) ... ... ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1 ... return 0 // ops is in the ftrace_ops_list. When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything: unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // return here, __unregister_ftrace_function is not executed, // as a result, ops is still in the ftrace_ops_list __unregister_ftrace_function ... If ops is dynamically allocated, it will be free later, in this case, is_ftrace_trampoline accesses NULL pointer: is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL! Syzkaller reports as follows: [ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b [ 1203.508039] #PF: supervisor read access in kernel mode [ 1203.508798] #PF: error_code(0x0000) - not-present page [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8 [ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866 [ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399 [ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Therefore, when ftrace_startup_enable fails, we need to rollback registration process and remove ops from ftrace_ops_list. Link: https://lkml.kernel.org/r/20220818032659.56209-1-yangjihong1@huawei.com Suggested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Yang Jihong <yangjihong1@huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[d2aa1002](https://gitee.com/openeuler/kernel/commits/d2aa10021857afbe44bea165223b5ed8372593b6)|2023-01-31 21:28:03 +0800 CST|fbdev: fb_pm2fb: Avoid potential divide by zero error stable inclusion from stable-v5.10.141 commit 8fc778ee2fb2853f7a3531fa7273349640d8e4e9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8fc778ee2fb2853f7a3531fa7273349640d8e4e9 -------------------------------- commit 19f953e7435644b81332dd632ba1b2d80b1e37af upstream. In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be copied from user, then go through `fb_set_var()` and `info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`. Along the path, `var->pixclock` won't be modified. This function checks whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is zero, there will be a divide by zero error. So, it is necessary to check whether denominator is zero to avoid crash. As this bug is found by Syzkaller, logs are listed below. divide error in pm2fb_check_var Call Trace: <TASK> fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Reported-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Letu Ren <fantasquex@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[0ef4377b](https://gitee.com/openeuler/kernel/commits/0ef4377bd1d22c995d9c091caab24c8e176102f1)|2023-01-31 21:28:02 +0800 CST|net: fix refcount bug in sk_psock_get (2) stable inclusion from stable-v5.10.141 commit 61cc798591a36ca27eb7d8d6c09bf20e50a59968 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=61cc798591a36ca27eb7d8d6c09bf20e50a59968 -------------------------------- commit 2a0133723f9ebeb751cfce19f74ec07e108bef1f upstream. Syzkaller reports refcount bug as follows: ------------[ cut here ]------------ refcount_t: saturated; leaking memory. WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19 Modules linked in: CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 <TASK> __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> During SMC fallback process in connect syscall, kernel will replaces TCP with SMC. In order to forward wakeup smc socket waitqueue after fallback, kernel will sets clcsk->sk_user_data to origin smc socket in smc_fback_replace_callbacks(). Later, in shutdown syscall, kernel will calls sk_psock_get(), which treats the clcsk->sk_user_data as psock type, triggering the refcnt warning. So, the root cause is that smc and psock, both will use sk_user_data field. So they will mismatch this field easily. This patch solves it by using another bit(defined as SK_USER_DATA_PSOCK) in PTRMASK, to mark whether sk_user_data points to a psock object or not. This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e ("net, sk_msg: Clear sk_user_data pointer on clone if tagged"). For there will possibly be more flags in the sk_user_data field, this patch also refactor sk_user_data flags code to be more generic to improve its maintainability. Reported-and-tested-by: syzbot+5f26f85569bd179c18ce@syzkaller.appspotmail.com Suggested-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Wen Gu <guwen@linux.alibaba.com> Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[6abc68f8](https://gitee.com/openeuler/kernel/commits/6abc68f87b364737bf07503959f2ec7f8e338ec3)|2023-01-31 21:28:01 +0800 CST|HID: hidraw: fix memory leak in hidraw_release() stable inclusion from stable-v5.10.141 commit 7e2fa79226580b035b00260d9f240ab9bda4af5d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7e2fa79226580b035b00260d9f240ab9bda4af5d -------------------------------- commit a5623a203cffe2d2b84d2f6c989d9017db1856af upstream. Free the buffered reports before deleting the list entry. BUG: memory leak unreferenced object 0xffff88810e72f180 (size 32): comm "softirq", pid 0, jiffies 4294945143 (age 16.080s) hex dump (first 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128 [<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline] [<ffffffff8357c1d2>] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521 [<ffffffff8356ddad>] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992 [<ffffffff8356e41e>] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065 [<ffffffff835f0d3f>] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [<ffffffff82d3c7f9>] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [<ffffffff82d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988 [<ffffffff812f50a8>] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [<ffffffff812f5586>] expire_timers kernel/time/timer.c:1519 [inline] [<ffffffff812f5586>] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790 [<ffffffff812f56e4>] __run_timers kernel/time/timer.c:1768 [inline] [<ffffffff812f56e4>] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803 [<ffffffff848000e6>] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline] [<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.c:650 [inline] [<ffffffff81246db0>] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [<ffffffff84574f02>] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106 [<ffffffff84600c8b>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649 [<ffffffff8458a070>] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] [<ffffffff8458a070>] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] [<ffffffff8458a070>] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline] [<ffffffff8458a070>] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554 Link: https://syzkaller.appspot.com/bug?id=19a04b43c75ed1092021010419b5e560a8172c4f Reported-by: syzbot+f59100a0428e6ded9443@syzkaller.appspotmail.com Signed-off-by: Karthik Alapati <mail@karthek.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[4bb3418e](https://gitee.com/openeuler/kernel/commits/4bb3418e1222ca4e0456e920c06ca64c5e20461f)|2023-01-31 21:28:00 +0800 CST|udmabuf: Set the DMA mask for the udmabuf device (v2) stable inclusion from stable-v5.10.141 commit 872875c9ecf8fa2e1d82bb2f2f1963f571aa8959 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=872875c9ecf8fa2e1d82bb2f2f1963f571aa8959 -------------------------------- commit 9e9fa6a9198b767b00f48160800128e83a038f9f upstream. If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek.kasireddy@intel.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[c9d1231b](https://gitee.com/openeuler/kernel/commits/c9d1231b6c4d765954d57948d76ba7c9e741e0b4)|2023-01-31 21:27:59 +0800 CST|HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report stable inclusion from stable-v5.10.141 commit dc815761948ab5b8c94db6cb53c95103588f16ae category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=dc815761948ab5b8c94db6cb53c95103588f16ae -------------------------------- commit cd11d1a6114bd4bc6450ae59f6e110ec47362126 upstream. It is possible for a malicious device to forgo submitting a Feature Report. The HID Steam driver presently makes no prevision for this and de-references the 'struct hid_report' pointer obtained from the HID devices without first checking its validity. Let's change that. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Fixes: c164d6abf3841 ("HID: add driver for Valve Steam Controller") Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[141da59f](https://gitee.com/openeuler/kernel/commits/141da59fdd6fa9c1ef278157dfad4fe5d55cda1c)|2023-01-31 21:27:58 +0800 CST|Revert "PCI/portdrv: Don't disable AER reporting in get_port_device_capability()" stable inclusion from stable-v5.10.141 commit 412b844143e351ea803c17ecc6675552f3ca771b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=412b844143e351ea803c17ecc6675552f3ca771b -------------------------------- This reverts commit ee70aa214a2d9fa74539b52f6c326ba2f7c0fb11 which is commit 8795e182b02dc87e343c79e73af6b8b7f9c5e635 upstream. It is reported to cause problems, so drop it from the stable trees for now until it gets sorted out. Link: https://lore.kernel.org/r/47b775c5-57fa-5edf-b59e-8a9041ffbee7@candelatech.com Reported-by: Ben Greear <greearb@candelatech.com> Cc: Stefan Roese <sr@denx.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Pali Rohár <pali@kernel.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Yao Hongbo <yaohongbo@linux.alibaba.com> Cc: Naveen Naidu <naveennaidu479@gmail.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[667ba256](https://gitee.com/openeuler/kernel/commits/667ba25692e2fc0f8d38bae19ce6914c1ae11f95)|2023-01-31 21:27:57 +0800 CST|kbuild: Fix include path in scripts/Makefile.modpost stable inclusion from stable-v5.10.141 commit ad697ade5939b5a40eb65b557083d083cf129790 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ad697ade5939b5a40eb65b557083d083cf129790 -------------------------------- commit 23a0cb8e3225122496bfa79172005c587c2d64bf upstream. When building an external module, if users don't need to separate the compilation output and source code, they run the following command: "make -C $(LINUX_SRC_DIR) M=$(PWD)". At this point, "$(KBUILD_EXTMOD)" and "$(src)" are the same. If they need to separate them, they run "make -C $(KERNEL_SRC_DIR) O=$(KERNEL_OUT_DIR) M=$(OUT_DIR) src=$(PWD)". Before running the command, they need to copy "Kbuild" or "Makefile" to "$(OUT_DIR)" to prevent compilation failure. So the kernel should change the included path to avoid the copy operation. Signed-off-by: Jing Leng <jleng@ambarella.com> [masahiro: I do not think "M=$(OUT_DIR) src=$(PWD)" is the official way, but this patch is a nice clean up anyway.] Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nicolas Schier <n.schier@avm.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[618290bf](https://gitee.com/openeuler/kernel/commits/618290bf6e2d77523d520f74510ba25a0888d9a7)|2023-01-31 21:27:56 +0800 CST|s390/mm: do not trigger write fault when vma does not allow VM_WRITE stable inclusion from stable-v5.10.141 commit b9feeb610099d01805f24b9f5a72e4abb2fe18d6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b9feeb610099d01805f24b9f5a72e4abb2fe18d6 -------------------------------- commit 41ac42f137080bc230b5882e3c88c392ab7f2d32 upstream. For non-protection pXd_none() page faults in do_dat_exception(), we call do_exception() with access == (VM_READ | VM_WRITE | VM_EXEC). In do_exception(), vma->vm_flags is checked against that before calling handle_mm_fault(). Since commit 92f842eac7ee3 ("[S390] store indication fault optimization"), we call handle_mm_fault() with FAULT_FLAG_WRITE, when recognizing that it was a write access. However, the vma flags check is still only checking against (VM_READ | VM_WRITE | VM_EXEC), and therefore also calling handle_mm_fault() with FAULT_FLAG_WRITE in cases where the vma does not allow VM_WRITE. Fix this by changing access check in do_exception() to VM_WRITE only, when recognizing write access. Link: https://lkml.kernel.org/r/20220811103435.188481-3-david@redhat.com Fixes: 92f842eac7ee3 ("[S390] store indication fault optimization") Cc: <stable@vger.kernel.org> Reported-by: David Hildenbrand <david@redhat.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[e9d3b652](https://gitee.com/openeuler/kernel/commits/e9d3b652bce70c4389be2e836e9f04567e82c950)|2023-01-31 21:27:55 +0800 CST|crypto: lib - remove unneeded selection of XOR_BLOCKS stable inclusion from stable-v5.10.141 commit 0dea6b3e22c67b37aeb1fca8fa5398fd38270f57 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0dea6b3e22c67b37aeb1fca8fa5398fd38270f57 -------------------------------- commit 874b301985ef2f89b8b592ad255e03fb6fbfe605 upstream. CRYPTO_LIB_CHACHA_GENERIC doesn't need to select XOR_BLOCKS. It perhaps was thought that it's needed for __crypto_xor, but that's not the case. Enabling XOR_BLOCKS is problematic because the XOR_BLOCKS code runs a benchmark when it is initialized. That causes a boot time regression on systems that didn't have it enabled before. Therefore, remove this unnecessary and problematic selection. Fixes: e56e18985596 ("lib/crypto: add prompts back to crypto libraries") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[bef64b59](https://gitee.com/openeuler/kernel/commits/bef64b598cc261f2bb2263ef4b2ae927a57e2e8d)|2023-01-31 21:27:54 +0800 CST|x86/nospec: Fix i386 RSB stuffing stable inclusion from stable-v5.10.141 commit e5796ff9acc5e922be3b1a599e004534e4fe23cf category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e5796ff9acc5e922be3b1a599e004534e4fe23cf -------------------------------- commit 332924973725e8cdcc783c175f68cf7e162cb9e5 upstream. Turns out that i386 doesn't unconditionally have LFENCE, as such the loop in __FILL_RETURN_BUFFER isn't actually speculation safe on such chips. Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence") Reported-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/Yv9tj9vbQ9nNlXoY@worktop.programming.kicks-ass.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |
|[4b944c0f](https://gitee.com/openeuler/kernel/commits/4b944c0fc78beb19540c2eb797a5c4867020a612)|2023-01-31 21:27:53 +0800 CST|x86/nospec: Unwreck the RSB stuffing stable inclusion from stable-v5.10.141 commit adee8f3082b01e5dab620d651e3ec75f57c0c855 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=adee8f3082b01e5dab620d651e3ec75f57c0c855 -------------------------------- commit 4e3aa9238277597c6c7624f302d81a7b568b6f2d upstream. Commit 2b1299322016 ("x86/speculation: Add RSB VM Exit protections") made a right mess of the RSB stuffing, rewrite the whole thing to not suck. Thanks to Andrew for the enlightening comment about Post-Barrier RSB things so we can make this code less magical. Cc: stable@vger.kernel.org Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/YvuNdDWoUZSBjYcm@worktop.programming.kicks-ass.net [bwh: Backported to 5.10: adjust context] Signed-off-by: Ben Hutchings <benh@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> |

GVPopenEuler/kernel

搜索帮助

GVP openEuler/kernel