- 20 6月, 2023 3 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1098 PR sync from: Li Nan <linan122@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/4EEIPQOJKUZAK6RIRH5RREOILH6ZD3EC/ Link:https://gitee.com/openeuler/kernel/pulls/1165 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1162 PR sync from: Zhang Changzhong <zhangchangzhong@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/RIOXNQNOVQ5DSEVFMIG6YBDCEKDWMBOS/ Link:https://gitee.com/openeuler/kernel/pulls/1169 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/582 #I6NYW4 Fix a type cast bug in mm/oom Link:https://gitee.com/openeuler/kernel/pulls/1156 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 19 6月, 2023 2 次提交
-
-
由 Samuel Thibault 提交于
mainline inclusion from mainline-v6.2-rc7 commit 2b09d5d3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7C2TM CVE: CVE-2023-3161 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b09d5d364986f724f17001ccfe4126b9b43a0be -------------------------------- blit_x and blit_y are u32, so fbcon currently cannot support fonts larger than 32x32. The 32x32 case also needs shifting an unsigned int, to properly set bit 31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font", as reported on: http://lore.kernel.org/all/IA1PR07MB98308653E259A6F2CE94A4AFABCE9@IA1PR07MB9830.namprd07.prod.outlook.com Kernel Branch: 6.2.0-rc5-next-20230124 Kernel config: https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing Reproducer: https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharingReported-by: NSanan Hasanov <sanan.hasanov@Knights.ucf.edu> Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org> Fixes: 2d2699d9 ("fbcon: font setting should check limitation of driver") Cc: stable@vger.kernel.org Tested-by: NMiko Larsson <mikoxyzzz@gmail.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NHelge Deller <deller@gmx.de> Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com> (cherry picked from commit aa4e4b8d)
-
由 Stephen Brennan 提交于
mainline inclusion from mainline-v5.16-rc1 commit da4d6b9c category: bugfix bugzilla: 188892, https://gitee.com/openeuler/kernel/issues/I7CWJ7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=da4d6b9cf80ae5b0083f640133b85b68b53b6497 ---------------------------------------- Problem Description: When running running ~128 parallel instances of TZ=/etc/localtime ps -fe >/dev/null on a 128CPU machine, the %sys utilization reaches 97%, and perf shows the following code path as being responsible for heavy contention on the d_lockref spinlock: walk_component() lookup_fast() d_revalidate() pid_revalidate() // returns -ECHILD unlazy_child() lockref_get_not_dead(&nd->path.dentry->d_lockref) <-- contention The reason is that pid_revalidate() is triggering a drop from RCU to ref path walk mode. All concurrent path lookups thus try to grab a reference to the dentry for /proc/, before re-executing pid_revalidate() and then stepping into the /proc/$pid directory. Thus there is huge spinlock contention. This patch allows pid_revalidate() to execute in RCU mode, meaning that the path lookup can successfully enter the /proc/$pid directory while still in RCU mode. Later on, the path lookup may still drop into ref mode, but the contention will be much reduced at this point. By applying this patch, %sys utilization falls to around 85% under the same workload, and the number of ps processes executed per unit time increases by 3x-4x. Although this particular workload is a bit contrived, we have seen some large collections of eager monitoring scripts which produced similarly high %sys time due to contention in the /proc directory. As a result this patch, Al noted that several procfs methods which were only called in ref-walk mode could now be called from RCU mode. To ensure that this patch is safe, I audited all the inode get_link and permission() implementations, as well as dentry d_revalidate() implementations, in fs/proc. The purpose here is to ensure that they either are safe to call in RCU (i.e. don't sleep) or correctly bail out of RCU mode if they don't support it. My analysis shows that all at-risk procfs methods are safe to call under RCU, and thus this patch is safe. Procfs RCU-walk Analysis: This analysis is up-to-date with 5.15-rc3. When called under RCU mode, these functions have arguments as follows: * get_link() receives a NULL dentry pointer when called in RCU mode. * permission() receives MAY_NOT_BLOCK in the mode parameter when called from RCU. * d_revalidate() receives LOOKUP_RCU in flags. For the following functions, either they are trivially RCU safe, or they explicitly bail at the beginning of the function when they run: proc_ns_get_link (bails out) proc_get_link (RCU safe) proc_pid_get_link (bails out) map_files_d_revalidate (bails out) map_misc_d_revalidate (bails out) proc_net_d_revalidate (RCU safe) proc_sys_revalidate (bails out, also not under /proc/$pid) tid_fd_revalidate (bails out) proc_sys_permission (not under /proc/$pid) The remainder of the functions require a bit more detail: * proc_fd_permission: RCU safe. All of the body of this function is under rcu_read_lock(), except generic_permission() which declares itself RCU safe in its documentation string. * proc_self_get_link uses GFP_ATOMIC in the RCU case, so it is RCU aware and otherwise looks safe. The same is true of proc_thread_self_get_link. * proc_map_files_get_link: calls ns_capable, which calls capable(), and thus calls into the audit code (see note #1 below). The remainder is just a call to the trivially safe proc_pid_get_link(). * proc_pid_permission: calls ptrace_may_access(), which appears RCU safe, although it does call into the "security_ptrace_access_check()" hook, which looks safe under smack and selinux. Just the audit code is of concern. Also uses get_task_struct() and put_task_struct(), see note #2 below. * proc_tid_comm_permission: Appears safe, though calls put_task_struct (see note #2 below). Note #1: Most of the concern of RCU safety has centered around the audit code. However, since b17ec22f ("selinux: slow_avc_audit has become non-blocking"), it's safe to call this code under RCU. So all of the above are safe by my estimation. Note #2: get_task_struct() and put_task_struct(): The majority of get_task_struct() is under RCU read lock, and in any case it is a simple increment. But put_task_struct() is complex, given that it could at some point free the task struct, and this process has many steps which I couldn't manually verify. However, several other places call put_task_struct() under RCU, so it appears safe to use here too (see kernel/hung_task.c:165 or rcu/tree-stall.h:296) Patch description: pid_revalidate() drops from RCU into REF lookup mode. When many threads are resolving paths within /proc in parallel, this can result in heavy spinlock contention on d_lockref as each thread tries to grab a reference to the /proc dentry (and drop it shortly thereafter). Investigation indicates that it is not necessary to drop RCU in pid_revalidate(), as no RCU data is modified and the function never sleeps. So, remove the LOOKUP_RCU check. Link: https://lkml.kernel.org/r/20211004175629.292270-2-stephen.s.brennan@oracle.comSigned-off-by: NStephen Brennan <stephen.s.brennan@oracle.com> Cc: Konrad Wilk <konrad.wilk@oracle.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Matthew Wilcox <willy@infradead.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NLi Nan <linan122@huawei.com> (cherry picked from commit f2924f34)
-
- 16 6月, 2023 5 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/855 Remove the automatic loading of the hisi_trng driver issue:https://gitee.com/openeuler/kernel/issues/I79JTN Link:https://gitee.com/openeuler/kernel/pulls/882 Reviewed-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Kang Chen 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6NYW4 CVE: NA -------------------------------- raw call flow: oom_kill_process -> mem_cgroup_scan_tasks(.., .., message) -> memcg_print_bad_task(message, ..) message is "const char*" type, and incorrectly cast to "oom_control*" type in memcg_print_bad_task. Fix it by moving memcg_print_bad_task out of mem_cgroup_scan_tasks and call it in select_bad_process and dump_tasks. Furthermore, use struct oom_control* directly and remove the useless parm `ret`. Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NKang Chen <void0red@hust.edu.cn> (cherry picked from commit 789038c7)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @xiao_jiang_shui Loop branch using 'i++' as condition will cause the loop to not execute when 'i == 0', should use '++i', Fix it. issue: https://gitee.com/openeuler/kernel/issues/I7DUYJ Link:https://gitee.com/openeuler/kernel/pulls/1144 Reviewed-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1136 PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/ID2Q7S2KSELYENBGS2BVZCEVGEP4WKO2/ Link:https://gitee.com/openeuler/kernel/pulls/1147 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Bob Peterson 提交于
mainline inclusion from mainline-v6.4-rc2 commit 504a10d9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7CXJL CVE: CVE-2023-3212 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=504a10d9e46bc37b23d0a1ae2f28973c8516e636 -------------------------------- On corrupt gfs2 file systems the evict code can try to reference the journal descriptor structure, jdesc, after it has been freed and set to NULL. The sequence of events is: init_journal() ... fail_jindex: gfs2_jindex_free(sdp); <------frees journals, sets jdesc = NULL if (gfs2_holder_initialized(&ji_gh)) gfs2_glock_dq_uninit(&ji_gh); fail: iput(sdp->sd_jindex); <--references jdesc in evict_linked_inode evict() gfs2_evict_inode() evict_linked_inode() ret = gfs2_trans_begin(sdp, 0, sdp->sd_jdesc->jd_blocks); <------references the now freed/zeroed sd_jdesc pointer. The call to gfs2_trans_begin is done because the truncate_inode_pages call can cause gfs2 events that require a transaction, such as removing journaled data (jdata) blocks from the journal. This patch fixes the problem by adding a check for sdp->sd_jdesc to function gfs2_evict_inode. In theory, this should only happen to corrupt gfs2 file systems, when gfs2 detects the problem, reports it, then tries to evict all the system inodes it has read in up to that point. Reported-by: NYang Lan <lanyang0908@gmail.com> Signed-off-by: NBob Peterson <rpeterso@redhat.com> Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com> Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> Conflicts: fs/gfs2/super.c (cherry picked from commit a1816ee0)
-
- 15 6月, 2023 3 次提交
-
-
由 JiangShui Yang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7DUYJ CVE: NA ---------------------------------------------------------------------- Loop branch using 'i++' as condition will cause the loop to not execute when 'i == 0', should use '++i', Fix it. Fixes: 26f2f10d ("crypto: hisilicon/qm - obtain the mailbox configuration at one time") Fixes: aabdf15d ("vfio/migration: obtain the mailbox configuration at one time") Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com> Signed-off-by: NWeili Qian <qianweili@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Liu Jian <liujian56@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OU22IIXYWUCYAU6Z4EMLHBK3CNL4JAZK/ Link:https://gitee.com/openeuler/kernel/pulls/1140 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Jian 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7DNAP CVE: N/A ---------------------------------------------------- add sample sockmap code for redis Signed-off-by: NLiu Jian <liujian56@huawei.com>
-
- 14 6月, 2023 6 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1115 PR sync from: Peng Zhang <zhangpeng362@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/GRJWIT22G2QJFYJL64FIBD6E7V5TTDY5/ From: ZhangPeng <zhangpeng362@huawei.com> Fix Fuzz test BUG_ON and failure to swap out large memory. Two userswap bugfixes synchronized from hulk5.10. ZhangPeng (2): userswap: fix BUG_ON in userfaultfd_release() userswap: fix kmalloc ENOMEM failed for a large memory -- 2.25.1 Link:https://gitee.com/openeuler/kernel/pulls/1126 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 ZhangPeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6CAIM -------------------------------- If the swapped-out memory is large, such as tens of gigabytes, we will allocate a large management structure, which may be tens of megabytes or hundreds of megabytes. So if we use kmalloc to allocate management structures it may fail. Fix this by changing kmalloc to kvzalloc and kfree to kvfree. Signed-off-by: NZhangPeng <zhangpeng362@huawei.com> (cherry picked from commit 6935faf1)
-
由 ZhangPeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6CAIM -------------------------------- In some features of userfaultfd, vma->vm_userfaultfd_ctx.ctx may be NULL but VM_USWAP is not cleared. No longer check whether vma->vm_flags has VM_USWAP. Just remove the flag. Signed-off-by: NZhangPeng <zhangpeng362@huawei.com> (cherry picked from commit 9f98927f)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Liu Jian <liujian56@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/GBQRSP7JMB5AKFHWXXI74KBSVWJZESEQ/ add one bpf helper function for redissockmap Liu Jian (2): net: add bpf_is_local_ipaddr bpf helper function net: let sockops can use bpf_get_current_comm() -- 2.34.1 Link:https://gitee.com/openeuler/kernel/pulls/1125 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Liu Jian 提交于
hulk inclusion category: feature bugzilla: NA CVE: N/A ---------------------------------------------------- Let sockops can use bpf_get_current_comm(). Signed-off-by: NLiu Jian <liujian56@huawei.com>
-
由 Liu Jian 提交于
hulk inclusion category: feature bugzilla: NA CVE: N/A ---------------------------------------------------- Some network acceleration solutions, such as sockmap, are valid only for internal packets of the local host. The bpf_is_local_ipaddr() bpf helper function is added so that the ebpf program can determine whether a packet is an internal packet of the local host. Signed-off-by: NLiu Jian <liujian56@huawei.com>
-
- 13 6月, 2023 12 次提交
-
-
由 openeuler-ci-bot 提交于
!1105 [sync] PR-1089: power: supply: bq24190: Fix use after free bug in bq24190_remove due to race condition Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1089 PR sync from: Zhao Wenhui <zhaowenhui8@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/FTJHXWWTIUDTIGLFJ4DL6XSYWRZEPLE4/ Link:https://gitee.com/openeuler/kernel/pulls/1105 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1090 PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/VQ5QP4GZFTJCMRJ3WK33W5A5SSQR2MY7/ Link:https://gitee.com/openeuler/kernel/pulls/1110 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
!1119 [openEuler-22.03-LTS-SP2] net: hns3: refactor hclge_mac_link_status_wait and add wait until mac link down Merge Pull Request from: @svishen This pull Requests refactor hclge_mac_link_status_wait and add wait until mac link down issue: https://gitee.com/openeuler/kernel/issues/I7D6IP Link:https://gitee.com/openeuler/kernel/pulls/1119 Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Jie Wang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7D6IP CVE: NA ---------------------------------------------------------------------- In some configure flow of hns3 driver, for example, change mtu, it will disable MAC through firmware before configuration. But firmware disables MAC asynchronously. The rx traffic may be not stopped in this case. So fixes it by waiting until mac link is down. Fixes: a9775bb6 ("net: hns3: fix set and get link ksettings issue") Signed-off-by: NJie Wang <wangjie125@huawei.com>
-
由 Jie Wang 提交于
driver inclusion category: cleanup bugzilla: https://gitee.com/openeuler/kernel/issues/I7D6IP CVE: NA ---------------------------------------------------------------------- Some nic configurations could only be performed after link is down. So this patch refactor this API for reuse. Signed-off-by: NJie Wang <wangjie125@huawei.com>
-
由 Konstantin Komarov 提交于
mainline inclusion from mainline-v6.2-rc1 commit 0e8235d2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I79X84 CVE: CVE-2022-48502 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b -------------------------------- Added new functions index_hdr_check and index_buf_check. Now we check all stuff for correctness while reading from disk. Also fixed bug with stale nfs data. Reported-by: Nvan fantasy <g1042620637@gmail.com> Signed-off-by: NKonstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> Conflicts: fs/ntfs3/inode.c fs/ntfs3/xattr.c (cherry picked from commit 9fc58dcc)
-
由 Zheng Wang 提交于
stable inclusion from stable-v5.10.177 commit 2b346876b93168541a45551d5f9abd1d26102e89 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7781Q CVE: CVE-2023-33288 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2b346876b93168541a45551d5f9abd1d26102e89 -------------------------------- [ Upstream commit 47c29d69 ] In bq24190_probe, &bdi->input_current_limit_work is bound with bq24190_input_current_limit_work. When external power changed, it will call bq24190_charger_external_power_changed to start the work. If we remove the module which will call bq24190_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows: CPU0 CPUc1 |bq24190_input_current_limit_work bq24190_remove | power_supply_unregister | device_unregister | power_supply_dev_release| kfree(psy) | | | power_supply_get_property_from_supplier | //use Fix it by finishing the work before cleanup in the bq24190_remove Fixes: 97774672 ("power_supply: Initialize changed_work before calling device_add") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Conflicts: drivers/power/supply/bq24190_charger.c Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com> (cherry picked from commit 085b94ff)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @did-you-collect-the-wool-today In probe_vendor_drivers, all registered vendor drivers are traversed. This is not a good idea. If a vendor driver is not implemented well enough, it may cause the system to panic. Use the vendor id and device id to select a proper driver. The acc live migration driver needs to be adapted. Link:https://gitee.com/openeuler/kernel/pulls/1093 Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @cj-xiaocai When enabled GICv4.1 in hip09, there are some invalid vPE configurations in configuration table for some situations, which will cause some vSGI interrupts lost. To fix the issue, need to send vinvall command after vmovp. Link:https://gitee.com/openeuler/kernel/pulls/1085 Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Xiang Chen 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7C103 -------------------------------------------------------------------------- When enabled GICv4.1 in hip09, there are some invalid vPE configurations in configuration table for some situations, which will cause some vSGI interrupts lost. To fix the issue, need to send vinvall command after vmovp. Signed-off-by: NNianyao Tang <tangnianyao@huawei.com> Signed-off-by: NXiang Chen <chenxiang66@hisilicon.com> Signed-off-by: NCaiJian <caijian11@h-partners.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhangjialin11 Only one page is allocated to the collection table. Recalculate the page number of collection table based on the number of CPUs. Link:https://gitee.com/openeuler/kernel/pulls/1095 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Liu Jian <liujian56@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/24ZK7TI2Q55BY7U53AB2LYQUFTABZR4L/ some backport bugfix for sockmap Cong Wang (1): bpf, sock_map: Move cancel_work_sync() out of sock lock Eric Dumazet (1): net: deal with most data-races in sk_wait_event() Jakub Sitnicki (2): bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself Pengcheng Yang (3): bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data bpf, sockmap: Fix missing BPF_F_INGRESS flag when using apply_bytes bpf, sockmap: Fix data loss caused by using apply_bytes on ingress redirect Wang Yufen (1): bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues zhangmingyi (1): bpf: fix bpf_tcp_ingress addr use after free -- 2.34.1 Link:https://gitee.com/openeuler/kernel/pulls/1081 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
- 12 6月, 2023 5 次提交
-
-
由 wangwudi 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7CX6S CVE: NA -------------------------------------------------------------------------- Only one page is allocated to the collection table. Recalculate the page number of collection table based on the number of CPUs. Signed-off-by: Nwangwudi <wangwudi@hisilicon.com>
-
由 Kunkun Jiang 提交于
virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7CX4Z CVE: NA ------------------------------------------------------------------ In probe_vendor_drivers, all registered vendor drivers are traversed. This is not a good idea. If a vendor driver is not implemented well enough, it may cause the system to panic. Use the vendor id and device id to select a proper driver. The acc live migration driver needs to be adapted. Signed-off-by: NLongfang Liu <liulongfang@huawei.com> Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Wei Li <liwei391@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/J4QNVBAATO5YYR4XQ6PLJNMFVEF6SNPX/ Link:https://gitee.com/openeuler/kernel/pulls/1077 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @did-you-collect-the-wool-today virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BQMW CVE: NA ----------------------------------------------------------------- The deafault value of NR_IRQS is not sufficient to support GICv4.1 features and ~56K LPIs. This parameter would be too small for certain server platforms where it has many IO devices and is capable of direct injection of vSGI and vLPI features. Currently, maximum of 64 + 8192 (IRQ_BITMAP_BITS) IRQ descriptors are allowed. The vCPU creation fails after reaching count ~400 with kvm-arm.vgic_v4_enable=1. This patch increases NR_IRQS to 1^19 to cover 56K LPIs and 262144 vSGIs (16vPEs x 16). ------------------------------------------------------------------ Tips: This is a temporary fix[1], but it has been able to solve the problem. The latest upstream version[2] depends on the 'maple tree', which is inappropriately introduced to the current kernel. ------------------------------------------------------------------- Another Tips: According to Chao Liu and Chang Liao's suggestion, modifying IRQ_BITMAP_BITS can achieve the same effect with less impact. Compared with solution[2], solution[1] has a disadvantage: the memory foot print increases as the number of VMs increases. Link: https://lore.kernel.org/linux-arm-kernel/20230104023738.1258925-1-sdonthineni@nvidia.com/ [1] Link: https://lore.kernel.org/all/20230519134902.1495562-1-sdonthineni@nvidia.com/#t [2] Signed-off-by: NShanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: NChao Liu <liuchao173@huawei.com> Signed-off-by: NChang Liao <liaochang1@huawei.com> Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com> Link:https://gitee.com/openeuler/kernel/pulls/1087 Reviewed-by: Liu Chao <liuchao173@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Kunkun Jiang 提交于
virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7BQMW CVE: NA ----------------------------------------------------------------- The deafault value of NR_IRQS is not sufficient to support GICv4.1 features and ~56K LPIs. This parameter would be too small for certain server platforms where it has many IO devices and is capable of direct injection of vSGI and vLPI features. Currently, maximum of 64 + 8192 (IRQ_BITMAP_BITS) IRQ descriptors are allowed. The vCPU creation fails after reaching count ~400 with kvm-arm.vgic_v4_enable=1. This patch increases NR_IRQS to 1^19 to cover 56K LPIs and 262144 vSGIs (16vPEs x 16). ------------------------------------------------------------------ Tips: This is a temporary fix[1], but it has been able to solve the problem. The latest upstream version[2] depends on the 'maple tree', which is inappropriately introduced to the current kernel. ------------------------------------------------------------------- Another Tips: According to Chao Liu and Chang Liao's suggestion, modifying IRQ_BITMAP_BITS can achieve the same effect with less impact. Compared with solution[2], solution[1] has a disadvantage: the memory foot print increases as the number of VMs increases. Link: https://lore.kernel.org/linux-arm-kernel/20230104023738.1258925-1-sdonthineni@nvidia.com/ [1] Link: https://lore.kernel.org/all/20230519134902.1495562-1-sdonthineni@nvidia.com/#t [2] Signed-off-by: NShanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: NChao Liu <liuchao173@huawei.com> Signed-off-by: NChang Liao <liaochang1@huawei.com> Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>
-
- 11 6月, 2023 4 次提交
-
-
由 zhangmingyi 提交于
euleros inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I545NW CVE: NA -------------------------------- fix a bug in bpf_tcp_ingress(), addr use after free Signed-off-by: Nzhangmingyi <zhangmingyi5@huawei.com> Reviewed-by: Nliuxin <liuxin350@huawei.com> Reviewed-by: Nwuchangye <wuchangye@huawei.com> Fixes: 8818e269 ("bpf, sockmap: Add sk_rmem_alloc check for sockmap") Signed-off-by: NLiu Jian <liujian56@huawei.com>
-
由 Eric Dumazet 提交于
stable inclusion from stable-v5.10.181 commit 4493914009609d6351b3a41dfe3b0ac5209bd4c6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I65HYE CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4493914009609d6351b3a41dfe3b0ac5209bd4c6 --------------------------- [ Upstream commit d0ac89f6 ] __condition is evaluated twice in sk_wait_event() macro. First invocation is lockless, and reads can race with writes, as spotted by syzbot. BUG: KCSAN: data-race in sk_stream_wait_connect / tcp_disconnect write to 0xffff88812d83d6a0 of 4 bytes by task 9065 on cpu 1: tcp_disconnect+0x2cd/0xdb0 inet_shutdown+0x19e/0x1f0 net/ipv4/af_inet.c:911 __sys_shutdown_sock net/socket.c:2343 [inline] __sys_shutdown net/socket.c:2355 [inline] __do_sys_shutdown net/socket.c:2363 [inline] __se_sys_shutdown+0xf8/0x140 net/socket.c:2361 __x64_sys_shutdown+0x31/0x40 net/socket.c:2361 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffff88812d83d6a0 of 4 bytes by task 9040 on cpu 0: sk_stream_wait_connect+0x1de/0x3a0 net/core/stream.c:75 tcp_sendmsg_locked+0x2e4/0x2120 net/ipv4/tcp.c:1266 tcp_sendmsg+0x30/0x50 net/ipv4/tcp.c:1484 inet6_sendmsg+0x63/0x80 net/ipv6/af_inet6.c:651 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] __sys_sendto+0x246/0x300 net/socket.c:2142 __do_sys_sendto net/socket.c:2154 [inline] __se_sys_sendto net/socket.c:2150 [inline] __x64_sys_sendto+0x78/0x90 net/socket.c:2150 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x00000000 -> 0x00000068 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by: Nsyzbot <syzkaller@googlegroups.com> Signed-off-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLiu Jian <liujian56@huawei.com>
-
由 Jakub Sitnicki 提交于
mainline inclusion from mainline-v6.2-rc7 commit 5b4a79ba category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I65HYE CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5b4a79ba65a1ab479903fff2e604865d229b70a9 --------------------------- sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/Suggested-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NJakub Sitnicki <jakub@cloudflare.com> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20230113-sockmap-fix-v2-1-1e0ee7ac2f90@cloudflare.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org> Signed-off-by: NLiu Jian <liujian56@huawei.com>
-
由 Jakub Sitnicki 提交于
stable inclusion from stable-v5.10.168 commit 9bd6074e1872d22190a8da30e796cbf937d334f0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6IXN2 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9bd6074e1872d22190a8da30e796cbf937d334f0 -------------------------------- [ Upstream commit ddce1e09 ] A listening socket linked to a sockmap has its sk_prot overridden. It points to one of the struct proto variants in tcp_bpf_prots. The variant depends on the socket's family and which sockmap programs are attached. A child socket cloned from a TCP listener initially inherits their sk_prot. But before cloning is finished, we restore the child's proto to the listener's original non-tcp_bpf_prots one. This happens in tcp_create_openreq_child -> tcp_bpf_clone. Today, in tcp_bpf_clone we detect if the child's proto should be restored by checking only for the TCP_BPF_BASE proto variant. This is not correct. The sk_prot of listening socket linked to a sockmap can point to to any variant in tcp_bpf_prots. If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, then the child socket unintentionally is left if the inherited sk_prot by tcp_bpf_clone. This leads to issues like infinite recursion on close [1], because the child state is otherwise not set up for use with tcp_bpf_prot operations. Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants. Note that it wouldn't be sufficient to check the socket state when overriding the sk_prot in tcp_bpf_update_proto in order to always use the TCP_BPF_BASE variant for listening sockets. Since commit b8b8315e ("bpf, sockmap: Remove unhash handler for BPF sockmap usage") it is possible for a socket to transition to TCP_LISTEN state while already linked to a sockmap, e.g. connect() -> insert into map -> connect(AF_UNSPEC) -> listen(). [1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ Fixes: e8025155 ("tcp_bpf: Don't let child socket inherit parent protocol ops on copy") Reported-by: syzbot+04c21ed96d861dccc5cd@syzkaller.appspotmail.com Signed-off-by: NJakub Sitnicki <jakub@cloudflare.com> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20230113-sockmap-fix-v2-2-1e0ee7ac2f90@cloudflare.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NWang Hai <wanghai38@huawei.com> Signed-off-by: NLiu Jian <liujian56@huawei.com>
-