| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6677
PR sync from: Wupeng Ma <mawupeng1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/F2VRDUQ6NU77XVWZ7ZJ63PSSBRJBGCO4/
From: Ma Wupeng <mawupeng1@huawei.com>
backport minor bugfix for mm.
Changelog since v2:
- fix style problem.
Changelog since v1:
- fix style problem.
Mel Gorman (1):
mm/page_alloc: always attempt to allocate at least one page during
bulk allocation
Miaohe Lin (1):
mm/madvise: fix potential pte_unmap_unlock pte error
--
2.25.1
https://gitee.com/openeuler/kernel/issues/I9JPDJ
Link:https://gitee.com/openeuler/kernel/pulls/6753
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v5.19-rc1
commit f3b9e8cc8b09ba3b41bb068c24a1061e8a70d26f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I9JPDJ
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f3b9e8cc8b09ba3b41bb068c24a1061e8a70d26f
--------------------------------
We can't assume pte_offset_map_lock will return same orig_pte value. So
it's necessary to reacquire the orig_pte or pte_unmap_unlock will unmap
the stale pte.
Link: https://lkml.kernel.org/r/20220416081416.23304-1-linmiaohe@huawei.com
Fixes: 9c276cc65a58 ("mm: introduce MADV_COLD")
Fixes: 854e9ed09ded ("mm: support madvise(MADV_FREE)")
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ma Wupeng <mawupeng1@huawei.com>
(cherry picked from commit 445475d0030d30716e259236bb48863d7ecf34cc)
|
|
allocation
stable inclusion
from stable-v5.15.46
commit fb49bd85dfac8c25dffa4b79825570e4c63a41b3
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I9JPDJ
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb49bd85dfac8c25dffa4b79825570e4c63a41b3
--------------------------------
commit c572e4888ad1be123c1516ec577ad30a700bbec4 upstream.
Peter Pavlisko reported the following problem on kernel bugzilla 216007.
When I try to extract an uncompressed tar archive (2.6 milion
files, 760.3 GiB in size) on newly created (empty) XFS file system,
after first low tens of gigabytes extracted the process hangs in
iowait indefinitely. One CPU core is 100% occupied with iowait,
the other CPU core is idle (on 2-core Intel Celeron G1610T).
It was bisected to c9fa563072e1 ("xfs: use alloc_pages_bulk_array() for
buffers") but XFS is only the messenger. The problem is that nothing is
waking kswapd to reclaim some pages at a time the PCP lists cannot be
refilled until some reclaim happens. The bulk allocator checks that there
are some pages in the array and the original intent was that a bulk
allocator did not necessarily need all the requested pages and it was best
to return as quickly as possible.
This was fine for the first user of the API but both NFS and XFS require
the requested number of pages be available before making progress. Both
could be adjusted to call the page allocator directly if a bulk allocation
fails but it puts a burden on users of the API. Adjust the semantics to
attempt at least one allocation via __alloc_pages() before returning so
kswapd is woken if necessary.
It was reported via bugzilla that the patch addressed the problem and that
the tar extraction completed successfully. This may also address bug
215975 but has yet to be confirmed.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216007
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215975
Link: https://lkml.kernel.org/r/20220526091210.GC3441@techsingularity.net
Fixes: 387ba26fb1cb ("mm/page_alloc: add a bulk page allocator")
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Cc: "Darrick J. Wong" <djwong@kernel.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: <stable@vger.kernel.org> [5.13+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Conflicts:
mm/page_alloc.c
[Ma Wupeng: partial add nr_account from commit 3e23060b2d0b]
Signed-off-by: Ma Wupeng <mawupeng1@huawei.com>
(cherry picked from commit 4aa8e00dedb0639bd3ac32cf06b6f2e0eac951c7)
|
|
Merge Pull Request from: @ci-robot
PR sync from: Baokun Li <libaokun1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/DCPKKVNPBDMB5HGOUCQM4IW3PENC7VA5/
https://gitee.com/src-openeuler/kernel/issues/I9HJVQ
Link:https://gitee.com/openeuler/kernel/pulls/6504
Reviewed-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mtk_drm_crtc_finish_page_flip
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6580
PR sync from: Xiongfeng Wang <wangxiongfeng2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/WORN7BWYNWIQZTCZ2HUOU34K7VVJBQC4/
https://gitee.com/src-openeuler/kernel/issues/I9HK5V
Link:https://gitee.com/openeuler/kernel/pulls/6688
Reviewed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.9-rc1
commit c958e86e9cc1b48cac004a6e245154dfba8e163b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK5V
CVE: CVE-2024-26874
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=c958e86e9cc1b48cac004a6e245154dfba8e163b
--------------------------------
It's possible that mtk_crtc->event is NULL in
mtk_drm_crtc_finish_page_flip().
pending_needs_vblank value is set by mtk_crtc->event, but in
mtk_drm_crtc_atomic_flush(), it's is not guarded by the same
lock in mtk_drm_finish_page_flip(), thus a race condition happens.
Consider the following case:
CPU1 CPU2
step 1:
mtk_drm_crtc_atomic_begin()
mtk_crtc->event is not null,
step 1:
mtk_drm_crtc_atomic_flush:
mtk_drm_crtc_update_config(
!!mtk_crtc->event)
step 2:
mtk_crtc_ddp_irq ->
mtk_drm_finish_page_flip:
lock
mtk_crtc->event set to null,
pending_needs_vblank set to false
unlock
pending_needs_vblank set to true,
step 2:
mtk_crtc_ddp_irq ->
mtk_drm_finish_page_flip called again,
pending_needs_vblank is still true
//null pointer
Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more
efficient to just check if mtk_crtc->event is null before use.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/dri-devel/patch/20240223212404.3709690-1-hsinyi@chromium.org/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
(cherry picked from commit 0f8e6cdbd3375b2dbdb3902fca2424efbd9e8e82)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6561
PR sync from: Li Nan <linan122@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/6RF4M2JYJO75LEZ422PP7PALRGEP3HCX/
https://gitee.com/src-openeuler/kernel/issues/I9HKBT
Link:https://gitee.com/openeuler/kernel/pulls/6638
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
acpi_processor_power_exit()
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6584
PR sync from: liwei <liwei728@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/N7TZPATAH2GUEO2Y4LQ6QJKUYTHFHTCV/
https://gitee.com/src-openeuler/kernel/issues/I9HK63
Link:https://gitee.com/openeuler/kernel/pulls/6600
Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6579
PR sync from: Zhenzeng Su <suzhenzeng@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JTLMEO4XWJMG3UHUIXGV5EWSWBH6BCUJ/
https://gitee.com/src-openeuler/kernel/issues/I9HJVU
Link:https://gitee.com/openeuler/kernel/pulls/6609
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6568
PR sync from: Zhenzeng Su <suzhenzeng@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/FLAF3LR3E55J7I2EFY73IZLYDDC4R3N2/
https://gitee.com/src-openeuler/kernel/issues/I9HJPD
Link:https://gitee.com/openeuler/kernel/pulls/6608
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
ice_bridge_setlink()
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6543
PR sync from: Zhenzeng Su <suzhenzeng@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/673JYB5LNH4NETXNQF2CIDIUV3HPX5WI/
https://gitee.com/src-openeuler/kernel/issues/I9HK2H
Link:https://gitee.com/openeuler/kernel/pulls/6610
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
cleanup path
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6520
PR sync from: Zhenzeng Su <suzhenzeng@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HKJTFRNVZ3EOCA5T6347NL7I3NHYQHRW/
https://gitee.com/src-openeuler/kernel/issues/I9HK9F
Link:https://gitee.com/openeuler/kernel/pulls/6612
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.9-rc1
commit 6cf350658736681b9d6b0b6e58c5c76b235bb4c4
category: bugfix
bugzilla: 189820, https://gitee.com/src-openeuler/kernel/issues/I9HKBT
CVE: CVE-2024-26900
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6cf350658736681b9d6b0b6e58c5c76b235bb4c4
--------------------------------
If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be
alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152):
comm "mdadm", pid 789, jiffies 4294716910
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc f773277a):
[<0000000058b0a453>] kmemleak_alloc+0x61/0xe0
[<00000000366adf14>] __kmalloc_large_node+0x15e/0x270
[<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f
[<00000000f206d60a>] kvmalloc_node+0x74/0x150
[<0000000034bf3363>] rdev_init_serial+0x67/0x170
[<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220
[<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630
[<0000000073c28560>] md_add_new_disk+0x400/0x9f0
[<00000000770e30ff>] md_ioctl+0x15bf/0x1c10
[<000000006cfab718>] blkdev_ioctl+0x191/0x3f0
[<0000000085086a11>] vfs_ioctl+0x22/0x60
[<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0
[<00000000e54e675e>] do_syscall_64+0x71/0x150
[<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74
Fixes: 963c555e75b0 ("md: introduce mddev_create/destroy_wb_pool for the change of member device")
Signed-off-by: Li Nan <linan122@huawei.com>
Signed-off-by: Song Liu <song@kernel.org>
Link: https://lore.kernel.org/r/20240208085556.2412922-1-linan666@huaweicloud.com
Conflict:
drivers/md/md.c
1. Mainline commit b4128c00a653 ("md: cleanup mddev_create/
destroy_serial_pool()") removed the third param of
mddev_destroy_serial_pool().
2. OLK commit 3bb76c49199e ("[Huawei] md: fix sysfs duplicate
file while adding rdev") changed context.
Signed-off-by: Li Nan <linan122@huawei.com>
(cherry picked from commit 95bc57bd99d6eeaef5186a074ec4b3b3d46981e8)
|
|
Merge Pull Request from: @ci-robot
PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/YJWGA7NUV7TABITXWZSCQMEMSU4UN6FI/
https://gitee.com/src-openeuler/kernel/issues/I91L79
Link:https://gitee.com/openeuler/kernel/pulls/6250
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.9-rc1
commit f1d71576d2c9ec8fdb822173fa7f3de79475e9bd
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK9F
CVE: CVE-2024-26893
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f1d71576d2c9ec8fdb822173fa7f3de79475e9bd
--------------------------------
When the generic SCMI code tears down a channel, it calls the chan_free
callback function, defined by each transport. Since multiple protocols
might share the same transport_info member, chan_free() might want to
clean up the same member multiple times within the given SCMI transport
implementation. In this case, it is SMC transport. This will lead to a NULL
pointer dereference at the second time:
| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
| arm-scmi firmware:scmi: unable to communicate with SCMI
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
| Mem abort info:
| ESR = 0x0000000096000004
| EC = 0x25: DABT (current EL), IL = 32 bits
| SET = 0, FnV = 0
| EA = 0, S1PTW = 0
| FSC = 0x04: level 0 translation fault
| Data abort info:
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in:
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
| Hardware name: FVP Base RevC (DT)
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : smc_chan_free+0x3c/0x6c
| lr : smc_chan_free+0x3c/0x6c
| Call trace:
| smc_chan_free+0x3c/0x6c
| idr_for_each+0x68/0xf8
| scmi_cleanup_channels.isra.0+0x2c/0x58
| scmi_probe+0x434/0x734
| platform_probe+0x68/0xd8
| really_probe+0x110/0x27c
| __driver_probe_device+0x78/0x12c
| driver_probe_device+0x3c/0x118
| __driver_attach+0x74/0x128
| bus_for_each_dev+0x78/0xe0
| driver_attach+0x24/0x30
| bus_add_driver+0xe4/0x1e8
| driver_register+0x60/0x128
| __platform_driver_register+0x28/0x34
| scmi_driver_init+0x84/0xc0
| do_one_initcall+0x78/0x33c
| kernel_init_freeable+0x2b8/0x51c
| kernel_init+0x24/0x130
| ret_from_fork+0x10/0x20
| Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
| ---[ end trace 0000000000000000 ]---
Simply check for the struct pointer being NULL before trying to access
its members, to avoid this situation.
This was found when a transport doesn't really work (for instance no SMC
service), the probe routines then tries to clean up, and triggers a crash.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport")
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20240126122325.2039669-1-andre.przywara@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Zhenzeng Su <suzhenzeng@huawei.com>
(cherry picked from commit c882eb9fed13af07f0d3cd1bd7c0ceb6f607764f)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6281
PR sync from: Xiang Yang <xiangyang3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LPSHVFCTKDH6DXEE5USVUXWVU5TKS7SZ/
https://gitee.com/src-openeuler/kernel/issues/I9FNF8
Link:https://gitee.com/openeuler/kernel/pulls/6450
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.213
commit 37fe99016b12d32100ce670216816dba6c48b309
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK2H
CVE: CVE-2024-26855
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=37fe99016b12d32100ce670216816dba6c48b309
--------------------------------
[ Upstream commit 06e456a05d669ca30b224b8ed962421770c1496c ]
The function ice_bridge_setlink() may encounter a NULL pointer dereference
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
in nla_for_each_nested(). To address this issue, add a check to ensure that
br_spec is not NULL before proceeding with the nested attribute iteration.
Fixes: b1edc14a3fbf ("ice: Implement ice_bridge_getlink and ice_bridge_setlink")
Signed-off-by: Rand Deeb <rand.sec96@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Zhenzeng Su <suzhenzeng@huawei.com>
(cherry picked from commit b7f8b02ee79ab6cd34d12968a86c6eddb999f72e)
|
|
stable inclusion
from stable-v5.10.210
commit 93d8109bf182510629bbefc8cd45296d2393987f
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJVU
CVE: CVE-2023-52642
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=93d8109bf182510629bbefc8cd45296d2393987f
--------------------------------
commit 6a9d552483d50953320b9d3b57abdee8d436f23f upstream.
Note that bpf attach/detach also requires CAP_NET_ADMIN.
Cc: stable@vger.kernel.org
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zhenzeng Su <suzhenzeng@huawei.com>
(cherry picked from commit 8cba46fe5d13688a84edabbdd83e9f8f9a32f513)
|
|
stable inclusion
from stable-v5.10.213
commit 37fe99016b12d32100ce670216816dba6c48b309
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK2H
CVE: CVE-2024-26855
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=37fe99016b12d32100ce670216816dba6c48b309
--------------------------------
[ Upstream commit 06e456a05d669ca30b224b8ed962421770c1496c ]
The function ice_bridge_setlink() may encounter a NULL pointer dereference
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
in nla_for_each_nested(). To address this issue, add a check to ensure that
br_spec is not NULL before proceeding with the nested attribute iteration.
Fixes: b1edc14a3fbf ("ice: Implement ice_bridge_getlink and ice_bridge_setlink")
Signed-off-by: Rand Deeb <rand.sec96@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Zhenzeng Su <suzhenzeng@huawei.com>
(cherry picked from commit b7f8b02ee79ab6cd34d12968a86c6eddb999f72e)
|
|
stable inclusion
from stable-v5.10.211
commit 3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJPD
CVE: CVE-2024-26839
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7
--------------------------------
[ Upstream commit 809aa64ebff51eb170ee31a95f83b2d21efa32e2 ]
When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
init_credit_return should deallocate dd->cr_base and
dd->cr_base[i] that allocated before. Or those resources
would be never freed and a memleak is triggered.
Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Link: https://lore.kernel.org/r/20240112085523.3731720-1-alexious@zju.edu.cn
Acked-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Zhenzeng Su <suzhenzeng@huawei.com>
(cherry picked from commit dbc9145bbeeb0c0aec5978916a59570e9e3e43c3)
|
|
mainline inclusion
from mainline-v6.9-rc1
commit e18afcb7b2a12b635ac10081f943fcf84ddacc51
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK63
CVE: CVE-2024-26894
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e18afcb7b2a12b635ac10081f943fcf84ddacc51
------------------------------------------------------
After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024):
comm "swapper/0", pid 1, jiffies 4294893170
hex dump (first 32 bytes):
00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 8836a742):
[<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
[<ffffffff9972f3b3>] acpi_processor_power_init+0xf3/0x1c0
[<ffffffff9972d263>] __acpi_processor_start+0xd3/0xf0
[<ffffffff9972d2bc>] acpi_processor_start+0x2c/0x50
[<ffffffff99805872>] really_probe+0xe2/0x480
[<ffffffff99805c98>] __driver_probe_device+0x78/0x160
[<ffffffff99805daf>] driver_probe_device+0x1f/0x90
[<ffffffff9980601e>] __driver_attach+0xce/0x1c0
[<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
[<ffffffff99804822>] bus_add_driver+0x112/0x210
[<ffffffff99807245>] driver_register+0x55/0x100
[<ffffffff9aee4acb>] acpi_processor_driver_init+0x3b/0xc0
[<ffffffff990012d1>] do_one_initcall+0x41/0x300
[<ffffffff9ae7c4b0>] kernel_init_freeable+0x320/0x470
[<ffffffff99b231f6>] kernel_init+0x16/0x1b0
[<ffffffff99042e6d>] ret_from_fork+0x2d/0x50
Fix this by freeing the CPU idle device after unregistering it.
Fixes: 3d339dcbb56d ("cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: liwei <liwei728@huawei.com>
(cherry picked from commit 6c81b7ff78fbfd6a60271b8911f31e8a0ef93351)
|
|
Merge Pull Request from: @ci-robot
PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/RYZGZZ3FD5FFBFYT75P3NBESXXZJYLKC/
https://gitee.com/src-openeuler/kernel/issues/I9HK1I
Link:https://gitee.com/openeuler/kernel/pulls/6477
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6417
PR sync from: Zhu Wang <wangzhu9@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/SV6RZACWW4UPWOI3WW2HKSEB4PELGVZW/
https://gitee.com/src-openeuler/kernel/issues/I9HK8R
Link:https://gitee.com/openeuler/kernel/pulls/6576
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.9-rc1
commit 0a0b79ea55de8514e1750884e5fec77f9fdd01ee
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK8R
CVE: CVE-2024-26875
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a0b79ea55de8514e1750884e5fec77f9fdd01ee
--------------------------------
[Syzbot reported]
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0xc4/0x620 mm/kasan/report.c:488
kasan_report+0xda/0x110 mm/kasan/report.c:601
pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
Freed by task 906:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
poison_slab_object mm/kasan/common.c:241 [inline]
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inline]
slab_free mm/slub.c:4299 [inline]
kfree+0x105/0x340 mm/slub.c:4409
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
[Analyze]
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
and releasing mp, leading to this issue.
[Fix]
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
to avoid this issue.
Reported-and-tested-by: syzbot+ce750e124675d4599449@syzkaller.appspotmail.com
Fixes: e5be15c63804 ("V4L/DVB (7711): pvrusb2: Fix race on module unload")
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
(cherry picked from commit 3bd813821d98b4d333547487aa1a82d37eb11df4)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5510
PR sync from: Guan Jing <guanjing6@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/4SJ673UNMV4OTLMBARBGYDVSVX6EBO6T/
https://gitee.com/src-openeuler/kernel/issues/I97NHA
Link:https://gitee.com/openeuler/kernel/pulls/6415
Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6103
PR sync from: Zheng Zucheng <zhengzucheng@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JEVMTFNBLBYM335WZ43LIO4OISN2JI2L/
https://gitee.com/src-openeuler/kernel/issues/I9E466
Link:https://gitee.com/openeuler/kernel/pulls/6144
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
pgtable_cache_add
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5222
PR sync from: Peng Zhang <zhangpeng362@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/YFPZEZXT3Q2NAP566YHFU6RKNBGTDEF4/
https://gitee.com/src-openeuler/kernel/issues/I96GP1
Link:https://gitee.com/openeuler/kernel/pulls/6536
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
connection dump
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5273
PR sync from: Dong Chenchen <dongchenchen2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/J7DE3GIK6MEXNYQCC3356GISX4OV6CF4/
https://gitee.com/src-openeuler/kernel/issues/I97NHS
Link:https://gitee.com/openeuler/kernel/pulls/6540
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
path handling in mtk_jpeg_dec_device_run
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5468
PR sync from: Guo Mengqi <guomengqi3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JHQDTC675OYBRBWDHWXBQKGK7HR5FMP4/
https://gitee.com/src-openeuler/kernel/issues/I97NHC
Link:https://gitee.com/openeuler/kernel/pulls/6530
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev()
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6407
PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/2EBH57YT3MTXHILLJAU2ZJ476EWJAWON/
https://gitee.com/src-openeuler/kernel/issues/I8QF9K
Link:https://gitee.com/openeuler/kernel/pulls/6498
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.209
commit 5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d
category: bugfix
bugzilla: 189676, https://gitee.com/src-openeuler/kernel/issues/I97NHS
CVE: CVE-2024-26615
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d
--------------------------------
[ Upstream commit dbc153fd3c142909e564bb256da087e13fbf239c ]
A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:
- run nginx/wrk test:
smc_run nginx
smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>
- continuously dump SMC-D connections in parallel:
watch -n 1 'smcss -D'
BUG: kernel NULL pointer dereference, address: 0000000000000030
CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55
RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
Call Trace:
<TASK>
? __die+0x24/0x70
? page_fault_oops+0x66/0x150
? exc_page_fault+0x69/0x140
? asm_exc_page_fault+0x26/0x30
? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
? __kmalloc_node_track_caller+0x35d/0x430
? __alloc_skb+0x77/0x170
smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
smc_diag_dump+0x26/0x60 [smc_diag]
netlink_dump+0x19f/0x320
__netlink_dump_start+0x1dc/0x300
smc_diag_handler_dump+0x6a/0x80 [smc_diag]
? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
sock_diag_rcv_msg+0x121/0x140
? __pfx_sock_diag_rcv_msg+0x10/0x10
netlink_rcv_skb+0x5a/0x110
sock_diag_rcv+0x28/0x40
netlink_unicast+0x22a/0x330
netlink_sendmsg+0x1f8/0x420
__sock_sendmsg+0xb0/0xc0
____sys_sendmsg+0x24e/0x300
? copy_msghdr_from_user+0x62/0x80
___sys_sendmsg+0x7c/0xd0
? __do_fault+0x34/0x160
? do_read_fault+0x5f/0x100
? do_fault+0xb0/0x110
? __handle_mm_fault+0x2b0/0x6c0
__sys_sendmsg+0x4d/0x80
do_syscall_64+0x69/0x180
entry_SYSCALL_64_after_hwframe+0x6e/0x76
It is possible that the connection is in process of being established
when we dump it. Assumed that the connection has been registered in a
link group by smc_conn_create() but the rmb_desc has not yet been
initialized by smc_buf_create(), thus causing the illegal access to
conn->rmb_desc. So fix it by checking before dump.
Fixes: 4b1b7d3b30a6 ("net/smc: add SMC-D diag support")
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com>
(cherry picked from commit d69ce4891edaecd1fd2d9fc58374064333d598df)
|
|
mainline inclusion
from mainline-v6.8-rc1
commit f46c8a75263f97bda13c739ba1c90aced0d3b071
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I96GP1
CVE: CVE-2023-52607
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46c8a75263f97bda13c739ba1c90aced0d3b071
------------------------------------------------------
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231204023223.2447523-1-chentao@kylinos.cn
Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
(cherry picked from commit 053b5f8d4de01deaf40a1f443fcb6238c92d4a50)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5773
PR sync from: Xiongfeng Wang <wangxiongfeng2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/FC7NOS2Q3ZTDYOKBKU6UUWRRV3VO2KLZ/
Christophe JAILLET (1):
PCI: switchtec: Fix an error handling path in switchtec_pci_probe()
Daniel Stodden (1):
PCI: switchtec: Fix stdev_release() crash after surprise hot remove
--
2.20.1
https://gitee.com/src-openeuler/kernel/issues/I99JXH
Link:https://gitee.com/openeuler/kernel/pulls/6507
Reviewed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
consistency
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5772
PR sync from: Xiongfeng Wang <wangxiongfeng2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/F2MLLBGEH7CG3YY23UHSR3RMHZVXUP2E/
https://gitee.com/src-openeuler/kernel/issues/I98BNA
Link:https://gitee.com/openeuler/kernel/pulls/6503
Reviewed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: Yang Yingliang <yangyingliang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/4BHLIEFCRSL26BJDESVWBYMJ7VE36AIA/
Fix CVE-2023-52498.
Bjorn Helgaas (1):
PM: sleep: Use dev_printk() when possible
Li zeming (1):
PM: core: Remove unnecessary (void *) conversions
Rafael J. Wysocki (5):
async: Split async_schedule_node_domain()
async: Introduce async_schedule_dev_nocall()
PM: sleep: Avoid calling put_device() under dpm_list_mtx
PM: sleep: Fix possible deadlocks in core system-wide PM code
PM: sleep: Fix error handling in dpm_prepare()
--
2.25.1
https://gitee.com/src-openeuler/kernel/issues/I97NIA
Link:https://gitee.com/openeuler/kernel/pulls/6519
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mtk_jpeg_dec_device_run
stable inclusion
from stable-v5.10.210
commit 43872f44eee6c6781fea1348b38885d8e78face9
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NHC
CVE: CVE-2023-52491
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=43872f44eee6c6781fea1348b38885d8e78face9
--------------------------------
[ Upstream commit 206c857dd17d4d026de85866f1b5f0969f2a109e ]
In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with
mtk_jpeg_job_timeout_work.
In mtk_jpeg_dec_device_run, if error happens in
mtk_jpeg_set_dec_dst, it will finally start the worker while
mark the job as finished by invoking v4l2_m2m_job_finish.
There are two methods to trigger the bug. If we remove the
module, it which will call mtk_jpeg_remove to make cleanup.
The possible sequence is as follows, which will cause a
use-after-free bug.
CPU0 CPU1
mtk_jpeg_dec_... |
start worker |
|mtk_jpeg_job_timeout_work
mtk_jpeg_remove |
v4l2_m2m_release |
kfree(m2m_dev); |
|
| v4l2_m2m_get_curr_priv
| m2m_dev->curr_ctx //use
If we close the file descriptor, which will call mtk_jpeg_release,
it will have a similar sequence.
Fix this bug by starting timeout worker only if started jpegdec worker
successfully. Then v4l2_m2m_job_finish will only be called in
either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.
Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver")
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Guo Mengqi <guomengqi3@huawei.com>
(cherry picked from commit c0b3cf1541fb8da6c7fc327cd8d9d169f5282ad8)
|
|
stable inclusion
from stable-v5.10.210
commit 6db18971f73a8312ec547c32274c398e6ca36e14
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NIA
CVE: CVE-2023-52498
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6db18971f73a8312ec547c32274c398e6ca36e14
--------------------------------
[ Upstream commit 544e737dea5ad1a457f25dbddf68761ff25e028b ]
Commit 2aa36604e824 ("PM: sleep: Avoid calling put_device() under
dpm_list_mtx") forgot to update the while () loop termination
condition to also break the loop if error is nonzero, which
causes the loop to become infinite if device_prepare() returns
an error for one device.
Add the missing !error check.
Fixes: 2aa36604e824 ("PM: sleep: Avoid calling put_device() under dpm_list_mtx")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
|
|
stable inclusion
from stable-v5.10.210
commit f46eb832389f162ad13cb780d0b8cde93641990d
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NIA
CVE: CVE-2023-52498
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f46eb832389f162ad13cb780d0b8cde93641990d
--------------------------------
[ Upstream commit 7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557 ]
It is reported that in low-memory situations the system-wide resume core
code deadlocks, because async_schedule_dev() executes its argument
function synchronously if it cannot allocate memory (and not only in
that case) and that function attempts to acquire a mutex that is already
held. Executing the argument function synchronously from within
dpm_async_fn() may also be problematic for ordering reasons (it may
cause a consumer device's resume callback to be invoked before a
requisite supplier device's one, for example).
Address this by changing the code in question to use
async_schedule_dev_nocall() for scheduling the asynchronous
execution of device suspend and resume functions and to directly
run them synchronously if async_schedule_dev_nocall() returns false.
Link: https://lore.kernel.org/linux-pm/ZYvjiqX6EsL15moe@perf/
Reported-by: Youngmin Nam <youngmin.nam@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Tested-by: Youngmin Nam <youngmin.nam@samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: 5.7+ <stable@vger.kernel.org> # 5.7+: 6aa09a5bccd8 async: Split async_schedule_node_domain()
Cc: 5.7+ <stable@vger.kernel.org> # 5.7+: 7d4b5d7a37bd async: Introduce async_schedule_dev_nocall()
Cc: 5.7+ <stable@vger.kernel.org> # 5.7+
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
|
|
stable inclusion
from stable-v5.10.210
commit 8b604883d4cb1fa8d6b7d5d7db44b96465c9010b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NIA
CVE: CVE-2023-52498
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8b604883d4cb1fa8d6b7d5d7db44b96465c9010b
--------------------------------
[ Upstream commit 73d73f5ee7fb0c42ff87091d105bee720a9565f1 ]
Assignments from pointer variables of type (void *) do not require
explicit type casts, so remove such type cases from the code in
drivers/base/power/main.c where applicable.
Signed-off-by: Li zeming <zeming@nfschina.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Stable-dep-of: 7839d0078e0d ("PM: sleep: Fix possible deadlocks in core system-wide PM code")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
|
|
stable inclusion
from stable-v5.10.210
commit 57df40f8008931f7b8f2206c6c3975055eb4bcb5
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NIA
CVE: CVE-2023-52498
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=57df40f8008931f7b8f2206c6c3975055eb4bcb5
--------------------------------
[ Upstream commit 2aa36604e8243698ff22bd5fef0dd0c6bb07ba92 ]
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Stable-dep-of: 7839d0078e0d ("PM: sleep: Fix possible deadlocks in core system-wide PM code")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
|
|
stable inclusion
from stable-v5.10.210
commit 2245a8498569fac4ad2e391f38862a859924cf3c
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NIA
CVE: CVE-2023-52498
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2245a8498569fac4ad2e391f38862a859924cf3c
--------------------------------
[ Upstream commit eb23d91af55bc2369fe3f0aa6997e72eb20e16fe ]
Use dev_printk() when possible to make messages more consistent with other
device-related messages.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Stable-dep-of: 7839d0078e0d ("PM: sleep: Fix possible deadlocks in core system-wide PM code")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
|
|
stable inclusion
from stable-v5.10.210
commit ac4dcccbe9106a5cec483d2ffa7f628b95340a07
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NIA
CVE: CVE-2023-52498
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ac4dcccbe9106a5cec483d2ffa7f628b95340a07
--------------------------------
commit 7d4b5d7a37bdd63a5a3371b988744b060d5bb86f upstream.
In preparation for subsequent changes, introduce a specialized variant
of async_schedule_dev() that will not invoke the argument function
synchronously when it cannot be scheduled for asynchronous execution.
The new function, async_schedule_dev_nocall(), will be used for fixing
possible deadlocks in the system-wide power management core code.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> for the series.
Tested-by: Youngmin Nam <youngmin.nam@samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
|
|
stable inclusion
from stable-v5.10.210
commit 9ef68b58fd00cbb39f6eeacd9f224b99912dde62
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NIA
CVE: CVE-2023-52498
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9ef68b58fd00cbb39f6eeacd9f224b99912dde62
--------------------------------
commit 6aa09a5bccd8e224d917afdb4c278fc66aacde4d upstream.
In preparation for subsequent changes, split async_schedule_node_domain()
in two pieces so as to allow the bottom part of it to be called from a
somewhat different code path.
No functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Tested-by: Youngmin Nam <youngmin.nam@samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
|
|
mainline inclusion
from mainline-v6.8-rc1
commit dec529b0b0572b32f9eb91c882dd1f08ca657efb
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I99JXH
CVE: CVE-2023-52617
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=dec529b0b0572b32f9eb91c882dd1f08ca657efb
--------------------------------
The commit in Fixes changed the logic on how resources are released and
introduced a new switchtec_exit_pci() that need to be called explicitly in
order to undo a corresponding switchtec_init_pci().
This was done in the remove function, but not in the probe.
Fix the probe now.
Fixes: df25461119d9 ("PCI: switchtec: Fix stdev_release() crash after surprise hot remove")
Link: https://lore.kernel.org/r/01446d2ccb91a578239915812f2b7dfbeb2882af.1703428183.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
(cherry picked from commit 6bf196a086b9846438c17ee23d1d8ccf5eaf1df9)
|
|
mainline inclusion
from mainline-v6.8-rc1
commit df25461119d987b8c81d232cfe4411e91dcabe66
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I99JXH
CVE: CVE-2023-52617
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=df25461119d987b8c81d232cfe4411e91dcabe66
--------------------------------
A PCI device hot removal may occur while stdev->cdev is held open. The call
to stdev_release() then happens during close or exit, at a point way past
switchtec_pci_remove(). Otherwise the last ref would vanish with the
trailing put_device(), just before return.
At that later point in time, the devm cleanup has already removed the
stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted
one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause
a fatal page fault, and the subsequent dma_free_coherent(), if reached,
would pass a stale &stdev->pdev->dev pointer.
Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after
stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent
future accidents.
Reproducible via the script at
https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com
Link: https://lore.kernel.org/r/20231122042316.91208-2-dns@arista.com
Signed-off-by: Daniel Stodden <dns@arista.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
(cherry picked from commit b778e445689fc3830650412bc45a5a47901ea8a1)
|
|
stable inclusion
from stable-v5.10.212
commit 43eccc5823732ba6daab2511ed32dfc545a666d8
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJVQ
CVE: CVE-2024-26840
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=43eccc5823732ba6daab2511ed32dfc545a666d8
--------------------------------
commit e21a2f17566cbd64926fb8f16323972f7a064444 upstream.
The following memory leak was reported after unbinding /dev/cachefiles:
==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
comm "cachefilesd2", pid 680, jiffies 4294881224
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc ea38a44b):
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
==================================================================
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
fix the problem. And also put cache_cred in cachefiles_add_cache() error
branch to avoid memory leaks.
Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem")
CC: stable@vger.kernel.org
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Link: https://lore.kernel.org/r/20240217081431.796809-1-libaokun1@huawei.com
Acked-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
|
|
mainline inclusion
from mainline-v6.8-rc2
commit 437a310b22244d4e0b78665c3042e5d1c0f45306
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I98BNA
CVE: CVE-2023-52608
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=437a310b22244d4e0b78665c3042e5d1c0f45306
--------------------------------
On reception of a completion interrupt the shared memory area is accessed
to retrieve the message header at first and then, if the message sequence
number identifies a transaction which is still pending, the related
payload is fetched too.
When an SCMI command times out the channel ownership remains with the
platform until eventually a late reply is received and, as a consequence,
any further transmission attempt remains pending, waiting for the channel
to be relinquished by the platform.
Once that late reply is received the channel ownership is given back
to the agent and any pending request is then allowed to proceed and
overwrite the SMT area of the just delivered late reply; then the wait
for the reply to the new request starts.
It has been observed that the spurious IRQ related to the late reply can
be wrongly associated with the freshly enqueued request: when that happens
the SCMI stack in-flight lookup procedure is fooled by the fact that the
message header now present in the SMT area is related to the new pending
transaction, even though the real reply has still to arrive.
This race-condition on the A2P channel can be detected by looking at the
channel status bits: a genuine reply from the platform will have set the
channel free bit before triggering the completion IRQ.
Add a consistency check to validate such condition in the A2P ISR.
Reported-by: Xinglong Yang <xinglong.yang@cixtech.com>
Closes: https://lore.kernel.org/all/PUZPR06MB54981E6FA00D82BFDBB864FBF08DA@PUZPR06MB5498.apcprd06.prod.outlook.com/
Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type")
Cc: stable@vger.kernel.org # 5.15+
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Xinglong Yang <xinglong.yang@cixtech.com>
Link: https://lore.kernel.org/r/20231220172112.763539-1-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Conflicts:
drivers/firmware/arm_scmi/mailbox.c
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
(cherry picked from commit 8e2dfcb7642c29fc7b0c3a79615e156ed5e68666)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6455
PR sync from: Li Nan <linan122@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/GE7G7LIS3T52HN5CEJAMOUWEN6KINEZH/
Damien Le Moal (1):
Hannes Reinecke (1):
--
2.39.2
https://gitee.com/src-openeuler/kernel/issues/I9FNFK
Link:https://gitee.com/openeuler/kernel/pulls/6489
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/3998
PR sync from: Zeng Heng <zengheng4@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/O6VDPOFYYCNYJPTKZUPURVH3XDK6LDPS/
https://gitee.com/openeuler/kernel/issues/I8WAED
Link:https://gitee.com/openeuler/kernel/pulls/6484
Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev()
stable inclusion
from stable-v5.10.214
commit e1dc7aa814a95aeeb1b2c05be2b62af8423b15cc
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8QF9K
CVE: CVE-2023-7042
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e1dc7aa814a95aeeb1b2c05be2b62af8423b15cc
--------------------------------
[ Upstream commit ad25ee36f00172f7d53242dc77c69fff7ced0755 ]
We should check whether the WMI_TLV_TAG_STRUCT_MGMT_TX_COMPL_EVENT tlv is
present before accessing it, otherwise a null pointer deference error will
occur.
Fixes: dc405152bb64 ("ath10k: handle mgmt tx completion event")
Signed-off-by: Xingyuan Mo <hdthky0@gmail.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20231208043433.271449-1-hdthky0@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
(cherry picked from commit 2ea3d8f6700dfb6227e292b5fd326ccebbd41f5c)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6312
PR sync from: Wupeng Ma <mawupeng1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/23LEXGKBKWRCZF6WTRAYHQYVO5HETJZZ/
From: Ma Wupeng <mawupeng1@huawei.com>
fix CVE-2024-24861.
Gui-Dong Han (1):
media: xc4000: Fix atomicity violation in xc4000_get_frequency
--
2.25.1
https://gitee.com/src-openeuler/kernel/issues/I917JN
Link:https://gitee.com/openeuler/kernel/pulls/6434
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v5.16-rc1
commit 17b49bcbf8351d3dbe57204468ac34f033ed60bc
category: bugfix
bugzilla: 189811, https://gitee.com/src-openeuler/kernel/issues/I9FNFK
CVE: CVE-2021-47182
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=17b49bcbf8351d3dbe57204468ac34f033ed60bc
--------------------------------
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits,
occupying bytes 7 and 8 of the CDB. With this command, access to mode
pages larger than 255 bytes is thus possible. However, the CDB
allocation length field is set by assigning len to byte 8 only, thus
truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with
sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length
is increased to 8 and 4 respectively, and the buffer is zero filled
with these increased values, thus corrupting the memory following the
buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev->use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.
While at it, also fix the folowing:
* Use get_unaligned_be16() to retrieve the mode data length and block
descriptor length fields of the mode sense reply header instead of using
an open coded calculation.
* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
Block Descriptor, which is the opposite of what the dbd argument
description was.
Link: https://lore.kernel.org/r/20210820070255.682775-2-damien.lemoal@wdc.com
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Li Nan <linan122@huawei.com>
(cherry picked from commit 73951e4d93564443e2a29bb6545b2577a3d91fbc)
|
|
mainline inclusion
from mainline-v5.14-rc1
commit 64aaa3dd096a1949ab216cdcc105a10059ab1244
category: bugfix
bugzilla: 189811, https://gitee.com/src-openeuler/kernel/issues/I9FNFK
CVE: CVE-2021-47182
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=64aaa3dd096a1949ab216cdcc105a10059ab1244
--------------------------------
Reshuffle response handling in scsi_mode_sense() to make the code easier to
follow.
[mkp: fix build]
Link: https://lore.kernel.org/r/20210427083046.31620-5-hare@suse.de
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Li Nan <linan122@huawei.com>
(cherry picked from commit b9f1e531b4a458862afc64390a7dd689acacf0c8)
|
|
mainline inclusion
from mainline-v5.18-rc1
commit ec1c7ad47664f964c1101fe555b6fde0cb124b38
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I8WAED
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec1c7ad47664f964c1101fe555b6fde0cb124b38
--------------------------------
CPUfreq governors request CPU frequencies using information
on current CPU usage. The CPPC driver converts them to
performance requests. Frequency targets are computed as:
target_freq = (util / cpu_capacity) * max_freq
target_freq is then clamped between [policy->min, policy->max].
The CPPC driver converts performance values to frequencies
(and vice-versa) using cppc_cpufreq_perf_to_khz() and
cppc_cpufreq_khz_to_perf(). These functions both use two different
factors depending on the range of the input value. For
cppc_cpufreq_khz_to_perf():
- (NOMINAL_PERF / NOMINAL_FREQ) or
- (LOWEST_PERF / LOWEST_FREQ)
and for cppc_cpufreq_perf_to_khz():
- (NOMINAL_FREQ / NOMINAL_PERF) or
- ((NOMINAL_PERF - LOWEST_FREQ) / (NOMINAL_PERF - LOWEST_PERF))
This means:
1- the functions are not inverse for some values:
(perf_to_khz(khz_to_perf(x)) != x)
2- cppc_cpufreq_perf_to_khz(LOWEST_PERF) can sometimes give
a different value from LOWEST_FREQ due to integer approximation
3- it is implied that performance and frequency are proportional
(NOMINAL_FREQ / NOMINAL_PERF) == (LOWEST_PERF / LOWEST_FREQ)
This patch changes the conversion functions to an affine function.
This fixes the 3 points above.
Suggested-by: Lukasz Luba <lukasz.luba@arm.com>
Suggested-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
(cherry picked from commit 72f6fabb92e94c67a94059f3498f3bf3114bc5a6)
|
|
mainline inclusion
from mainline-v6.9-rc1
commit 3948abaa4e2be938ccdfc289385a27342fb13d43
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK1I
CVE: CVE-2024-26901
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3948abaa4e2be938ccdfc289385a27342fb13d43
--------------------------------
syzbot identified a kernel information leak vulnerability in
do_sys_name_to_handle() and issued the following report [1].
[1]
"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
_copy_to_user+0xbc/0x100 lib/usercopy.c:40
copy_to_user include/linux/uaccess.h:191 [inline]
do_sys_name_to_handle fs/fhandle.c:73 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc+0x121/0x3c0 mm/slab_common.c:1020
kmalloc include/linux/slab.h:604 [inline]
do_sys_name_to_handle fs/fhandle.c:39 [inline]
__do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
__se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
__x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
...
Bytes 18-19 of 20 are uninitialized
Memory access of size 20 starts at ffff888128a46380
Data copied to user address 0000000020000240"
Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
solve the problem.
Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support")
Suggested-by: Chuck Lever III <chuck.lever@oracle.com>
Reported-and-tested-by: <syzbot+09b349b3066c2e0b1e96@syzkaller.appspotmail.com>
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintech.ru
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/3982
PR sync from: Zeng Heng <zengheng4@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/QJ6NFI4QTBCTXXXDWIK2IHPEPTIUNVRY/
https://gitee.com/openeuler/kernel/issues/I8W708
Link:https://gitee.com/openeuler/kernel/pulls/3994
Reviewed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/3793
PR sync from: Zeng Heng <zengheng4@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/MZMVVA5O723C4WTVITWQXWNOQL5GJ2PW/
Ionela Voinescu (2):
cppc_cpufreq: clean up cpu, cpu_num and cpunum variable use
cppc_cpufreq: use policy->cpu as driver of frequency setting
Zeng Heng (1):
cppc_cpufreq: get cpunum from fb_ctrs instead of smp_processor_id()
--
2.25.1
https://gitee.com/openeuler/kernel/issues/I8TPP6
https://gitee.com/openeuler/kernel/issues/I8ELKA
Link:https://gitee.com/openeuler/kernel/pulls/6471
Reviewed-by: Wei Li <liwei391@huawei.com>
Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v5.11-rc1
commit d2641a5c3d5ecaa1078225e493c7fed821715a04
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I8TPP6
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d2641a5c3d5ecaa1078225e493c7fed821715a04
--------------------------------
Considering only the currently supported coordination types (ANY, HW,
NONE), this change only makes a difference for the ANY type, when
policy->cpu is hotplugged out. In that case the new policy->cpu will
be different from ((struct cppc_cpudata *)policy->driver_data)->cpu.
While in this case the controls of *ANY* CPU could be used to drive
frequency changes, it's more consistent to use policy->cpu as the
leading CPU, as used in all other cppc_cpufreq functions. Additionally,
the debug prints in cppc_set_perf() would no longer create confusion
when referring to a CPU that is hotplugged out.
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
(cherry picked from commit ce5a3a8e5973daeea8e96dc967208166c4918aeb)
|
|
mainline inclusion
from mainline-v5.11-rc1
commit 48ad8dc94032ab43f0655190d9687f6d65b98f7f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I8TPP6
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48ad8dc94032ab43f0655190d9687f6d65b98f7f
--------------------------------
In order to maintain the typical naming convention in the cpufreq
framework:
- replace the use of "cpu" variable name for cppc_cpudata pointers
with "cpu_data"
- replace variable names "cpu_num" and "cpunum" with "cpu"
- make cpu variables unsigned int
Where pertinent, also move the initialisation of cpu_data variable to
its declaration and make consistent use of the local "cpu" variable.
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
(cherry picked from commit 8aa11dc8deeca7916a9fb6ef2d9425af0a12ba25)
|
|
hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I8ELKA
----------------------------------------
In cppc_cpufreq_get_rate(), when the platform doesn't have AMU and call
cppc_get_perf_ctrs_sample() directly, it needs target cpunum argument
but not get local cpu by smp_processor_id().
Here introduce the struct fb_ctr_pair which includes the target cpunum,
and acts as the parameter of cppc_get_perf_ctrs_sample().
Fixes: 904d9dcde3e6 ("cpufreq: CPPC: keep target core awake when reading its cpufreq rate")
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
(cherry picked from commit 733bb2cd81bdee2f0f40e4ea1d92b5bc36a06656)
|
|
stable inclusion
from stable-v5.15.5
commit a51a6da375d82aed5c8f83abd13e7d060421bd48
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNF8
CVE: CVE-2021-47212
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a51a6da375d82aed5c8f83abd13e7d060421bd48
--------------------------------
[ Upstream commit ba50cd9451f6c49cf0841c0a4a146ff6a2822699 ]
In the fast unload flow, the device state is set to internal error,
which indicates that the driver started the destroy process.
In this case, when a destroy command is being executed, it should return
MLX5_CMD_STAT_OK.
Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK
instead of EIO.
This fixes a call trace in the umem release process -
[ 2633.536695] Call Trace:
[ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]
[ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core]
[ 2633.539641] disable_device+0x8c/0x130 [ib_core]
[ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core]
[ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core]
[ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib]
[ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary]
[ 2633.544661] device_release_driver_internal+0x103/0x1f0
[ 2633.545679] bus_remove_device+0xf7/0x170
[ 2633.546640] device_del+0x181/0x410
[ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core]
[ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core]
[ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core]
[ 2633.550864] remove_one+0x69/0xe0 [mlx5_core]
[ 2633.551819] pci_device_remove+0x3b/0xc0
[ 2633.552731] device_release_driver_internal+0x103/0x1f0
[ 2633.553746] unbind_store+0xf6/0x130
[ 2633.554657] kernfs_fop_write+0x116/0x190
[ 2633.555567] vfs_write+0xa5/0x1a0
[ 2633.556407] ksys_write+0x4f/0xb0
[ 2633.557233] do_syscall_64+0x5b/0x1a0
[ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 2633.559018] RIP: 0033:0x7f9977132648
[ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
[ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648
[ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001
[ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740
[ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0
[ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c
[ 2633.568725] ---[ end trace 10b4fe52945e544d ]---
conflicts:
drivers/net/ethernet/mellanox/mlx5/core/cmd.c
Fixes: 6a6fabbfa3e8 ("net/mlx5: Update pci error handler entries and command translation")
Signed-off-by: Neta Ostrovsky <netao@nvidia.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Xiang Yang <xiangyang3@huawei.com>
(cherry picked from commit fedc327ddee9c982f7ed1d1e748884dc5161f644)
|
|
stable inclusion
from stable-v5.10.215
commit 7936e5c8da5bc975dec7e1e31e05da154f140cf6
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917JN
CVE: CVE-2024-24861
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7936e5c8da5bc975dec7e1e31e05da154f140cf6
--------------------------------
[ Upstream commit 36d503ad547d1c75758a6fcdbec2806f1b6aeb41 ]
In xc4000_get_frequency():
*freq = priv->freq_hz + priv->freq_offset;
The code accesses priv->freq_hz and priv->freq_offset without holding any
lock.
In xc4000_set_params():
// Code that updates priv->freq_hz and priv->freq_offset
...
xc4000_get_frequency() and xc4000_set_params() may execute concurrently,
risking inconsistent reads of priv->freq_hz and priv->freq_offset. Since
these related data may update during reading, it can result in incorrect
frequency calculation, leading to atomicity violations.
This possible bug is found by an experimental static analysis tool
developed by our team, BassCheck[1]. This tool analyzes the locking APIs
to extract function pairs that can be concurrently executed, and then
analyzes the instructions in the paired functions to identify possible
concurrency bugs including data races and atomicity violations. The above
possible bug is reported when our tool analyzes the source code of
Linux 6.2.
To address this issue, it is proposed to add a mutex lock pair in
xc4000_get_frequency() to ensure atomicity. With this patch applied, our
tool no longer reports the possible bug, with the kernel configuration
allyesconfig for x86_64. Due to the lack of associated hardware, we cannot
test the patch in runtime testing, and just verify it according to the
code logic.
[1] https://sites.google.com/view/basscheck/
Fixes: 4c07e32884ab ("[media] xc4000: Fix get_frequency()")
Cc: stable@vger.kernel.org
Reported-by: BassCheck <bass@buaa.edu.cn>
Signed-off-by: Gui-Dong Han <2045gemini@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Ma Wupeng <mawupeng1@huawei.com>
(cherry picked from commit d75e5a505bb38f3b6882bd1c72f97e26e0af1356)
|
|
function
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5195
PR sync from: Zheng Yejian <zhengyejian1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/O72YUEP2GLKL2NC6L4K3AZTXAWXJMML5/
https://gitee.com/src-openeuler/kernel/issues/I97NHW
Link:https://gitee.com/openeuler/kernel/pulls/6412
Reviewed-by: Xu Kuohai <xukuohai@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.209
commit 20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NHA
CVE: CVE-2023-52493
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e
--------------------------------
Ensure read and write locks for the channel are not taken in succession by
dropping the read lock from parse_xfer_event() such that a callback given
to client can potentially queue buffers and acquire the write lock in that
process. Any queueing of buffers should be done without channel read lock
acquired as it can result in multiple locks and a soft lockup.
Cc: <stable@vger.kernel.org> # 5.7
Fixes: 1d3173a3bae7 ("bus: mhi: core: Add support for processing events from client device")
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1702276972-41296-3-git-send-email-quic_qianyu@quicinc.com
[mani: added fixes tag and cc'ed stable]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Guan Jing <guanjing6@huawei.com>
(cherry picked from commit d5ff8b7b24d0b98f57526f241f157df2c5a14244)
|
|
stable inclusion
from stable-v5.10.210
commit 9de69732dde4e443c1c7f89acbbed2c45a6a8e17
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I97NHW
CVE: CVE-2023-52492
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9de69732dde4e443c1c7f89acbbed2c45a6a8e17
---------------------------
[ Upstream commit f5c24d94512f1b288262beda4d3dcb9629222fc7 ]
__dma_async_device_channel_register() can fail. In case of failure,
chan->local is freed (with free_percpu()), and chan->local is nullified.
When dma_async_device_unregister() is called (because of managed API or
intentionally by DMA controller driver), channels are unconditionally
unregistered, leading to this NULL pointer:
[ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
[...]
[ 1.484499] Call trace:
[ 1.486930] device_del+0x40/0x394
[ 1.490314] device_unregister+0x20/0x7c
[ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0
Look at dma_async_device_register() function error path, channel device
unregistration is done only if chan->local is not NULL.
Then add the same condition at the beginning of
__dma_async_device_channel_unregister() function, to avoid NULL pointer
issue whatever the API used to reach this function.
Fixes: d2fb0a043838 ("dmaengine: break out channel registration")
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20231213160452.2598073-1-amelie.delaunay@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
(cherry picked from commit 3923c8f0ff8589787909350f5f607b334509c377)
|
|
Merge Pull Request from: @ci-robot
PR sync from: Chen Ridong <chenridong@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/H4KAPZ7W3PV2SLPEG46EARTNZU32S7MG/
*** BLURB HERE ***
Chen Ridong (1):
cgroup_writeback: fix softlockup for blkcg->memcg_list
Lu Jialin (1):
cgroup_writeback: fix deadlock in cgroup1_writeback
--
2.34.1
https://gitee.com/openeuler/kernel/issues/I8Y0RW
https://gitee.com/openeuler/kernel/issues/I99KM6
Link:https://gitee.com/openeuler/kernel/pulls/6299
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I99KM6
--------------------------------
When multi tasks write memory.wb_blkio_ino of a memcg at same time, it may
insert same node to blkcg->memcg_list, which will lead to softlockup.
This is because no protection when write blkcg->memcg_list, and it may
also lead to NULL pointer dereference when write and rmdir same memcg
at the same time. So add spin_lock to protect blkcg->memcg_list.
The error logs:
watchdog: BUG: soft lockup - CPU#4 stuck for 23s! [rmdir:938142]
[ 5716.668802] ? irq_work_claim+0x25/0x60
[ 5716.668812] ? __list_add_valid+0x9c/0xe0
[ 5716.668820] wb_kill_blkcg+0x19f/0x310
[ 5716.668829] wb_kill_memcg_blkcg+0x8d/0xa0
[ 5716.668837] kill_css+0x89/0xd0
[ 5716.668846] cgroup_destroy_locked+0x1c6/0x380
[ 5716.668855] ? css_has_online_children+0x110/0x110
[ 5716.668864] ? selinux_inode_setxattr+0x4e0/0x4e0
[ 5716.668876] cgroup_rmdir+0x37/0x140
[ 5716.668888] kernfs_iop_rmdir+0xbb/0xf0
[ 5716.668898] vfs_rmdir.part.0+0xa5/0x230
[ 5716.668909] do_rmdir+0x2e0/0x320
[ 5716.668926] ? do_file_open_root+0x330/0x330
[ 5716.668933] ? __check_object_size+0x38/0x50
[ 5716.668942] ? getname_flags+0x14d/0x320
[ 5716.668952] do_syscall_64+0x33/0x40
[ 5716.668961] entry_SYSCALL_64_after_hwframe+0x62/0xc7
[ 5716.668968] RIP: 0033:0x7f742706cafb
Fixes: 404067a201b1 ("cgroup_writeback: fix deadlock in cgroup1_writeback")
Signed-off-by: Chen Ridong <chenridong@huawei.com>
|
|
hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I8Y0RW
--------------------------------
When read/write memory.wb_blkio_ino of a memcg, and delete the
memcg at the same time, it could cause deadlock as below:
CPU0 CPU1
rlock(kn->active#4);
lock(cgroup_mutex);
lock(kn->active#4);
lock(cgroup_mutex);
Therefore, delete locking cgroup_mutex in reading/writing
memory.wb_blkio_ino, just use refcnt and rcu to make sure that
the blkcg exists.
Fixes: 13b8199f0a47 ("cgroup: support cgroup writeback on cgroupv1")
Signed-off-by: Lu Jialin <lujialin4@huawei.com>
Signed-off-by: Chen Ridong <chenridong@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/GZOZCFLE4SO23YVGWCJHPWXUS3V2VRXR/
Bart Van Assche (2):
fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
--
2.39.2
https://gitee.com/src-openeuler/kernel/issues/I9E2O3
Link:https://gitee.com/openeuler/kernel/pulls/6088
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/XCAFV3WPH6WMCNBZIEXV4T5URGO5KJ2C/
All patches are from 5.15.y.
Namjae Jeon (4):
ksmbd: return STATUS_NOT_SUPPORTED on unsupported smb2.0 dialect
ksmbd: return unsupported error on smb1 mount
ksmbd: fix slab-out-of-bounds in init_smb2_rsp_hdr
ksmbd: fix out of bounds in init_smb2_rsp_hdr()
--
2.34.3
https://gitee.com/src-openeuler/kernel/issues/I92OOJ
Link:https://gitee.com/openeuler/kernel/pulls/5968
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.212
commit 8af1c121b0102041809bc137ec600d1865eaeedd
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E466
CVE: CVE-2024-26795
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8af1c121b0102041809bc137ec600d1865eaeedd
--------------------------------
[ Upstream commit a11dd49dcb9376776193e15641f84fcc1e5980c9 ]
Offset vmemmap so that the first page of vmemmap will be mapped
to the first page of physical memory in order to ensure that
vmemmap’s bounds will be respected during
pfn_to_page()/page_to_pfn() operations.
The conversion macros will produce correct SV39/48/57 addresses
for every possible/valid DRAM_BASE inside the physical memory limits.
v2:Address Alex's comments
Suggested-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Signed-off-by: Dimitris Vlachos <dvlachos@ics.forth.gr>
Reported-by: Dimitris Vlachos <dvlachos@ics.forth.gr>
Closes: https://lore.kernel.org/linux-riscv/20240202135030.42265-1-csd4492@csd.uoc.gr
Fixes: d95f1a542c3d ("RISC-V: Implement sparsemem")
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Link: https://lore.kernel.org/r/20240229191723.32779-1-dvlachos@ics.forth.gr
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Zheng Zucheng <zhengzucheng@huawei.com>
(cherry picked from commit 9428674e43389966e73ee74f904630c5a963f33a)
|
|
Merge Pull Request from: @ci-robot
PR sync from: Yi Yang <yiyang13@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/RUFRESPIBEY6Z5LTEVC4BQBZYHR4WDDM/
https://gitee.com/src-openeuler/kernel/issues/I95ATO
Link:https://gitee.com/openeuler/kernel/pulls/6194
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.9-rc1
commit 68a24aba7c593eafa8fd00f2f76407b9b32b47a9
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I91L79
CVE: CVE-2024-25739
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68a24aba7c593eafa8fd00f2f76407b9b32b47a9
--------------------------------
If the LEB size is smaller than a volume table record we cannot
have volumes.
In this case abort attaching.
Cc: Chenyuan Yang <cy54@illinois.edu>
Cc: stable@vger.kernel.org
Fixes: 801c135ce73d ("UBI: Unsorted Block Images")
Reported-by: Chenyuan Yang <cy54@illinois.edu>
Closes: https://lore.kernel.org/linux-mtd/1433EB7A-FC89-47D6-8F47-23BE41B263B3@illinois.edu/
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5093
PR sync from: Dong Chenchen <dongchenchen2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/O7HTWP5V3B4BLF724VPDAQDYH3ZNTTZN/
https://gitee.com/src-openeuler/kernel/issues/I95ASP
Link:https://gitee.com/openeuler/kernel/pulls/6182
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: Guo Mengqi <guomengqi3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/2RHSOLIAGHGVWFHM5IMDY6RE67QSRVDA/
https://gitee.com/openeuler/kernel/issues/I987V5
Link:https://gitee.com/openeuler/kernel/pulls/6219
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6186
PR sync from: Zheng Zengkai <zhengzengkai@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/TUT7U6RMB6GQGVECVSIMCDAW2WBJCHGJ/
Considering that CONFIG_X86_5LEVEL is enabled in openEuler 5.10,
Backport patch from 5.10.199 LTS to fix CVE-2023-52504.
https://nvd.nist.gov/vuln/detail/CVE-2023-52504
Kirill A. Shutemov (1):
x86/alternatives: Disable KASAN in apply_alternatives()
--
2.20.1
https://gitee.com/src-openeuler/kernel/issues/I95AT0
Link:https://gitee.com/openeuler/kernel/pulls/6239
Reviewed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: Guo Mengqi <guomengqi3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/P4ZRCHH27WJXHGHVWOTG6DWJFMGVFGCV/
https://gitee.com/src-openeuler/kernel/issues/I95AT9
Link:https://gitee.com/openeuler/kernel/pulls/6220
Reviewed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: Guo Mengqi <guomengqi3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/AJYTIMBKZEIK4QGDQGNUBRZDEYUSRFBA/
https://gitee.com/src-openeuler/kernel/issues/I956G4
Link:https://gitee.com/openeuler/kernel/pulls/6237
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
memory region as reserved
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6192
PR sync from: Guo Mengqi <guomengqi3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LUTEEIX2FIUHDJP642TH662A63LGX3L2/
https://gitee.com/src-openeuler/kernel/issues/I95ATF
Link:https://gitee.com/openeuler/kernel/pulls/6233
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.199
commit 6788b10620ca6e98575d1e06e72a8974aad7657e
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95AT0
CVE: CVE-2023-52504
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6788b10620ca6e98575d1e06e72a8974aad7657e
--------------------------------
commit d35652a5fc9944784f6f50a5c979518ff8dacf61 upstream.
Fei has reported that KASAN triggers during apply_alternatives() on
a 5-level paging machine:
BUG: KASAN: out-of-bounds in rcu_is_watching()
Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
...
__asan_load4()
rcu_is_watching()
trace_hardirqs_on()
text_poke_early()
apply_alternatives()
...
On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().
KASAN gets confused when apply_alternatives() patches the
KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.
Fix it for real by disabling KASAN while the kernel is patching alternatives.
[ mingo: updated the changelog ]
Fixes: 6657fca06e3f ("x86/mm: Allow to boot without LA57 if CONFIG_X86_5LEVEL=y")
Reported-by: Fei Yang <fei.yang@intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231012100424.1456-1-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
(cherry picked from commit d02f1abb540834bbd01ee4ecd0dcb7969335cccb)
|
|
mainline inclusion
from mainline-v5.13-rc3
commit 0b0226be3a52dadd965644bc52a807961c2c26df
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I956G4
CVE: CVE-2021-47070
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b0226be3a52dadd965644bc52a807961c2c26df
--------------------------------
Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe
function is never freed in the error handling path.
Add the missing 'vmbus_free_ring()' call.
Note that it is already freed in the .remove function.
Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/0d86027b8eeed8e6360bc3d52bcdb328ff9bdca1.1620544055.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
conflicts:
drivers/uio/uio_hv_generic.c
Signed-off-by: Guo Mengqi <guomengqi3@huawei.com>
|
|
mainline inclusion
from mainline-v6.6-rc1
commit 110e70fccce4f22b53986ae797d665ffb1950aa6
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ATF
CVE: CVE-2023-52561
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=110e70fccce4f22b53986ae797d665ffb1950aa6
--------------------------------
[ Upstream commit 110e70fccce4f22b53986ae797d665ffb1950aa6 ]
Adding a reserved memory region for the framebuffer memory
(the splash memory region set up by the bootloader).
It fixes a kernel panic (arm-smmu: Unhandled context fault
at this particular memory region) reported on DB845c running
v5.10.y.
Cc: stable@vger.kernel.org # v5.10+
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230726132719.2117369-2-amit.pundir@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Guo Mengqi <guomengqi3@huawei.com>
(cherry picked from commit 3f27eeaae7292741c589519cebc10e8f778b6d10)
|
|
mainline inclusion
from mainline-v5.13-rc3
commit 0b0226be3a52dadd965644bc52a807961c2c26df
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I956G4
CVE: CVE-2021-47070
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b0226be3a52dadd965644bc52a807961c2c26df
--------------------------------
Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe
function is never freed in the error handling path.
Add the missing 'vmbus_free_ring()' call.
Note that it is already freed in the .remove function.
Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/0d86027b8eeed8e6360bc3d52bcdb328ff9bdca1.1620544055.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
conflicts:
drivers/uio/uio_hv_generic.c
Signed-off-by: Guo Mengqi <guomengqi3@huawei.com>
(cherry picked from commit 68ed071878cb4a75ab7f9b6475d8590579c46e4e)
|
|
Merge Pull Request from: @ci-robot
PR sync from: Guo Mengqi <guomengqi3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/76OROQTRIS4YZ2TEJ4VPUOE34AIHAXYQ/
https://gitee.com/openeuler/kernel/issues/I9AWJ5
Link:https://gitee.com/openeuler/kernel/pulls/6195
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
read in ath9k_htc_txstatus()
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5466
PR sync from: Guo Mengqi <guomengqi3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/67CUQMMIYM27HQMJPQCEPRHBVNHOI7CH/
https://gitee.com/src-openeuler/kernel/issues/I96G7W
Link:https://gitee.com/openeuler/kernel/pulls/6191
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.198
commit ae806c74c0634b0c23855066d8ba28d850fd1260
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95AT9
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ae806c74c0634b0c23855066d8ba28d850fd1260
--------------------------------
[ Upstream commit 01b057b2f4cc2d905a0bd92195657dbd9a7005ab ]
If the user has requested no SRSO mitigation, other mitigations can use
the lighter-weight SBPB instead of IBPB.
Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/b20820c3cfd1003171135ec8d762a0b957348497.1693889988.git.jpoimboe@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: sanglipeng <sanglipeng1@jd.com>
|
|
stable inclusion
from stable-v5.10.198
commit 0d520cdb0cd095eac5d00078dfd318408c9b5eed
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I987V5
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0d520cdb0cd095eac5d00078dfd318408c9b5eed
--------------------------------
commit 53a3f777049771496f791504e7dc8ef017cba590 upstream.
In case immediate MPA request processing fails, the newly
created endpoint unlinks the listening endpoint and is
ready to be dropped. This special case was not handled
correctly by the code handling the later TCP socket close,
causing a NULL dereference crash in siw_cm_work_handler()
when dereferencing a NULL listener. We now also cancel
the useless MPA timeout, if immediate MPA request
processing fails.
This patch furthermore simplifies MPA processing in general:
Scheduling a useless TCP socket read in sk_data_ready() upcall
is now surpressed, if the socket is already moved out of
TCP_ESTABLISHED state.
Fixes: 6c52fdc244b5 ("rdma/siw: connection management")
Signed-off-by: Bernard Metzler <bmt@zurich.ibm.com>
Link: https://lore.kernel.org/r/20230905145822.446263-1-bmt@zurich.ibm.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: sanglipeng <sanglipeng1@jd.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5770
PR sync from: Yihang Li <liyihang9@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/FC7IJTYWFKOM2YNCUWGC3KNMOO3QF2D5/
This patchset includes 2 minor changes
- For interrupt coalescing, the count of CQ entries is set to 10, and the
interrupt coalescing timeout period is set to 10us.
- Add cond_resched() to cq_thread_v3_hw() to execute the watchdog thread.
Changes since v1:
- Remove unnecessary comments.
- Update the commit message for patch 1.
Yihang Li (2):
scsi: hisi_sas: Default enable interrupt coalescing
scsi: hisi_sas: Add cond_resched() to cq_thread_v3_hw()
--
2.33.0
https://gitee.com/openeuler/kernel/issues/I9BBFQ
Link:https://gitee.com/openeuler/kernel/pulls/6187
Reviewed-by: Yihang Li <liyihang9@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/E6GO5RWT5FEX5BZG6Z7A47F342WKQOBZ/
https://gitee.com/src-openeuler/kernel/issues/I95AUA
Link:https://gitee.com/openeuler/kernel/pulls/6115
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.199
commit da7ce52a2f6c468946195b116615297d3d113a27
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I9AWJ5
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=da7ce52a2f6c468946195b116615297d3d113a27
--------------------------------
commit f4384b3e54ea813868bb81a861bf5b2406e15d8f upstream.
There is a potential race condition in amdtee_close_session that may
cause use-after-free in amdtee_open_session. For instance, if a session
has refcount == 1, and one thread tries to free this session via:
kref_put(&sess->refcount, destroy_session);
the reference count will get decremented, and the next step would be to
call destroy_session(). However, if in another thread,
amdtee_open_session() is called before destroy_session() has completed
execution, alloc_session() may return 'sess' that will be freed up
later in destroy_session() leading to use-after-free in
amdtee_open_session.
To fix this issue, treat decrement of sess->refcount and removal of
'sess' from session list in destroy_session() as a critical section, so
that it is executed atomically.
Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver")
Cc: stable@vger.kernel.org
Signed-off-by: Rijo Thomas <Rijo-john.Thomas@amd.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: sanglipeng <sanglipeng1@jd.com>
|
|
stable inclusion
from stable-v5.10.198
commit e14afa4450cb7e4cf93e993a765801203d41d014
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ATO
CVE: CVE-2023-52567
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e14afa4450cb7e4cf93e993a765801203d41d014
--------------------------------
commit cce7fc8b29961b64fadb1ce398dc5ff32a79643b upstream.
In case the leaf driver wants to use IRQ polling (irq = 0) and
IIR register shows that an interrupt happened in the 8250 hardware
the IRQ data can be NULL. In such a case we need to skip the wake
event as we came to this path from the timer interrupt and quite
likely system is already awake.
Without this fix we have got an Oops:
serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A
...
BUG: kernel NULL pointer dereference, address: 0000000000000010
RIP: 0010:serial8250_handle_irq+0x7c/0x240
Call Trace:
? serial8250_handle_irq+0x7c/0x240
? __pfx_serial8250_timeout+0x10/0x10
Fixes: 0ba9e3a13c6a ("serial: 8250: Add missing wakeup event reporting")
Cc: stable <stable@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20230831222555.614426-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yi Yang <yiyang13@huawei.com>
|
|
ath9k_htc_txstatus()
stable inclusion
from stable-v5.10.210
commit 84770a996ad8d7f121ff2fb5a8d149aad52d64c1
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I96G7W
CVE: CVE-2023-52594
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=84770a996ad8d7f121ff2fb5a8d149aad52d64c1
--------------------------------
[ Upstream commit 2adc886244dff60f948497b59affb6c6ebb3c348 ]
Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug
occurs when txs->cnt, data from a URB provided by a USB device, is
bigger than the size of the array txs->txstatus, which is
HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug
handling code after the check. Make the function return if that is the
case.
Found by a modified version of syzkaller.
UBSAN: array-index-out-of-bounds in htc_drv_txrx.c
index 13 is out of range for type '__wmi_event_txstatus [12]'
Call Trace:
ath9k_htc_txstatus
ath9k_wmi_event_tasklet
tasklet_action_common
__do_softirq
irq_exit_rxu
sysvec_apic_timer_interrupt
Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20231113065756.1491991-1-linuxlovemin@yonsei.ac.kr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Guo Mengqi <guomengqi3@huawei.com>
(cherry picked from commit 0a990ed10af934161adb287f085f26250e7ff00d)
|
|
driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I9BBFQ
CVE: NA
----------------------------------------------------------------------
In the scenario where the expander is connected to 12 SAS SSDs, the
following call trace may occur:
[ 214.409199][ C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211]
[ 214.545262][ C240] CPU: 240 PID: 3211 Comm: irq/149-hisi_sa Kdump: loaded Tainted: G E 5.10.0 #1
[ 214.568533][ C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 214.575224][ C240] pc : fput_many+0x8c/0xdc
[ 214.579480][ C240] lr : fput+0x1c/0xf0
[ 214.583302][ C240] sp : ffff80002de2b900
[ 214.587298][ C240] x29: ffff80002de2b900 x28: ffff1082aa412000
[ 214.593291][ C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000
[ 214.599284][ C240] x25: ffff1062bbac5c40 x24: 0000000000001000
[ 214.605277][ C240] x23: 000000000000000a x22: 0000000000000001
[ 214.611270][ C240] x21: 0000000000001000 x20: 0000000000000000
[ 214.617262][ C240] x19: ffff3062a41ae580 x18: 0000000000010000
[ 214.623255][ C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0
[ 214.629248][ C240] x15: ffffffffffffffff x14: 0000000003ffffff
[ 214.635241][ C240] x13: 000000000000ffff x12: 000000000000029c
[ 214.641234][ C240] x11: 0000000000000006 x10: ffff80003a9f7fd0
[ 214.647226][ C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001
[ 214.653219][ C240] x7 : 0000000000000002 x6 : 0000000000000080
[ 214.659212][ C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554
[ 214.665205][ C240] x3 : 0000000000000002 x2 : 0000000000000020
[ 214.671198][ C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8
[ 214.677191][ C240] Call trace:
[ 214.680320][ C240] fput_many+0x8c/0xdc
[ 214.684230][ C240] fput+0x1c/0xf0
[ 214.687707][ C240] aio_complete_rw+0xd8/0x1fc
[ 214.692225][ C240] blkdev_bio_end_io+0x98/0x140
[ 214.696917][ C240] bio_endio+0x160/0x1bc
[ 214.701001][ C240] blk_update_request+0x1c8/0x3bc
[ 214.705867][ C240] scsi_end_request+0x3c/0x1f0
[ 214.710471][ C240] scsi_io_completion+0x7c/0x1a0
[ 214.715249][ C240] scsi_finish_command+0x104/0x140
[ 214.720200][ C240] scsi_softirq_done+0x90/0x180
[ 214.724892][ C240] blk_mq_complete_request+0x5c/0x70
[ 214.730016][ C240] scsi_mq_done+0x48/0xac
[ 214.734194][ C240] sas_scsi_task_done+0xbc/0x16c [libsas]
[ 214.739758][ C240] slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw]
[ 214.746185][ C240] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw]
[ 214.752179][ C240] irq_thread_fn+0x34/0xa4
[ 214.756435][ C240] irq_thread+0xc4/0x130
[ 214.760520][ C240] kthread+0x108/0x13c
[ 214.764430][ C240] ret_from_fork+0x10/0x18
This is because in the hisi_sas driver, both the hardware interrupt
handler and the interrupt thread are executed on the same CPU. In the
performance test scenario, a large number of hardware interrupts and
interrupt processing threads continuously occupy the CPU. As a result,
the CPU cannot run the watchdog thread. When the watchdog time exceeds
the specified time, call trace occurs.
To fix it, add cond_resched() to cq_thread_v3_hw() to execute the watchdog
thread.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Signed-off-by: Bing Xia <xiabing12@h-partners.com>
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
(cherry picked from commit 6c932bdded7de9684046c138065cdc73fef6f7ba)
|
|
driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I9BBFQ
CVE: NA
----------------------------------------------------------------------
In the current interrupt reporting mode, each CQ entry reports an
interrupt. However, when there are a large number of I/O completion
interrupts, the following issue may occur:
[ 4682.678657][ C129] irq 134: nobody cared (try booting with the "irqpoll" option)
[ 4682.686137][ C129] CPU: 129 PID: 2567 Comm: irq/134-hisi_sa Kdump: loaded Tainted: G OE 5.10.0 #1
[ 4682.696297][ C129] Hardware name: To be filled by O.E.M. KpxxxEVB 2P2T2N TB/To be filled by O.E.M., BIOS KpxxxEVB 2P2T2N TB 03/23/2023
[ 4682.708455][ C129] Call trace:
[ 4682.711589][ C129] dump_backtrace+0x0/0x1e4
[ 4682.715934][ C129] show_stack+0x20/0x2c
[ 4682.719933][ C129] dump_stack+0xd8/0x140
[ 4682.724017][ C129] __report_bad_irq+0x54/0x180
[ 4682.728625][ C129] note_interrupt+0x1ec/0x2f0
[ 4682.733143][ C129] handle_irq_event+0x118/0x1ac
[ 4682.737834][ C129] handle_fasteoi_irq+0xc8/0x200
[ 4682.742613][ C129] __handle_domain_irq+0x84/0xf0
[ 4682.747391][ C129] gic_handle_irq+0x88/0x2c0
[ 4682.751822][ C129] el1_irq+0xbc/0x140
[ 4682.755648][ C129] _find_next_bit.constprop.0+0x20/0x94
[ 4682.761036][ C129] cpumask_next+0x24/0x30
[ 4682.765208][ C129] gic_ipi_send_mask+0x48/0x170
[ 4682.769900][ C129] __ipi_send_mask+0x34/0x110
[ 4682.775720][ C129] smp_cross_call+0x3c/0xcc
[ 4682.780064][ C129] arch_send_call_function_single_ipi+0x38/0x44
[ 4682.786146][ C129] send_call_function_single_ipi+0xd0/0xe0
[ 4682.791794][ C129] generic_exec_single+0xb4/0x170
[ 4682.796659][ C129] smp_call_function_single_async+0x2c/0x40
[ 4682.802395][ C129] blk_mq_complete_request_remote.part.0+0xec/0x100
[ 4682.808822][ C129] blk_mq_complete_request+0x30/0x70
[ 4682.813950][ C129] scsi_mq_done+0x48/0xac
[ 4682.818128][ C129] sas_scsi_task_done+0xb0/0x150 [libsas]
[ 4682.823692][ C129] slot_complete_v3_hw+0x230/0x710 [hisi_sas_v3_hw]
[ 4682.830120][ C129] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw]
[ 4682.836114][ C129] irq_thread_fn+0x34/0xa4
[ 4682.840371][ C129] irq_thread+0xc4/0x130
[ 4682.844455][ C129] kthread+0x108/0x13c
[ 4682.848365][ C129] ret_from_fork+0x10/0x18
[ 4682.852621][ C129] handlers:
[ 4682.855577][ C129] [<00000000949e52bf>] cq_interrupt_v3_hw [hisi_sas_v3_hw] threaded [<000000005d8e3b68>] cq_thread_v3_hw [hisi_sas_v3_hw]
[ 4682.868084][ C129] Disabling IRQ #134
When the IRQ management layer processes each hardware interrupt, if the
return value of the interrupt handler is IRQ_WAKE_THREAD, it will wake up
the handler thread for this interrupt action and set IRQTF_RUNTHREAD flag,
wait for the interrupt handling thread to clear the IRQTF_RUNTHREAD flag
after execution. Later in note_interrupt(), use irq_count to count
hardware interrupts and irqs_unhandled to count interrupts for which no
thread handler is responsible. When irq_count reaches 100000 and
irqs_unhandled reaches 99000, irq will be disabled.
In the performance test scenario, I/O completion hardware interrupts are
continuously and quickly generated. As a result, the interrupt processing
thread is cyclically called in irq_thread() and does not exit, this
affects the response of the interrupt thread to the hardware interrupt.
Finally, the irq is disabled.
Therefore, default enable interrupt coalescing to reduce the generation of
hardware interrupts, this helps interrupt processing threads to stop
calling in irq_thread().
For interrupt coalescing, the count of CQ entries is set to 10, and the
interrupt coalescing timeout period is set to 10us.
After interrupt coalescing is enabled by default, for fio with 4K read 32
iodepth scenario, the performance is improved by about 4% (1342k -> 1396k).
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Signed-off-by: Bing Xia <xiabing12@h-partners.com>
(cherry picked from commit 7c1d68136323fff20caeae4ba4b6af15820b6799)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6137
PR sync from: Yang Yingliang <yangyingliang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/EH4BFOSOOARIXNWWJTM3TACVNQ3FGXNI/
https://gitee.com/src-openeuler/kernel/issues/I9E6TS
Link:https://gitee.com/openeuler/kernel/pulls/6174
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v5.12-rc6
commit 31db78a4923ef5e2008f2eed321811ca79e7f71b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ASP
CVE: CVE-2023-52530
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=31db78a4923ef5e2008f2eed321811ca79e7f71b
--------------------------------
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
but returns 0 due to KRACK protection (identical key reinstall),
ieee80211_gtk_rekey_add() will still return a pointer into the
key, in a potential use-after-free. This normally doesn't happen
since it's only called by iwlwifi in case of WoWLAN rekey offload
which has its own KRACK protection, but still better to fix, do
that by returning an error code and converting that to success on
the cfg80211 boundary only, leaving the error for bad callers of
ieee80211_gtk_rekey_add().
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Conflicts:
net/mac80211/cfg.c
Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com>
(cherry picked from commit a4f4c7258e064db59adf4684f6393a0d5953ffb8)
|
|
Merge Pull Request from: @ci-robot
PR sync from: Cheng Yu <serein.chengyu@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/Q4FS7HJ5F5ATTNFXRCV3G6S7EEIUX2RS/
fix-CVE-2021-47101-openEuler-22.03-LTS-SP2
Pavel Skripkin (3):
net: asix: fix uninit value bugs
asix: fix uninit-value in asix_mdio_read()
asix: fix wrong return value in asix_check_host_enable()
--
2.25.1
https://gitee.com/src-openeuler/kernel/issues/I95RDW
Link:https://gitee.com/openeuler/kernel/pulls/6128
Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.9-rc1
commit 810cd4bb53456d0503cc4e7934e063835152c1b7
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E6TS
CVE: CVE-2024-26810
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=810cd4bb53456d0503cc4e7934e063835152c1b7
-------------------------------------------
Mask operations through config space changes to DisINTx may race INTx
configuration changes via ioctl. Create wrappers that add locking for
paths outside of the core interrupt code.
In particular, irq_type is updated holding igate, therefore testing
is_intx() requires holding igate. For example clearing DisINTx from
config space can otherwise race changes of the interrupt configuration.
This aligns interfaces which may trigger the INTx eventfd into two
camps, one side serialized by igate and the other only enabled while
INTx is configured. A subsequent patch introduces synchronization for
the latter flows.
Cc: <stable@vger.kernel.org>
Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Link: https://lore.kernel.org/r/20240308230557.805580-3-alex.williamson@redhat.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Conflicts:
drivers/vfio/pci/vfio_pci_intrs.c
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
(cherry picked from commit e875c3ec3461b0f16bd93816dd8582458569f513)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5717
PR sync from: Yu Liao <liaoyu15@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/U2J3RS5UMVBWXJII3EDMWO4YP4OISISZ/
Daniel Vacek (1):
IB/ipoib: Fix mcast list locking
Jack Wang (1):
RDMA/IPoIB: Fix error code return in ipoib_mcast_join
--
2.25.1
https://gitee.com/src-openeuler/kernel/issues/I96G8W
Link:https://gitee.com/openeuler/kernel/pulls/6156
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6101
PR sync from: Jinjie Ruan <ruanjinjie@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/2PSSMOYLN5J2IPSJF5P5Q4IOHQUNLFIC/
https://gitee.com/src-openeuler/kernel/issues/I9E6TU
Link:https://gitee.com/openeuler/kernel/pulls/6150
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
and netvsc_remove
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6047
PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/RHHXHXWLIDZKBDEZ2X4RW5BW6YVKY5TK/
https://gitee.com/src-openeuler/kernel/issues/I9E2GU
Link:https://gitee.com/openeuler/kernel/pulls/6146
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
damon_do_test_apply_three_regions()
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/4923
PR sync from: Ze Zuo <zuoze1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/WBG6ZXZHXSZZRZDPEVBNK4G7GSHAG7ZQ/
https://gitee.com/src-openeuler/kernel/issues/I95ATG
Link:https://gitee.com/openeuler/kernel/pulls/6133
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5317
PR sync from: Ze Zuo <zuoze1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HCQYSNRNP26GKEFGZOTQJHP6XGQVAHOB/
https://gitee.com/src-openeuler/kernel/issues/I96GPO
Link:https://gitee.com/openeuler/kernel/pulls/5421
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.210
commit ac2630fd3c90ffec34a0bfc4d413668538b0e8f2
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I96G8W
CVE: CVE-2023-52587
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ac2630fd3c90ffec34a0bfc4d413668538b0e8f2
--------------------------------
[ Upstream commit 4f973e211b3b1c6d36f7c6a19239d258856749f9 ]
Releasing the `priv->lock` while iterating the `priv->multicast_list` in
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
-----------------------------------+-----------------------------------
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
&priv->multicast_list, list) |
ipoib_mcast_join(dev, mcast) |
spin_unlock_irq(&priv->lock) |
| spin_lock_irqsave(&priv->lock, flags)
| list_for_each_entry_safe(mcast, tmcast,
| &priv->multicast_list, list)
| list_del(&mcast->list);
| list_add_tail(&mcast->list, &remove_list)
| spin_unlock_irqrestore(&priv->lock, flags)
spin_lock_irq(&priv->lock) |
| ipoib_mcast_remove_list(&remove_list)
(Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,
`priv->multicast_list` and we keep | remove_list, list)
spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done)
the other thread which is blocked |
and the list is still valid on |
it's stack.)
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
eventual sleeps.
Unfortunately we could not reproduce the lockup and confirm this fix but
based on the code review I think this fix should address such lockups.
crash> bc 31
PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"
[exception RIP: ipoib_mcast_join_task+0x1b1]
RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002
RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
work (&priv->mcast_task{,.work})
RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
&mcast->list
RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000
R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00
mcast
R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8
dev priv (&priv->lock) &priv->multicast_list (aka head)
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yu Liao <liaoyu15@huawei.com>
(cherry picked from commit 13f968e187b2e515e9c7e36ccac95e8f47037ab9)
|
|
stable inclusion
from stable-v5.10.210
commit 3a1da8abd772b39414149a90d262cbbd44b73a37
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I96G8W
CVE: CVE-2023-52587
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3a1da8abd772b39414149a90d262cbbd44b73a37
--------------------------------
[ Upstream commit 753fff78f430704548f45eda52d6d55371a52c0f ]
Return the error code in case of ib_sa_join_multicast fail.
Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
Link: https://lore.kernel.org/r/20231121130316.126364-2-jinpu.wang@ionos.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yu Liao <liaoyu15@huawei.com>
(cherry picked from commit 77764e5a94dfa57edae5ec9ef177cfb33fb91e0d)
|
|
stable inclusion
from stable-v5.15.154
commit b7a2f0955ffceffadfe098b40b50307431f45438
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E6TU
CVE: CVE-2024-27437
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b7a2f0955ffceffadfe098b40b50307431f45438
--------------------------------
[ Upstream commit fe9a7082684eb059b925c535682e68c34d487d43 ]
Currently for devices requiring masking at the irqchip for INTx, ie.
devices without DisINTx support, the IRQ is enabled in request_irq()
and subsequently disabled as necessary to align with the masked status
flag. This presents a window where the interrupt could fire between
these events, resulting in the IRQ incrementing the disable depth twice.
This would be unrecoverable for a user since the masked flag prevents
nested enables through vfio.
Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
is never auto-enabled, then unmask as required.
Cc: <stable@vger.kernel.org>
Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Link: https://lore.kernel.org/r/20240308230557.805580-2-alex.williamson@redhat.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
(cherry picked from commit a44e497900d4e744d3bc492de825b466d78c1c7f)
|
|
stable inclusion
from stable-v5.10.210
commit 9ec807e7b6f5fcf9499f3baa69f254bb239a847f
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2GU
CVE: CVE-2024-26698
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9ec807e7b6f5fcf9499f3baa69f254bb239a847f
--------------------------------
commit e0526ec5360a48ad3ab2e26e802b0532302a7e11 upstream.
In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
VMBus channel"), napi_disable was getting called for all channels,
including all subchannels without confirming if they are enabled or not.
This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
has finished running but nvdev->subchan_work has not started yet.
netvsc_subchan_work() -> rndis_set_subchannel() has not created the
sub-channels and because of that netvsc_sc_open() is not running.
netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
netvsc_subchan_work did not run.
netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
opposite.
Now during netvsc_device_remove(), when napi_disable is called for those
subchannels, napi_disable gets stuck on infinite msleep.
This fix addresses this problem by ensuring that napi_disable() is not
getting called for non-enabled NAPI struct.
But netif_napi_del() is still necessary for these non-enabled NAPI struct
for cleanup purpose.
Call trace:
[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002
[ 654.568030] Call Trace:
[ 654.571221] <TASK>
[ 654.573790] __schedule+0x2d6/0x960
[ 654.577733] schedule+0x69/0xf0
[ 654.581214] schedule_timeout+0x87/0x140
[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20
[ 654.590291] msleep+0x2d/0x40
[ 654.593625] napi_disable+0x2b/0x80
[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
[ 654.611101] ? do_wait_intr+0xb0/0xb0
[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]
[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]
Cc: stable@vger.kernel.org
Fixes: ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel")
Signed-off-by: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/1706686551-28510-1-git-send-email-schakrabarti@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
(cherry picked from commit 89f85f4b38906e3661d932418906afd207ed78b7)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5113
PR sync from: Zhengchao Shao <shaozhengchao@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OIOS3PLH6PBZRR4FH7X7BV5IFN7NRX6C/
fix CVE-2023-52578
Eric Dumazet (2):
net: add atomic_long_t to net_device_stats fields
net: bridge: use DEV_STATS_INC()
Felix Riemann (1):
net: Fix unwanted sign extension in netdev_stats_to_stats64()
Zhengchao Shao (1):
net: fix kabi check warning
--
2.34.1
https://gitee.com/src-openeuler/kernel/issues/I95ATV
Link:https://gitee.com/openeuler/kernel/pulls/5131
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5062
PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/4XZVYTE3JFF5YGUNOZC5HAQ7VUR25N4E/
https://gitee.com/src-openeuler/kernel/issues/I95ATZ
Link:https://gitee.com/openeuler/kernel/pulls/5122
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: Pu Lehui <pulehui@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/5H5XB3OZJ2FDE2AYTRRL7V5HWMYDXX5I/
https://gitee.com/src-openeuler/kernel/issues/I96GO9
Link:https://gitee.com/openeuler/kernel/pulls/6119
Reviewed-by: Xu Kuohai <xukuohai@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/6017
PR sync from: Zhenzeng Su <suzhenzeng@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/TPBDRSS5C6HS3TNVOPL3DQONXR73VVE3/
https://gitee.com/src-openeuler/kernel/issues/I9DO1Z
Link:https://gitee.com/openeuler/kernel/pulls/6056
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
free_entries_lock
Merge Pull Request from: @ci-robot
PR sync from: Jinjiang Tu <tujinjiang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/N32GJYAUIODSM4H6WEZREIV44N24KO5K/
https://gitee.com/src-openeuler/kernel/issues/I95AXL
Link:https://gitee.com/openeuler/kernel/pulls/6121
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.6-rc4
commit 45120b15743fa7c0aa53d5db6dfb4c8f87be4abd
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95ATG
CVE: CVE-2023-52560
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=45120b15743fa7c0aa53d5db6dfb4c8f87be4abd
--------------------------------
When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary
variables"), the damon_destroy_ctx() is removed, but still call
damon_new_target() and damon_new_region(), the damon_region which is
allocated by kmem_cache_alloc() in damon_new_region() and the damon_target
which is allocated by kmalloc in damon_new_target() are not freed. And
the damon_region which is allocated in damon_new_region() in
damon_set_regions() is also not freed.
So use damon_destroy_target to free all the damon_regions and damon_target.
unreferenced object 0xffff888107c9a940 (size 64):
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff8881079cc740 (size 56):
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107c9ac40 (size 64):
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v.....
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff8881079ccc80 (size 56):
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107c9af40 (size 64):
comm "kunit_try_catch", pid 1073, jiffies 4294670597 (age 733.011s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
20 a2 76 07 81 88 ff ff b8 a6 76 07 81 88 ff ff .v.......v.....
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c877e>] damon_test_apply_three_regions3+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810776a200 (size 56):
comm "kunit_try_catch", pid 1073, jiffies 4294670597 (age 733.011s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
[<ffffffff819c877e>] damon_test_apply_three_regions3+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810776a740 (size 56):
comm "kunit_try_catch", pid 1073, jiffies 4294670597 (age 733.025s)
hex dump (first 32 bytes):
3d 00 00 00 00 00 00 00 3f 00 00 00 00 00 00 00 =.......?.......
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819bfcc2>] damon_set_regions+0x4c2/0x8e0
[<ffffffff819c7dbb>] damon_do_test_apply_three_regions.constprop.0+0xfb/0x3e0
[<ffffffff819c877e>] damon_test_apply_three_regions3+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888108038240 (size 64):
comm "kunit_try_catch", pid 1075, jiffies 4294670600 (age 733.022s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 03 00 00 00 6b 6b 6b 6b ............kkkk
48 ad 76 07 81 88 ff ff 98 ae 76 07 81 88 ff ff H.v.......v.....
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c898d>] damon_test_apply_three_regions4+0x1cd/0x210
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810776ad28 (size 56):
comm "kunit_try_catch", pid 1075, jiffies 4294670600 (age 733.022s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819bfcc2>] damon_set_regions+0x4c2/0x8e0
[<ffffffff819c7dbb>] damon_do_test_apply_three_regions.constprop.0+0xfb/0x3e0
[<ffffffff819c898d>] damon_test_apply_three_regions4+0x1cd/0x210
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
Link: https://lkml.kernel.org/r/20230925072100.3725620-1-ruanjinjie@huawei.com
Fixes: 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary variables")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: SeongJae Park <sj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ze Zuo <zuoze1@huawei.com>
(cherry picked from commit c5921e72afb06794ef5cdc7b229680e456b6b08f)
|
|
mainline inclusion
from mainline-v5.16-rc7
commit d1652b70d07cc3eed96210c876c4879e1655f20e
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95RDW
CVE: CVE-2021-47101
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1652b70d07cc3eed96210c876c4879e1655f20e
--------------------------------
If asix_read_cmd() returns 0 on 30th interation, 0 will be returned from
asix_check_host_enable(), which is logically wrong. Fix it by returning
-ETIMEDOUT explicitly if we have exceeded 30 iterations
Also, replaced 30 with #define as suggested by Andrew
Fixes: a786e3195d6a ("net: asix: fix uninit value bugs")
Reported-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/ecd3470ce6c2d5697ac635d0d3b14a47defb4acb.1640117288.git.paskripkin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Cheng Yu <serein.chengyu@huawei.com>
|
|
mainline inclusion
from mainline-v5.16-rc7
commit 8035b1a2a37a29d8c717ef84fca8fe7278bc9f03
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95RDW
CVE: CVE-2021-47101
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8035b1a2a37a29d8c717ef84fca8fe7278bc9f03
--------------------------------
asix_read_cmd() may read less than sizeof(smsr) bytes and in this case
smsr will be uninitialized.
Fail log:
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
Fixes: d9fe64e51114 ("net: asix: Add in_pm parameter")
Reported-and-tested-by: syzbot+f44badb06036334e867a@syzkaller.appspotmail.com
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Link: https://lore.kernel.org/r/8966e3b514edf39857dd93603fc79ec02e000a75.1640117288.git.paskripkin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Cheng Yu <serein.chengyu@huawei.com>
|
|
mainline inclusion
from mainline-v5.14-rc7
commit a786e3195d6af183033e86f0518ffd2c51c0e8ac
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95RDW
CVE: CVE-2021-47101
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a786e3195d6af183033e86f0518ffd2c51c0e8ac
--------------------------------
Syzbot reported uninit-value in asix_mdio_read(). The problem was in
missing error handling. asix_read_cmd() should initialize passed stack
variable smsr, but it can fail in some cases. Then while condidition
checks possibly uninit smsr variable.
Since smsr is uninitialized stack variable, driver can misbehave,
because smsr will be random in case of asix_read_cmd() failure.
Fix it by adding error handling and just continue the loop instead of
checking uninit value.
Added helper function for checking Host_En bit, since wrong loop was used
in 4 functions and there is no need in copy-pasting code parts.
Cc: Robert Foss <robert.foss@collabora.com>
Fixes: d9fe64e51114 ("net: asix: Add in_pm parameter")
Reported-by: syzbot+a631ec9e717fb0423053@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Cheng Yu <serein.chengyu@huawei.com>
|
|
stable inclusion
from stable-v5.10.198
commit c79300599923daaa30f417c75555d5566b3d31ae
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95AXL
CVE: CVE-2023-52516
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c79300599923daaa30f417c75555d5566b3d31ae
--------------------------------
[ Upstream commit fb5a4315591dae307a65fc246ca80b5159d296e1 ]
__dma_entry_alloc_check_leak() calls into printk -> serial console
output (qcom geni) and grabs port->lock under free_entries_lock
spin lock, which is a reverse locking dependency chain as qcom_geni
IRQ handler can call into dma-debug code and grab free_entries_lock
under port->lock.
Move __dma_entry_alloc_check_leak() call out of free_entries_lock
scope so that we don't acquire serial console's port->lock under it.
Trimmed-down lockdep splat:
The existing dependency chain (in reverse order) is:
-> #2 (free_entries_lock){-.-.}-{2:2}:
_raw_spin_lock_irqsave+0x60/0x80
dma_entry_alloc+0x38/0x110
debug_dma_map_page+0x60/0xf8
dma_map_page_attrs+0x1e0/0x230
dma_map_single_attrs.constprop.0+0x6c/0xc8
geni_se_rx_dma_prep+0x40/0xcc
qcom_geni_serial_isr+0x310/0x510
__handle_irq_event_percpu+0x110/0x244
handle_irq_event_percpu+0x20/0x54
handle_irq_event+0x50/0x88
handle_fasteoi_irq+0xa4/0xcc
handle_irq_desc+0x28/0x40
generic_handle_domain_irq+0x24/0x30
gic_handle_irq+0xc4/0x148
do_interrupt_handler+0xa4/0xb0
el1_interrupt+0x34/0x64
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x64/0x68
arch_local_irq_enable+0x4/0x8
____do_softirq+0x18/0x24
...
-> #1 (&port_lock_key){-.-.}-{2:2}:
_raw_spin_lock_irqsave+0x60/0x80
qcom_geni_serial_console_write+0x184/0x1dc
console_flush_all+0x344/0x454
console_unlock+0x94/0xf0
vprintk_emit+0x238/0x24c
vprintk_default+0x3c/0x48
vprintk+0xb4/0xbc
_printk+0x68/0x90
register_console+0x230/0x38c
uart_add_one_port+0x338/0x494
qcom_geni_serial_probe+0x390/0x424
platform_probe+0x70/0xc0
really_probe+0x148/0x280
__driver_probe_device+0xfc/0x114
driver_probe_device+0x44/0x100
__device_attach_driver+0x64/0xdc
bus_for_each_drv+0xb0/0xd8
__device_attach+0xe4/0x140
device_initial_probe+0x1c/0x28
bus_probe_device+0x44/0xb0
device_add+0x538/0x668
of_device_add+0x44/0x50
of_platform_device_create_pdata+0x94/0xc8
of_platform_bus_create+0x270/0x304
of_platform_populate+0xac/0xc4
devm_of_platform_populate+0x60/0xac
geni_se_probe+0x154/0x160
platform_probe+0x70/0xc0
...
-> #0 (console_owner){-...}-{0:0}:
__lock_acquire+0xdf8/0x109c
lock_acquire+0x234/0x284
console_flush_all+0x330/0x454
console_unlock+0x94/0xf0
vprintk_emit+0x238/0x24c
vprintk_default+0x3c/0x48
vprintk+0xb4/0xbc
_printk+0x68/0x90
dma_entry_alloc+0xb4/0x110
debug_dma_map_sg+0xdc/0x2f8
__dma_map_sg_attrs+0xac/0xe4
dma_map_sgtable+0x30/0x4c
get_pages+0x1d4/0x1e4 [msm]
msm_gem_pin_pages_locked+0x38/0xac [msm]
msm_gem_pin_vma_locked+0x58/0x88 [msm]
msm_ioctl_gem_submit+0xde4/0x13ac [msm]
drm_ioctl_kernel+0xe0/0x15c
drm_ioctl+0x2e8/0x3f4
vfs_ioctl+0x30/0x50
...
Chain exists of:
console_owner --> &port_lock_key --> free_entries_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(free_entries_lock);
lock(&port_lock_key);
lock(free_entries_lock);
lock(console_owner);
*** DEADLOCK ***
Call trace:
dump_backtrace+0xb4/0xf0
show_stack+0x20/0x30
dump_stack_lvl+0x60/0x84
dump_stack+0x18/0x24
print_circular_bug+0x1cc/0x234
check_noncircular+0x78/0xac
__lock_acquire+0xdf8/0x109c
lock_acquire+0x234/0x284
console_flush_all+0x330/0x454
console_unlock+0x94/0xf0
vprintk_emit+0x238/0x24c
vprintk_default+0x3c/0x48
vprintk+0xb4/0xbc
_printk+0x68/0x90
dma_entry_alloc+0xb4/0x110
debug_dma_map_sg+0xdc/0x2f8
__dma_map_sg_attrs+0xac/0xe4
dma_map_sgtable+0x30/0x4c
get_pages+0x1d4/0x1e4 [msm]
msm_gem_pin_pages_locked+0x38/0xac [msm]
msm_gem_pin_vma_locked+0x58/0x88 [msm]
msm_ioctl_gem_submit+0xde4/0x13ac [msm]
drm_ioctl_kernel+0xe0/0x15c
drm_ioctl+0x2e8/0x3f4
vfs_ioctl+0x30/0x50
...
Reported-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: sanglipeng <sanglipeng1@jd.com>
Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
|
|
stable inclusion
from stable-v5.10.210
commit 69e905beca193125820c201ab3db4fb0e245124e
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I96GO9
CVE: CVE-2023-52595
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=69e905beca19
--------------------------------
[ Upstream commit a11d965a218f0cd95b13fe44d0bcd8a20ce134a8 ]
When a hardware reset is triggered, all registers are reset, so all
queues are forced to stop in hardware interface. However, mac80211
will not automatically stop the queue. If we don't manually stop the
beacon queue, the queue will be deadlocked and unable to start again.
This patch fixes the issue where Apple devices cannot connect to the
AP after calling ieee80211_restart_hw().
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/TYAP286MB031530EB6D98DCE4DF20766CBCA4A@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
|
|
mainline inclusion
from mainline-v6.6-rc3
commit d527f51331cace562393a8038d870b3e9916686f
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I95AUA
CVE: CVE-2023-52572
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d527f51331cace562393a8038d870b3e9916686f
--------------------------------
There is a UAF when xfstests on cifs:
BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160
Read of size 4 at addr ffff88810103fc08 by task cifsd/923
CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45
...
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
print_report+0x171/0x472
kasan_report+0xad/0x130
kasan_check_range+0x145/0x1a0
smb2_is_network_name_deleted+0x27/0x160
cifs_demultiplex_thread.cold+0x172/0x5a4
kthread+0x165/0x1a0
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 923:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_slab_alloc+0x54/0x60
kmem_cache_alloc+0x147/0x320
mempool_alloc+0xe1/0x260
cifs_small_buf_get+0x24/0x60
allocate_buffers+0xa1/0x1c0
cifs_demultiplex_thread+0x199/0x10d0
kthread+0x165/0x1a0
ret_from_fork+0x1f/0x30
Freed by task 921:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x40
____kasan_slab_free+0x143/0x1b0
kmem_cache_free+0xe3/0x4d0
cifs_small_buf_release+0x29/0x90
SMB2_negotiate+0x8b7/0x1c60
smb2_negotiate+0x51/0x70
cifs_negotiate_protocol+0xf0/0x160
cifs_get_smb_ses+0x5fa/0x13c0
mount_get_conns+0x7a/0x750
cifs_mount+0x103/0xd00
cifs_smb3_do_mount+0x1dd/0xcb0
smb3_get_tree+0x1d5/0x300
vfs_get_tree+0x41/0xf0
path_mount+0x9b3/0xdd0
__x64_sys_mount+0x190/0x1d0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The UAF is because:
mount(pid: 921) | cifsd(pid: 923)
-------------------------------|-------------------------------
| cifs_demultiplex_thread
SMB2_negotiate |
cifs_send_recv |
compound_send_recv |
smb_send_rqst |
wait_for_response |
wait_event_state [1] |
| standard_receive3
| cifs_handle_standard
| handle_mid
| mid->resp_buf = buf; [2]
| dequeue_mid [3]
KILL the process [4] |
resp_iov[i].iov_base = buf |
free_rsp_buf [5] |
| is_network_name_deleted [6]
| callback
1. After send request to server, wait the response until
mid->mid_state != SUBMITTED;
2. Receive response from server, and set it to mid;
3. Set the mid state to RECEIVED;
4. Kill the process, the mid state already RECEIVED, get 0;
5. Handle and release the negotiate response;
6. UAF.
It can be easily reproduce with add some delay in [3] - [6].
Only sync call has the problem since async call's callback is
executed in cifsd process.
Add an extra state to mark the mid state to READY before wakeup the
waitter, then it can get the resp safely.
Fixes: ec637e3ffb6b ("[CIFS] Avoid extra large buffer allocation (and memcpy) in cifs_readpages")
Reviewed-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Conflicts:
fs/cifs/transport.c
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5973
PR sync from: Lu Jialin <lujialin4@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/KZJBWOZOXFETEM2SKCXMEHHYYC3PR6ID/
https://gitee.com/src-openeuler/kernel/issues/I93EBW
Link:https://gitee.com/openeuler/kernel/pulls/6079
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.8
commit 961ebd120565cb60cebe21cb634fbc456022db4a
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2O3
CVE: CVE-2024-26764
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=961ebd120565cb60cebe21cb634fbc456022db4a
--------------------------------
The first kiocb_set_cancel_fn() argument may point at a struct kiocb
that is not embedded inside struct aio_kiocb. With the current code,
depending on the compiler, the req->ki_ctx read happens either before
the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such
that it is guaranteed that the IOCB_AIO_RW test happens first.
Reported-by: Eric Biggers <ebiggers@kernel.org>
Cc: Benjamin LaHaise <ben@communityfibre.ca>
Cc: Eric Biggers <ebiggers@google.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Avi Kivity <avi@scylladb.com>
Cc: Sandeep Dhavale <dhavale@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: stable@vger.kernel.org
Fixes: b820de741ae4 ("fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240304235715.3790858-1-bvanassche@acm.org
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
stable inclusion
from stable-v5.10.211
commit ea1cd64d59f22d6d13f367d62ec6e27b9344695f
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2O3
CVE: CVE-2024-26764
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ea1cd64d59f22d6d13f367d62ec6e27b9344695f
--------------------------------
commit b820de741ae48ccf50dd95e297889c286ff4f760 upstream.
If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
following kernel warning appears:
WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
Call trace:
kiocb_set_cancel_fn+0x9c/0xa8
ffs_epfile_read_iter+0x144/0x1d0
io_read+0x19c/0x498
io_issue_sqe+0x118/0x27c
io_submit_sqes+0x25c/0x5fc
__arm64_sys_io_uring_enter+0x104/0xab0
invoke_syscall+0x58/0x11c
el0_svc_common+0xb4/0xf4
do_el0_svc+0x2c/0xb0
el0_svc+0x2c/0xa4
el0t_64_sync_handler+0x68/0xb4
el0t_64_sync+0x1a4/0x1a8
Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
submitted by libaio.
Suggested-by: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Avi Kivity <avi@scylladb.com>
Cc: Sandeep Dhavale <dhavale@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: stable@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240215204739.2677806-2-bvanassche@acm.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5995
PR sync from: Jinjiang Tu <tujinjiang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OOA6SREAEMWJD733ZA2BL6Z6ZCZRJWXH/
https://gitee.com/src-openeuler/kernel/issues/I9E2M2
Link:https://gitee.com/openeuler/kernel/pulls/6044
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5970
PR sync from: Yuntao Liu <liuyuntao12@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/VSXSERQ775PX4KMUVEYPECEAXKOY4USC/
fixup CVE-2024-26751
Nikita Shubin (1):
ARM: ep93xx: Add terminator to gpiod_lookup_table
--
2.34.1
https://gitee.com/src-openeuler/kernel/issues/I9E2O0
Link:https://gitee.com/openeuler/kernel/pulls/6024
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5969
PR sync from: Cai Xinchen <caixinchen1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/WWRG5CSX4IEMDHMPPQDDWBHXTWZHHD4M/
https://gitee.com/src-openeuler/kernel/issues/I9E2Y8
Link:https://gitee.com/openeuler/kernel/pulls/6036
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.209
commit 6aa7865ba7ff7f0ede0035180fb3b9400ceb405a
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EBW
CVE: CVE-2023-52464
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6aa7865ba7ff7f0ede0035180fb3b9400ceb405a
--------------------------------
[ Upstream commit 475c58e1a471e9b873e3e39958c64a2d278275c8 ]
Enabling -Wstringop-overflow globally exposes a warning for a common bug
in the usage of strncat():
drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]
1136 | strncat(msg, other, OCX_MESSAGE_SIZE);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
1145 | strncat(msg, other, OCX_MESSAGE_SIZE);
...
1150 | strncat(msg, other, OCX_MESSAGE_SIZE);
...
Apparently the author of this driver expected strncat() to behave the
way that strlcat() does, which uses the size of the destination buffer
as its third argument rather than the length of the source buffer. The
result is that there is no check on the size of the allocated buffer.
Change it to strlcat().
[ bp: Trim compiler output, fixup commit message. ]
Fixes: 41003396f932 ("EDAC, thunderx: Add Cavium ThunderX EDAC driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20231122222007.3199885-1-arnd@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lu Jialin <lujialin4@huawei.com>
(cherry picked from commit 85727f3d56d4498ffaa07ab81498a751d48d4993)
|
|
ext4_mb_find_by_goal()
Merge Pull Request from: @ci-robot
PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/FVTTRI4LAWG6LGKIZDMKTZDLKMF5TLWD/
https://gitee.com/src-openeuler/kernel/issues/I9E2MF
Link:https://gitee.com/openeuler/kernel/pulls/5850
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: Baokun Li <libaokun1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/ZNUV6S3AMEWEDG6R2PILEA4PJLQCMYI7/
Edward Adam Davis (1):
fs/ntfs3: Fix oob in ntfs_listxattr
Zeng Heng (2):
ntfs: Fix panic about slab-out-of-bounds caused by ntfs_listxattr()
fs/ntfs3: fix panic about slab-out-of-bounds caused by ntfs_list_ea()
--
2.31.1
https://gitee.com/src-openeuler/kernel/issues/I9E2O5
Link:https://gitee.com/openeuler/kernel/pulls/6060
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.8-rc4
commit 731ab1f9828800df871c5a7ab9ffe965317d3f15
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2O5
CVE: CVE-2023-52640
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=731ab1f9828800df871c5a7ab9ffe965317d3f15
--------------------------------
The length of name cannot exceed the space occupied by ea.
Reported-and-tested-by: syzbot+65e940cfb8f99a97aca7@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
|
|
mainline inclusion
from mainline-v6.6-rc7
commit 8e7e27b2ee1e19c4040d4987e345f678a74c0aed
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2O5
CVE: CVE-2023-52640
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8e7e27b2ee1e19c4040d4987e345f678a74c0aed
--------------------------------
Here is a BUG report about linux-6.1 from syzbot, but it still remains
within upstream:
BUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]
BUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710
Read of size 1 at addr ffff888021acaf3d by task syz-executor128/3632
Call Trace:
kasan_report+0x139/0x170 mm/kasan/report.c:495
ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]
ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710
vfs_listxattr fs/xattr.c:457 [inline]
listxattr+0x293/0x2d0 fs/xattr.c:804
path_listxattr fs/xattr.c:828 [inline]
__do_sys_llistxattr fs/xattr.c:846 [inline]
Before derefering field members of `ea` in unpacked_ea_size(), we need to
check whether the EA_FULL struct is located in access validate range.
Similarly, when derefering `ea->name` field member, we need to check
whethe the ea->name is located in access validate range, too.
Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations")
Reported-by: syzbot+9fcea5ef6dc4dc72d334@syzkaller.appspotmail.com
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
[almaz.alexandrovich@paragon-software.com: took the ret variable out of the loop block]
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
|
|
mainline inclusion
from mainline-v6.5-rc1
commit 3c675ddffb17a8b1e32efad5c983254af18b12c2
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2O5
CVE: CVE-2023-52640
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c675ddffb17a8b1e32efad5c983254af18b12c2
--------------------------------
Here is a BUG report from syzbot:
BUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]
BUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710
Read of size 1 at addr ffff888021acaf3d by task syz-executor128/3632
Call Trace:
ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]
ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710
vfs_listxattr fs/xattr.c:457 [inline]
listxattr+0x293/0x2d0 fs/xattr.c:804
Fix the logic of ea_all iteration. When the ea->name_len is 0,
return immediately, or Add2Ptr() would visit invalid memory
in the next loop.
Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations")
Reported-by: syzbot+9fcea5ef6dc4dc72d334@syzkaller.appspotmail.com
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
[almaz.alexandrovich@paragon-software.com: lines of the patch have changed]
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
|
|
mainline inclusion
from mainline-v6.9-rc1
commit 22207fd5c80177b860279653d017474b2812af5e
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9DO1Z
CVE: CVE-2024-26656
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=22207fd5c80177b860279653d017474b2812af5e
--------------------------------
The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl
to the AMDGPU DRM driver on any ASICs with an invalid address and size.
The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>.
For example the following code:
static void Syzkaller1(int fd)
{
struct drm_amdgpu_gem_userptr arg;
int ret;
arg.addr = 0xffffffffffff0000;
arg.size = 0x80000000; /*2 Gb*/
arg.flags = 0x7;
ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg);
}
Due to the address and size are not valid there is a failure in
amdgpu_mn_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert->
check_shl_overflow, but we even the amdgpu_mn_register failure we still call
amdgpu_mn_unregister into amdgpu_gem_object_free which causes access to a bad address.
The following stack is below when the issue is reproduced when Kazan is enabled:
[ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340
[ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80
[ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246
[ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b
[ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260
[ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25
[ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00
[ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260
[ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000
[ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0
[ +0.000010] Call Trace:
[ +0.000006] <TASK>
[ +0.000007] ? show_regs+0x6a/0x80
[ +0.000018] ? __warn+0xa5/0x1b0
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
[ +0.000018] ? report_bug+0x24a/0x290
[ +0.000022] ? handle_bug+0x46/0x90
[ +0.000015] ? exc_invalid_op+0x19/0x50
[ +0.000016] ? asm_exc_invalid_op+0x1b/0x20
[ +0.000017] ? kasan_save_stack+0x26/0x50
[ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340
[ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340
[ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340
[ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10
[ +0.000017] ? kasan_save_alloc_info+0x1e/0x30
[ +0.000018] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? __kasan_kmalloc+0xb1/0xc0
[ +0.000018] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_read+0x11/0x20
[ +0.000020] amdgpu_mn_unregister+0x34/0x50 [amdgpu]
[ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu]
[ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]
[ +0.004291] ? do_syscall_64+0x5f/0xe0
[ +0.000023] ? srso_return_thunk+0x5/0x5f
[ +0.000017] drm_gem_object_free+0x3b/0x50 [drm]
[ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]
[ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004270] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? __this_cpu_preempt_check+0x13/0x20
[ +0.000015] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0
[ +0.000020] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm]
[ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm]
[ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm]
[ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm]
[ +0.000489] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? __kasan_check_write+0x14/0x20
[ +0.000016] drm_ioctl+0x3da/0x730 [drm]
[ +0.000475] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[ +0.004293] ? __pfx_drm_ioctl+0x10/0x10 [drm]
[ +0.000506] ? __pfx_rpm_resume+0x10/0x10
[ +0.000016] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? __kasan_check_write+0x14/0x20
[ +0.000010] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? _raw_spin_lock_irqsave+0x99/0x100
[ +0.000015] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ +0.000014] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? srso_return_thunk+0x5/0x5f
[ +0.000011] ? preempt_count_sub+0x18/0xc0
[ +0.000013] ? srso_return_thunk+0x5/0x5f
[ +0.000010] ? _raw_spin_unlock_irqrestore+0x27/0x50
[ +0.000019] amdgpu_drm_ioctl+0x7e/0xe0 [amdgpu]
[ +0.004272] __x64_sys_ioctl+0xcd/0x110
[ +0.000020] do_syscall_64+0x5f/0xe0
[ +0.000021] entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ +0.000015] RIP: 0033:0x7ff9ed31a94f
[ +0.000012] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
[ +0.000013] RSP: 002b:00007fff25f66790 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ +0.000016] RAX: ffffffffffffffda RBX: 000055b3f7e133e0 RCX: 00007ff9ed31a94f
[ +0.000012] RDX: 000055b3f7e133e0 RSI: 00000000c1186451 RDI: 0000000000000003
[ +0.000010] RBP: 00000000c1186451 R08: 0000000000000000 R09: 0000000000000000
[ +0.000009] R10: 0000000000000008 R11: 0000000000000246 R12: 00007fff25f66ca8
[ +0.000009] R13: 0000000000000003 R14: 000055b3f7021ba8 R15: 00007ff9ed7af040
[ +0.000024] </TASK>
[ +0.000007] ---[ end trace 0000000000000000 ]---
v2: Consolidate any error handling into amdgpu_mn_register
which applied to kfd_bo also. (Christian)
v3: Improve syntax and comment (Christian)
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Felix Kuehling <felix.kuehling@amd.com>
Cc: Joonkyo Jung <joonkyoj@yonsei.ac.kr>
Cc: Dokyung Song <dokyungs@yonsei.ac.kr>
Cc: <jisoo.jang@yonsei.ac.kr>
Cc: <yw9865@yonsei.ac.kr>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 57e12e6f5f79e1e9b0cf59b19d0f0f157dbce054)
|
|
mainline inclusion
from mainline-v6.8-rc6
commit 13ddaf26be324a7f951891ecd9ccd04466d27458
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2M2
CVE: CVE-2024-26759
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13ddaf26be324a7f951891ecd9ccd04466d27458
-------------------------------------------
When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads
swapin the same entry at the same time, they get different pages (A, B).
Before one thread (T0) finishes the swapin and installs page (A) to the
PTE, another thread (T1) could finish swapin of page (B), swap_free the
entry, then swap out the possibly modified page reusing the same entry.
It breaks the pte_same check in (T0) because PTE value is unchanged,
causing ABA problem. Thread (T0) will install a stalled page (A) into the
PTE and cause data corruption.
One possible callstack is like this:
CPU0 CPU1
---- ----
do_swap_page() do_swap_page() with same entry
<direct swapin path> <direct swapin path>
<alloc page A> <alloc page B>
swap_read_folio() <- read to page A swap_read_folio() <- read to page B
<slow on later locks or interrupt> <finished swapin first>
... set_pte_at()
swap_free() <- entry is free
<write to page B, now page A stalled>
<swap out page B to same swap entry>
pte_same() <- Check pass, PTE seems
unchanged, but page A
is stalled!
swap_free() <- page B content lost!
set_pte_at() <- staled page A installed!
And besides, for ZRAM, swap_free() allows the swap device to discard the
entry content, so even if page (B) is not modified, if swap_read_folio()
on CPU0 happens later than swap_free() on CPU1, it may also cause data
loss.
To fix this, reuse swapcache_prepare which will pin the swap entry using
the cache flag, and allow only one thread to swap it in, also prevent any
parallel code from putting the entry in the cache. Release the pin after
PT unlocked.
Racers just loop and wait since it's a rare and very short event. A
schedule_timeout_uninterruptible(1) call is added to avoid repeated page
faults wasting too much CPU, causing livelock or adding too much noise to
perf statistics. A similar livelock issue was described in commit
029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead")
Reproducer:
This race issue can be triggered easily using a well constructed
reproducer and patched brd (with a delay in read path) [1]:
With latest 6.8 mainline, race caused data loss can be observed easily:
$ gcc -g -lpthread test-thread-swap-race.c && ./a.out
Polulating 32MB of memory region...
Keep swapping out...
Starting round 0...
Spawning 65536 workers...
32746 workers spawned, wait for done...
Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss!
Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss!
Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss!
Round 0 Failed, 15 data loss!
This reproducer spawns multiple threads sharing the same memory region
using a small swap device. Every two threads updates mapped pages one by
one in opposite direction trying to create a race, with one dedicated
thread keep swapping out the data out using madvise.
The reproducer created a reproduce rate of about once every 5 minutes, so
the race should be totally possible in production.
After this patch, I ran the reproducer for over a few hundred rounds and
no data loss observed.
Performance overhead is minimal, microbenchmark swapin 10G from 32G
zram:
Before: 10934698 us
After: 11157121 us
Cached: 13155355 us (Dropping SWP_SYNCHRONOUS_IO flag)
[kasong@tencent.com: v4]
Link: https://lkml.kernel.org/r/20240219082040.7495-1-ryncsn@gmail.com
Link: https://lkml.kernel.org/r/20240206182559.32264-1-ryncsn@gmail.com
Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device")
Reported-by: "Huang, Ying" <ying.huang@intel.com>
Closes: https://lore.kernel.org/lkml/87bk92gqpx.fsf_-_@yhuang6-desk2.ccr.corp.intel.com/
Link: https://github.com/ryncsn/emm-test-project/tree/master/swap-stress-race [1]
Signed-off-by: Kairui Song <kasong@tencent.com>
Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Chris Li <chrisl@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Yosry Ahmed <yosryahmed@google.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Barry Song <21cnbao@gmail.com>
Cc: SeongJae Park <sj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Conflicts:
mm/memory.c
include/linux/swap.h
Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
(cherry picked from commit 75acda4d647010e8488696ddb4ef84b5689bb2ae)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5901
PR sync from: Chen Ridong <chenridong@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/4FEBL5NK5XIY3AYTHSQ3ASU6RADGEIVF/
*** BLURB HERE ***
Kim Phillips (1):
crypto: ccp - Fix null pointer dereference in
__sev_platform_shutdown_locked
--
2.34.1
https://gitee.com/src-openeuler/kernel/issues/I9E2FM
Link:https://gitee.com/openeuler/kernel/pulls/5989
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5812
PR sync from: Zhihao Cheng <chengzhihao1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/MK34IJMGUWICBHTOAHHVUP3DC4UL7IBA/
https://gitee.com/src-openeuler/kernel/issues/I9E3E9
Link:https://gitee.com/openeuler/kernel/pulls/5982
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.211
commit 512ee6d6041e007ef5bf200c6e388e172a2c5b24
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2Y8
CVE: CVE-2024-26778
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=512ee6d6041e007ef5bf200c6e388e172a2c5b24
--------------------------------
[ Upstream commit 04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288 ]
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.
Although pixclock is checked in savagefb_decode_var(), but it is not
checked properly in savagefb_probe(). Fix this by checking whether
pixclock is zero in the function savagefb_check_var() before
info->var.pixclock is used as the divisor.
This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8.
Signed-off-by: Fullway Wang <fullwaywang@outlook.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
(cherry picked from commit 89aa105a852059bf16b384c7be90415adbe3c1a6)
|
|
stable inclusion
from stable-v5.10.211
commit 70d92abbe29692a3de8697ae082c60f2d21ab482
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2O0
CVE: CVE-2024-26751
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=70d92abbe29692a3de8697ae082c60f2d21ab482
--------------------------------
Without the terminator, if a con_id is passed to gpio_find() that
does not exist in the lookup table the function will not stop looping
correctly, and eventually cause an oops.
Cc: stable@vger.kernel.org
Fixes: b2e63555592f ("i2c: gpio: Convert to use descriptors")
Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20240205102337.439002-1-alexander.sverdlin@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Yuntao Liu <liuyuntao12@huawei.com>
(cherry picked from commit f2019796562a154044728afe0c80a71713fd55ec)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5831
PR sync from: Jinjiang Tu <tujinjiang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/TUN4KAULJV5TNF7ORD3PQ3IFJXLXQ26S/
https://gitee.com/src-openeuler/kernel/issues/I9E2MG
Link:https://gitee.com/openeuler/kernel/pulls/5949
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5884
PR sync from: Jinjie Ruan <ruanjinjie@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OSEBM74ACF43YCV7LCPJPP4WPSTU2ZB3/
https://gitee.com/openeuler/kernel/issues/I9F351
Link:https://gitee.com/openeuler/kernel/pulls/5960
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5348
PR sync from: Zheng Zucheng <zhengzucheng@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/2VK7OF5YR2E3GU2M6KDDTJEOSSGR3XAY/
https://gitee.com/src-openeuler/kernel/issues/I96G7Q
Link:https://gitee.com/openeuler/kernel/pulls/5844
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
unchecked symbol
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5745
PR sync from: Zhang Zekun <zhangzekun11@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/6MYFSTED4KCZICV6K3NNGDKGHAVXAMFS/
https://gitee.com/openeuler/kernel/issues/I9EEIG
Link:https://gitee.com/openeuler/kernel/pulls/5962
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.8-rc4
commit ccb88e9549e7cfd8bcd511c538f437e20026e983
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2FM
CVE: CVE-2024-26695
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ccb88e9549e7cfd8bcd511c538f437e20026e983
----------------------------------------------------------------------
The SEV platform device can be shutdown with a null psp_master,
e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN:
[ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002)
[ 137.162647] ccp 0000:23:00.1: no command queues available
[ 137.170598] ccp 0000:23:00.1: sev enabled
[ 137.174645] ccp 0000:23:00.1: psp enabled
[ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI
[ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7]
[ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311
[ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180
[ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c
[ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216
[ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e
[ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0
[ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66
[ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28
[ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8
[ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000
[ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0
[ 137.182693] Call Trace:
[ 137.182693] <TASK>
[ 137.182693] ? show_regs+0x6c/0x80
[ 137.182693] ? __die_body+0x24/0x70
[ 137.182693] ? die_addr+0x4b/0x80
[ 137.182693] ? exc_general_protection+0x126/0x230
[ 137.182693] ? asm_exc_general_protection+0x2b/0x30
[ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180
[ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80
[ 137.182693] sev_dev_destroy+0x49/0x100
[ 137.182693] psp_dev_destroy+0x47/0xb0
[ 137.182693] sp_destroy+0xbb/0x240
[ 137.182693] sp_pci_remove+0x45/0x60
[ 137.182693] pci_device_remove+0xaa/0x1d0
[ 137.182693] device_remove+0xc7/0x170
[ 137.182693] really_probe+0x374/0xbe0
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] __driver_probe_device+0x199/0x460
[ 137.182693] driver_probe_device+0x4e/0xd0
[ 137.182693] __driver_attach+0x191/0x3d0
[ 137.182693] ? __pfx___driver_attach+0x10/0x10
[ 137.182693] bus_for_each_dev+0x100/0x190
[ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10
[ 137.182693] ? __kasan_check_read+0x15/0x20
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] ? _raw_spin_unlock+0x27/0x50
[ 137.182693] driver_attach+0x41/0x60
[ 137.182693] bus_add_driver+0x2a8/0x580
[ 137.182693] driver_register+0x141/0x480
[ 137.182693] __pci_register_driver+0x1d6/0x2a0
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0
[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10
[ 137.182693] sp_pci_init+0x22/0x30
[ 137.182693] sp_mod_init+0x14/0x30
[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10
[ 137.182693] do_one_initcall+0xd1/0x470
[ 137.182693] ? __pfx_do_one_initcall+0x10/0x10
[ 137.182693] ? parameq+0x80/0xf0
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] ? __kmalloc+0x3b0/0x4e0
[ 137.182693] ? kernel_init_freeable+0x92d/0x1050
[ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190
[ 137.182693] ? srso_return_thunk+0x5/0x5f
[ 137.182693] kernel_init_freeable+0xa64/0x1050
[ 137.182693] ? __pfx_kernel_init+0x10/0x10
[ 137.182693] kernel_init+0x24/0x160
[ 137.182693] ? __switch_to_asm+0x3e/0x70
[ 137.182693] ret_from_fork+0x40/0x80
[ 137.182693] ? __pfx_kernel_init+0x10/0x10
[ 137.182693] ret_from_fork_asm+0x1b/0x30
[ 137.182693] </TASK>
[ 137.182693] Modules linked in:
[ 137.538483] ---[ end trace 0000000000000000 ]---
Fixes: 1b05ece0c931 ("crypto: ccp - During shutdown, check SEV data pointer before using")
Cc: stable@vger.kernel.org
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Chen Ridong <chenridong@huawei.com>
(cherry picked from commit 1e283b5f8379357750cfbed0cec775de9f27536c)
|
|
Merge Pull Request from: @ci-robot
PR sync from: GUO Zihua <guozihua@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/3OJWJNIE2IBHCIV5NDLVRWMIF2UF3YXQ/
https://gitee.com/src-openeuler/kernel/issues/I9E2MP
Link:https://gitee.com/openeuler/kernel/pulls/5859
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
ainline inclusion
from mainline-v6.8-rc6
commit 6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E3E9
CVE: CVE-2024-26736
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d
--------------------------------
The max length of volume->vid value is 20 characters.
So increase idbuf[] size up to 24 to avoid overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]
Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/r/20240211150442.3416-1-d.dulov@aladdin.ru/ # v1
Link: https://lore.kernel.org/r/20240212083347.10742-1-d.dulov@aladdin.ru/ # v2
Link: https://lore.kernel.org/r/20240219143906.138346-3-dhowells@redhat.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
(cherry picked from commit 9ce3908dd299050b7138fc000f809c4c18099a31)
|
|
Merge Pull Request from: @ci-robot
PR sync from: Liu Mingrui <liumingrui@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/J2Z7VJPGPD2NJJFCP7GFKKMWK25PM6Y6/
CVE-2021-46926
Libin Yang (1):
ALSA: hda: intel-sdw-acpi: harden detection of controller
--
2.25.1
https://gitee.com/src-openeuler/kernel/issues/I947TK
Link:https://gitee.com/openeuler/kernel/pulls/5940
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5861
PR sync from: Long Li <leo.lilong@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/WDGOUOZTAAFCTWDTQDTDPDPK4SHQKQHI/
https://gitee.com/src-openeuler/kernel/issues/I94P2I
Link:https://gitee.com/openeuler/kernel/pulls/5946
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5911
PR sync from: Guo Mengqi <guomengqi3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/TBAWQUCXBET53PA36MQKZ7T3IKCXODG7/
CVE-2023-52484
Nicolin Chen (2):
iommu/arm-smmu-v3: Fix size calculation in
arm_smmu_mm_invalidate_range()
iommu/arm-smmu-v3: Fix soft lockup triggered by
arm_smmu_mm_invalidate_range
--
2.17.1
https://gitee.com/src-openeuler/kernel/issues/I94OZS
Link:https://gitee.com/openeuler/kernel/pulls/5938
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.15.145
commit 5c0df9d30c289d6b9d7d44e2a450de2f8e3cf40b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I92OOJ
CVE: CVE-2023-52441
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5c0df9d30c289d6b9d7d44e2a450de2f8e3cf40b
--------------------------------
[ Upstream commit 536bb492d39bb6c080c92f31e8a55fe9934f452b ]
If client send smb2 negotiate request and then send smb1 negotiate
request, init_smb2_rsp_hdr is called for smb1 negotiate request since
need_neg is set to false. This patch ignore smb1 packets after ->need_neg
is set to false.
Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-21541
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
stable inclusion
from stable-v5.15.145
commit 921536046bd165efeb07beef5630aff35cd6a489
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I92OOJ
CVE: CVE-2023-52441
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=921536046bd165efeb07beef5630aff35cd6a489
--------------------------------
[ Upstream commit dc8289f912387c3bcfbc5d2db29c8947fa207c11 ]
When smb1 mount fails, KASAN detect slab-out-of-bounds in
init_smb2_rsp_hdr like the following one.
For smb1 negotiate(56bytes) , init_smb2_rsp_hdr() for smb2 is called.
The issue occurs while handling smb1 negotiate as smb2 server operations.
Add smb server operations for smb1 (get_cmd_val, init_rsp_hdr,
allocate_rsp_buf, check_user_session) to handle smb1 negotiate so that
smb2 server operation does not handle it.
[ 411.400423] CIFS: VFS: Use of the less secure dialect vers=1.0 is
not recommended unless required for access to very old servers
[ 411.400452] CIFS: Attempting to mount \\192.168.45.139\homes
[ 411.479312] ksmbd: init_smb2_rsp_hdr : 492
[ 411.479323] ==================================================================
[ 411.479327] BUG: KASAN: slab-out-of-bounds in
init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[ 411.479369] Read of size 16 at addr ffff888488ed0734 by task kworker/14:1/199
[ 411.479379] CPU: 14 PID: 199 Comm: kworker/14:1 Tainted: G
OE 6.1.21 #3
[ 411.479386] Hardware name: ASUSTeK COMPUTER INC. Z10PA-D8
Series/Z10PA-D8 Series, BIOS 3801 08/23/2019
[ 411.479390] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]
[ 411.479425] Call Trace:
[ 411.479428] <TASK>
[ 411.479432] dump_stack_lvl+0x49/0x63
[ 411.479444] print_report+0x171/0x4a8
[ 411.479452] ? kasan_complete_mode_report_info+0x3c/0x200
[ 411.479463] ? init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[ 411.479497] kasan_report+0xb4/0x130
[ 411.479503] ? init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[ 411.479537] kasan_check_range+0x149/0x1e0
[ 411.479543] memcpy+0x24/0x70
[ 411.479550] init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[ 411.479585] handle_ksmbd_work+0x109/0x760 [ksmbd]
[ 411.479616] ? _raw_spin_unlock_irqrestore+0x50/0x50
[ 411.479624] ? smb3_encrypt_resp+0x340/0x340 [ksmbd]
[ 411.479656] process_one_work+0x49c/0x790
[ 411.479667] worker_thread+0x2b1/0x6e0
[ 411.479674] ? process_one_work+0x790/0x790
[ 411.479680] kthread+0x177/0x1b0
[ 411.479686] ? kthread_complete_and_exit+0x30/0x30
[ 411.479692] ret_from_fork+0x22/0x30
[ 411.479702] </TASK>
Fixes: 39b291b86b59 ("ksmbd: return unsupported error on smb1 mount")
Cc: stable@vger.kernel.org
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
stable inclusion
from stable-v5.15.105
commit 51a8534c0f35c0401e45f1055f914729cad98bf9
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I92OOJ
CVE: CVE-2023-52441
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=51a8534c0f35c0401e45f1055f914729cad98bf9
--------------------------------
commit 39b291b86b5988bf8753c3874d5c773399d09b96 upstream.
ksmbd disconnect connection when mounting with vers=smb1.
ksmbd should send smb1 negotiate response to client for correct
unsupported error return. This patch add needed SMB1 macros and fill
NegProt part of the response for smb1 negotiate response.
Cc: stable@vger.kernel.org
Reported-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Conflicts:
fs/ksmbd/connection.c
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
stable inclusion
from stable-v5.15.105
commit 496e186bc005fa4a4d9cf14e0662ae00b60e1362
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I92OOJ
CVE: CVE-2023-52441
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=496e186bc005fa4a4d9cf14e0662ae00b60e1362
--------------------------------
commit b53e8cfec30b93c120623232ba27c041b1ef8f1a upstream.
ksmbd returned "Input/output error" when mounting with vers=2.0 to
ksmbd. It should return STATUS_NOT_SUPPORTED on unsupported smb2.0
dialect.
Cc: stable@vger.kernel.org
Reported-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5895
PR sync from: Liao Chen <liaochen4@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/MP5WRJGPAQWUNCND6JWO6SSBEYJMBV5O/
According to the Intel datasheets, software must reset the block
buffer index twice for block process call transactions: once before
writing the outgoing data to the buffer, and once again before
reading the incoming data from the buffer.
The driver is currently missing the second reset, causing the wrong
portion of the block buffer to be read.
Jean Delvare (1):
i2c: i801: Fix block process call transactions
--
2.34.1
https://gitee.com/src-openeuler/kernel/issues/I93ELY
Link:https://gitee.com/openeuler/kernel/pulls/5934
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I9EEIG
--------------------------------------
This commit fix the following errors in the code:
1. The arm_smmu_aux_attach_dev function returns an uncertain return value
ret when all conditions are not met. In this case, the cd table is not
initialized. Therefore, a new default exception value is added.
2. In arm_smmu_ecmdq_probe(), the parameter pre_addr is used in the loop
but it is not initialed yet. Also, the parameter "ecmdq" is used before
check if it is NULL.
Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com>
(cherry picked from commit e2f50ac39b3df52562f639d0dce54d722dfc9300)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5863
PR sync from: Hongbo Li <lihongbo22@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/FAGLWUHLH6EJ4YJQRA5BLMMMINXHTPMT/
fix CVE-2024-26788
Curtis Klein (1):
[Backport] dmaengine: fsl-qdma: init irq after reg initialization
--
2.34.1
https://gitee.com/src-openeuler/kernel/issues/I9E46I
Link:https://gitee.com/openeuler/kernel/pulls/5929
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/4928
PR sync from: Ye Bin <yebin10@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/WOFZWIXJMMALUENIM5ZENWYPKWWXTQSY/
https://gitee.com/src-openeuler/kernel/issues/I94UOT
Link:https://gitee.com/openeuler/kernel/pulls/5910
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
ext4_mb_try_best_found()
Merge Pull Request from: @ci-robot
PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/3Y5SHBNDHHHDZZLO46IZAGEYB32I3I3I/
https://gitee.com/src-openeuler/kernel/issues/I9E2M9
Link:https://gitee.com/openeuler/kernel/pulls/5783
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I9F351
CVE: CVE-2024-26598
--------------------------------------
The commit d1e388dbca87 ("KVM: arm64: vgic-its: Avoid potential UAF in LPI
translation cache") fix CVE-2024-26598 erroneously, correct it.
Fixes: d1e388dbca87 ("KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
(cherry picked from commit 66069c0eb0f8f4d566a31d2b54933542de0ce015)
|
|
kv_parse_power_table
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5870
PR sync from: Hui Tang <tanghui20@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HOQ7FL5UUYEH76ZG6HRS2YJU6NQ3Z7F2/
https://gitee.com/src-openeuler/kernel/issues/I93L72
Link:https://gitee.com/openeuler/kernel/pulls/5917
Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
for SRP
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/4931
PR sync from: Dong Chenchen <dongchenchen2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JXNI5VT3RT75BCKAL4RBHJD4OQPZS3Z3/
https://gitee.com/src-openeuler/kernel/issues/I93HCX
Link:https://gitee.com/openeuler/kernel/pulls/5902
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.211
commit cd36da760bd1f78c63c7078407baf01dd724f313
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2MG
CVE: CVE-2024-26777
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cd36da760bd1f78c63c7078407baf01dd724f313
--------------------------------
[ Upstream commit e421946be7d9bf545147bea8419ef8239cb7ca52 ]
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.
In sisfb_check_var(), var->pixclock is used as a divisor to caculate
drate before it is checked against zero. Fix this by checking it
at the beginning.
This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8.
Signed-off-by: Fullway Wang <fullwaywang@outlook.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
(cherry picked from commit 9c77371e58fd193eec409bda64a28b5c25e98570)
|
|
stable inclusion
from stable-v5.15.81
commit 694e13732e830cbbfedb562e57f28644927c33fd
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94P2I
CVE: CVE-2023-52479
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y&id=694e13732e830cbbfedb562e57f28644927c33fd
--------------------------------
commit c69813471a1ec081a0b9bf0c6bd7e8afd818afce upstream.
drop reference after use opinfo.
Signed-off-by: luosili <rootlab@huawei.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Long Li <leo.lilong@huawei.com>
(cherry picked from commit 2955d95752d943d56c5363dce457a272087ee0af)
|
|
mainline inclusion
from mainline-v5.16-rc7
commit 385f287f9853da402d94278e59f594501c1d1dad
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I947TK
CVE: CVE-2021-46926
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=385f287f9853da402d94278e59f594501c1d1dad
--------------------------------
The existing code currently sets a pointer to an ACPI handle before
checking that it's actually a SoundWire controller. This can lead to
issues where the graph walk continues and eventually fails, but the
pointer was set already.
This patch changes the logic so that the information provided to
the caller is set when a controller is found.
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20211221010817.23636-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Conflicts:
sound/hda/intel-sdw-acpi.c
Signed-off-by: Liu Mingrui <liumingrui@huawei.com>
|
|
stable inclusion
from stable-v5.15.134
commit f5a604757aa8e37ea9c7011dc9da54fa1b30f29b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94OZS
CVE: CVE-2023-52484
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f5a604757aa8e37ea9c7011dc9da54fa1b30f29b
--------------------------------
commit d5afb4b47e13161b3f33904d45110f9e6463bad6 upstream.
When running an SVA case, the following soft lockup is triggered:
--------------------------------------------------------------------
watchdog: BUG: soft lockup - CPU#244 stuck for 26s!
pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50
sp : ffff8000d83ef290
x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000
x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000
x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0
x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0
x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a
x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001
Call trace:
arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
__arm_smmu_tlb_inv_range+0x118/0x254
arm_smmu_tlb_inv_range_asid+0x6c/0x130
arm_smmu_mm_invalidate_range+0xa0/0xa4
__mmu_notifier_invalidate_range_end+0x88/0x120
unmap_vmas+0x194/0x1e0
unmap_region+0xb4/0x144
do_mas_align_munmap+0x290/0x490
do_mas_munmap+0xbc/0x124
__vm_munmap+0xa8/0x19c
__arm64_sys_munmap+0x28/0x50
invoke_syscall+0x78/0x11c
el0_svc_common.constprop.0+0x58/0x1c0
do_el0_svc+0x34/0x60
el0_svc+0x2c/0xd4
el0t_64_sync_handler+0x114/0x140
el0t_64_sync+0x1a4/0x1a8
--------------------------------------------------------------------
The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable
protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur
to SMMU too since arm_smmu_mm_invalidate_range() is typically called next
to MMU tlb flush function, e.g.
tlb_flush_mmu_tlbonly {
tlb_flush {
__flush_tlb_range {
// check MAX_TLBI_OPS
}
}
mmu_notifier_invalidate_range {
arm_smmu_mm_invalidate_range {
// does not check MAX_TLBI_OPS
}
}
}
Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an
SVA case SMMU uses the CPU page table, so it makes sense to align with the
tlbflush code. Then, replace per-page TLBI commands with a single per-asid
TLBI command, if the request size hits this threshold.
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Link: https://lore.kernel.org/r/20230920052257.8615-1-nicolinc@nvidia.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
conflicts:
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
Signed-off-by: Guo Mengqi <guomengqi3@huawei.com>
(cherry picked from commit 860efaa2a1971f9166e06834a9666c91d5d3396b)
|
|
stable inclusion
from stable-v5.15.39
commit 2c14dda7a4dfecbda191351da29e4756b7377ee7
bugzilla: 189652
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2c14dda7a4dfecbda191351da29e4756b7377ee7
--------------------------------
commit 95d4782c34a60800ccf91d9f0703137d4367a2fc upstream.
The arm_smmu_mm_invalidate_range function is designed to be called
by mm core for Shared Virtual Addressing purpose between IOMMU and
CPU MMU. However, the ways of two subsystems defining their "end"
addresses are slightly different. IOMMU defines its "end" address
using the last address of an address range, while mm core defines
that using the following address of an address range:
include/linux/mm_types.h:
unsigned long vm_end;
/* The first byte after our end address ...
This mismatch resulted in an incorrect calculation for size so it
failed to be page-size aligned. Further, it caused a dead loop at
"while (iova < end)" check in __arm_smmu_tlb_inv_range function.
This patch fixes the issue by doing the calculation correctly.
Fixes: 2f7e8c553e98 ("iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops")
Cc: stable@vger.kernel.org
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20220419210158.21320-1-nicolinc@nvidia.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Guo Mengqi <guomengqi3@huawei.com>
(cherry picked from commit d26891f944aa591cdde15dc452dde4053425af40)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5811
PR sync from: Zheng Zengkai <zhengzengkai@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/XEY7VEQF7K7POCPZJKQOUYBVHUVEDZBE/
Backport following patches to fix CVE-2021-47037.
Reference: https://nvd.nist.gov/vuln/detail/CVE-2021-47037
Dmitry Baryshkov (1):
[Backport] ASoC: q6afe-clocks: fix reprobing of the driver
Srinivas Kandagatla (1):
[Backport] ASoC: q6afe-clocks: fix warning on symbol scope
--
2.20.1
https://gitee.com/src-openeuler/kernel/issues/I94K5J
Link:https://gitee.com/openeuler/kernel/pulls/5914
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/4794
PR sync from: felix <fuzhen5@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/GSOELNXX7EAKIWBCNWFS7IXZSOLORM77/
https://gitee.com/src-openeuler/kernel/issues/I93EEE
Link:https://gitee.com/openeuler/kernel/pulls/5873
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
powermate_config_complete
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/4865
PR sync from: Xiang Yang <xiangyang3@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HD3URJV2W6XWNHMJDV72JFZBD3SXDN7K/
https://gitee.com/src-openeuler/kernel/issues/I94PA7
Link:https://gitee.com/openeuler/kernel/pulls/4910
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.210
commit 7a14b8a477b88607d157c24aeb23e7389ec3319f
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93ELY
CVE: CVE-2024-26593
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d074d5ff5ae77b18300e5079c6bda6342a4d44b7
--------------------------------
[ Upstream commit c1c9d0f6f7f1dbf29db996bd8e166242843a5f21 ]
According to the Intel datasheets, software must reset the block
buffer index twice for block process call transactions: once before
writing the outgoing data to the buffer, and once again before
reading the incoming data from the buffer.
The driver is currently missing the second reset, causing the wrong
portion of the block buffer to be read.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reported-by: Piotr Zakowski <piotr.zakowski@intel.com>
Closes: https://lore.kernel.org/linux-i2c/20240213120553.7b0ab120@endymion.delvare/
Fixes: 315cd67c9453 ("i2c: i801: Add Block Write-Block Read Process Call support")
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Liao Chen <liaochen4@huawei.com>
(cherry picked from commit e3d5786751ba7b32a9fcfa80a80a4bbe2f6a447a)
|
|
stable inclusion
from stable-v5.10.212
commit 9579a21e99fe8dab22a253050ddff28d340d74e1
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E46I
CVE: CVE-2024-26788
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9579a21e99fe8dab22a253050ddff28d340d74e1
--------------------------------
commit 87a39071e0b639f45e05d296cc0538eef44ec0bd upstream.
Initialize the qDMA irqs after the registers are configured so that
interrupts that may have been pending from a primary kernel don't get
processed by the irq handler before it is ready to and cause panic with
the following trace:
Call trace:
fsl_qdma_queue_handler+0xf8/0x3e8
__handle_irq_event_percpu+0x78/0x2b0
handle_irq_event_percpu+0x1c/0x68
handle_irq_event+0x44/0x78
handle_fasteoi_irq+0xc8/0x178
generic_handle_irq+0x24/0x38
__handle_domain_irq+0x90/0x100
gic_handle_irq+0x5c/0xb8
el1_irq+0xb8/0x180
_raw_spin_unlock_irqrestore+0x14/0x40
__setup_irq+0x4bc/0x798
request_threaded_irq+0xd8/0x190
devm_request_threaded_irq+0x74/0xe8
fsl_qdma_probe+0x4d4/0xca8
platform_drv_probe+0x50/0xa0
really_probe+0xe0/0x3f8
driver_probe_device+0x64/0x130
device_driver_attach+0x6c/0x78
__driver_attach+0xbc/0x158
bus_for_each_dev+0x5c/0x98
driver_attach+0x20/0x28
bus_add_driver+0x158/0x220
driver_register+0x60/0x110
__platform_driver_register+0x44/0x50
fsl_qdma_driver_init+0x18/0x20
do_one_initcall+0x48/0x258
kernel_init_freeable+0x1a4/0x23c
kernel_init+0x10/0xf8
ret_from_fork+0x10/0x18
Cc: stable@vger.kernel.org
Fixes: b092529e0aa0 ("dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs")
Signed-off-by: Curtis Klein <curtis.klein@hpe.com>
Signed-off-by: Yi Zhao <yi.zhao@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20240201220406.440145-1-Frank.Li@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
(cherry picked from commit 17b23ea612fc86d4a46018fea69df02380a27a54)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5808
PR sync from: Yifan Qiao <qiaoyifan4@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/BUMPSHILH2XDBHH3PCL5E3NHMTL5CGLE/
https://gitee.com/src-openeuler/kernel/issues/I9E2EQ
Link:https://gitee.com/openeuler/kernel/pulls/5898
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5832
PR sync from: Chen Ridong <chenridong@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/UITGCIO5IAKMSP3ALGP7S6Z7WLSBGDY4/
*** BLURB HERE ***
Kunwu Chan (1):
mfd: syscon: Fix null pointer dereference in of_syscon_register()
--
2.34.1
https://gitee.com/src-openeuler/kernel/issues/I93L7E
Link:https://gitee.com/openeuler/kernel/pulls/5890
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.209
commit 520e213a0b97b64735a13950e9371e0a5d7a5dc3
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93L72
CVE: CVE-2023-52469
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=520e213a0b97b64735a13950e9371e0a5d7a5dc3
--------------------------------
[ Upstream commit 28dd788382c43b330480f57cd34cde0840896743 ]
When ps allocated by kzalloc equals to NULL, kv_parse_power_table
frees adev->pm.dpm.ps that allocated before. However, after the control
flow goes through the following call chains:
kv_parse_power_table
|-> kv_dpm_init
|-> kv_dpm_sw_init
|-> kv_dpm_fini
The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its
first free in kv_parse_power_table and causes a use-after-free bug.
Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts")
Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Hui Tang <tanghui20@huawei.com>
(cherry picked from commit 9646a08e991f06c56208c1b643d6b653b3969c21)
|
|
mainline inclusion
from mainline-v5.13-rc1
commit 96fadf7e8ff49fdb74754801228942b67c3eeebd
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94K5J
CVE: CVE-2021-47037
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96fadf7e8ff49fdb74754801228942b67c3eeebd
------------------------------------------------------
Q6afe-clocks driver can get reprobed. For example if the APR services
are restarted after the firmware crash. However currently Q6afe-clocks
driver will oops because hw.init will get cleared during first _probe
call. Rewrite the driver to fill the clock data at runtime rather than
using big static array of clocks.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Fixes: 520a1c396d19 ("ASoC: q6afe-clocks: add q6afe clock controller")
Link: https://lore.kernel.org/r/20210327092857.3073879-1-dmitry.baryshkov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
(cherry picked from commit ff31807c357a2d486f6a18c2f3c2ceeea6365f46)
|
|
mainline inclusion
from mainline-v5.11-rc1
commit ee5d28e735082a5676c85bdc578653097e4e29e2
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94K5J
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee5d28e735082a5676c85bdc578653097e4e29e2
------------------------------------------------------
This patch fixes below warning when module is compiled with W=1 C=1
sound/soc/qcom/qdsp6/q6afe-clocks.c:122:18: warning: symbol 'q6afe_clks'
was not declared. Should it be static?
Fixes: 520a1c396d196 ("ASoC: q6afe-clocks: add q6afe clock controller")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20201105114435.22860-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
(cherry picked from commit 23b96053da438ed10434437695b7f2b2354854a5)
|
|
mainline inclusion
from mainline-v6.8-rc2
commit 08ac6f132dd77e40f786d8af51140c96c6d739c9
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94UOT
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=08ac6f132dd77e40f786d8af51140c96c6d739c9
--------------------------------
A null pointer dereference crash has been observed rarely on TI
platforms using sii9022 bridge:
[ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x]
[ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x]
[ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm]
[ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]
[ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]
[ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm]
[ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]
[ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]
[ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]
[ 53.326401] drm_client_register+0x5c/0xa0 [drm]
[ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]
[ 53.336881] tidss_probe+0x128/0x264 [tidss]
[ 53.341174] platform_probe+0x68/0xc4
[ 53.344841] really_probe+0x188/0x3c4
[ 53.348501] __driver_probe_device+0x7c/0x16c
[ 53.352854] driver_probe_device+0x3c/0x10c
[ 53.357033] __device_attach_driver+0xbc/0x158
[ 53.361472] bus_for_each_drv+0x88/0xe8
[ 53.365303] __device_attach+0xa0/0x1b4
[ 53.369135] device_initial_probe+0x14/0x20
[ 53.373314] bus_probe_device+0xb0/0xb4
[ 53.377145] deferred_probe_work_func+0xcc/0x124
[ 53.381757] process_one_work+0x1f0/0x518
[ 53.385770] worker_thread+0x1e8/0x3dc
[ 53.389519] kthread+0x11c/0x120
[ 53.392750] ret_from_fork+0x10/0x20
The issue here is as follows:
- tidss probes, but is deferred as sii902x is still missing.
- sii902x starts probing and enters sii902x_init().
- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from
DRM's perspective.
- sii902x calls sii902x_audio_codec_init() and
platform_device_register_data()
- The registration of the audio platform device causes probing of the
deferred devices.
- tidss probes, which eventually causes sii902x_bridge_get_edid() to be
called.
- sii902x_bridge_get_edid() tries to use the i2c to read the edid.
However, the sii902x driver has not set up the i2c part yet, leading
to the crash.
Fix this by moving the drm_bridge_add() to the end of the
sii902x_init(), which is also at the very end of sii902x_probe().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Fixes: 21d808405fe4 ("drm/bridge/sii902x: Fix EDID readback")
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240103-si902x-fixes-v1-1-b9fd3e448411@ideasonboard.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240103-si902x-fixes-v1-1-b9fd3e448411@ideasonboard.com
Signed-off-by: Ye Bin <yebin10@huawei.com>
(cherry picked from commit a54108956df1bf1528828dbcdf51391b5bb609bd)
|
|
stable inclusion
from stable-v5.10.209
commit be3b82e4871ba00e9b5d0ede92d396d579d7b3b3
category: bugfix
bugzilla: 189592, https://gitee.com/src-openeuler/kernel/issues/I93HCX
CVE: CVE-2024-26600
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=be3b82e4871ba00e9b5d0ede92d396d579d7b3b3
--------------------------------
[ Upstream commit 7104ba0f1958adb250319e68a15eff89ec4fd36d ]
If the external phy working together with phy-omap-usb2 does not implement
send_srp(), we may still attempt to call it. This can happen on an idle
Ethernet gadget triggering a wakeup for example:
configfs-gadget.g1 gadget.0: ECM Suspend
configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
...
Unable to handle kernel NULL pointer dereference at virtual address
00000000 when execute
...
PC is at 0x0
LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
...
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
__dev_queue_xmit from arp_solicit+0xf0/0x268
arp_solicit from neigh_probe+0x54/0x7c
neigh_probe from __neigh_event_send+0x22c/0x47c
__neigh_event_send from neigh_resolve_output+0x14c/0x1c0
neigh_resolve_output from ip_finish_output2+0x1c8/0x628
ip_finish_output2 from ip_send_skb+0x40/0xd8
ip_send_skb from udp_send_skb+0x124/0x340
udp_send_skb from udp_sendmsg+0x780/0x984
udp_sendmsg from __sys_sendto+0xd8/0x158
__sys_sendto from ret_fast_syscall+0x0/0x58
Let's fix the issue by checking for send_srp() and set_vbus() before
calling them. For USB peripheral only cases these both could be NULL.
Fixes: 657b306a7bdf ("usb: phy: add a new driver for omap usb2 phy")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20240128120556.8848-1-tony@atomide.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com>
(cherry picked from commit 7b9cb4039e767d247175fa485aa0dc1135c05ab5)
|
|
stable inclusion
from stable-v5.10.210
commit 98a4026b22ff440c7f47056481bcbbe442f607d6
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2EQ
CVE: CVE-2024-26696
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=98a4026b22ff440c7f47056481bcbbe442f607d6
--------------------------------
commit 38296afe3c6ee07319e01bb249aa4bb47c07b534 upstream.
Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
While migrate_pages_batch() locks a folio and waits for the writeback to
complete, the log writer thread that should bring the writeback to
completion picks up the folio being written back in
nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
creation and was trying to lock the folio. Thus causing a deadlock.
In the first place, it is unexpected that folios/pages in the middle of
writeback will be updated and become dirty. Nilfs2 adds a checksum to
verify the validity of the log being written and uses it for recovery at
mount, so data changes during writeback are suppressed. Since this is
broken, an unclean shutdown could potentially cause recovery to fail.
Investigation revealed that the root cause is that the wait for writeback
completion in nilfs_page_mkwrite() is conditional, and if the backing
device does not require stable writes, data may be modified without
waiting.
Fix these issues by making nilfs_page_mkwrite() wait for writeback to
finish regardless of the stable write requirement of the backing device.
Link: https://lkml.kernel.org/r/20240131145657.4209-1-konishi.ryusuke@gmail.com
Fixes: 1d1d1a767206 ("mm: only enforce stable page writes if the backing device requires it")
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+ee2ae68da3b22d04cd8d@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/00000000000047d819061004ad6c@google.com
Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lin Yujun <linyujun809@huawei.com>
Signed-off-by: Yifan Qiao <qiaoyifan4@huawei.com>
(cherry picked from commit 63b883fdddaa7691885c24fa4240b1ccc3b898b8)
|
|
Merge Pull Request from: @ci-robot
PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/P4C4ICPMZSVH2P2DG23MVR6UZ4B5PCNE/
https://gitee.com/src-openeuler/kernel/issues/I97NHT
Link:https://gitee.com/openeuler/kernel/pulls/5750
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.8-rc1
commit 41673c66b3d0c09915698fec5c13b24336f18dd1
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93L7E
CVE: CVE-2023-52467
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=41673c66b3d0c09915698fec5c13b24336f18dd1
----------------------------------------------------------------------
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
Fixes: e15d7f2b81d2 ("mfd: syscon: Use a unique name with regmap_config")
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20231204092443.2462115-1-chentao@kylinos.cn
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Chen Ridong <chenridong@huawei.com>
(cherry picked from commit ee19a73e1e6c95da57b17e1ee5dc3cf77b92e6f8)
|
|
stable inclusion
from stable-v5.10.209
commit 6e04a9d30509fb53ba6df5d655ed61d607a7cfda
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EEE
CVE: CVE-2023-52456
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6e04a9d30509fb53ba6df5d655ed61d607a7cfda
--------------------------------
[ Upstream commit 78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0 ]
When using the serial port as RS485 port, the tx statemachine is used to
control the RTS pin to drive the RS485 transceiver TX_EN pin. When the
TTY port is closed in the middle of a transmission (for instance during
userland application crash), imx_uart_shutdown disables the interface
and disables the Transmission Complete interrupt. afer that,
imx_uart_stop_tx bails on an incomplete transmission, to be retriggered
by the TC interrupt. This interrupt is disabled and therefore the tx
statemachine never transitions out of SEND. The statemachine is in
deadlock now, and the TX_EN remains low, making the interface useless.
imx_uart_stop_tx now checks for incomplete transmission AND whether TC
interrupts are enabled before bailing to be retriggered. This makes sure
the state machine handling is reached, and is properly set to
WAIT_AFTER_SEND.
Fixes: cb1a60923609 ("serial: imx: implement rts delaying for rs485")
Signed-off-by: Paul Geurts <paul_geurts@live.nl>
Tested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Tested-by: Eberhard Stoll <eberhard.stoll@gmx.de>
Link: https://lore.kernel.org/r/AM0PR09MB26758F651BC1B742EB45775995B8A@AM0PR09MB2675.eurprd09.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Felix Fu <fuzhen5@huawei.com>
(cherry picked from commit e90af23ee36ecc7b9748d4c41d43cfe9a1bee064)
|
|
stable inclusion
from stable-v5.10.211
commit c432094aa7c9970f2fa10d2305d550d3810657ce
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2MP
CVE: CVE-2024-26771
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c432094aa7c9970f2fa10d2305d550d3810657ce
--------------------------------
[ Upstream commit 6e2276203ac9ff10fc76917ec9813c660f627369 ]
devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Link: https://lore.kernel.org/r/20240118031929.192192-1-chentao@kylinos.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Conflicts:
drivers/dma/ti/edma.c
Signed-off-by: GUO Zihua <guozihua@huawei.com>
|
|
mainline inclusion
from mainline-v6.8-rc3
commit 832698373a25950942c04a512daa652c18a9b513
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2MF
CVE: CVE-2024-26772
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=832698373a25950942c04a512daa652c18a9b513
--------------------------------
Places the logic for checking if the group's block bitmap is corrupt under
the protection of the group lock to avoid allocating blocks from the group
with a corrupted block bitmap.
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240104142040.2835097-8-libaokun1@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: ZhaoLong Wang <wangzhaolong1@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5785
PR sync from: Xia Fukun <xiafukun@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/IGL4WQF73CLODBSW3DONCM2R5ET65HSD/
https://gitee.com/src-openeuler/kernel/issues/I93EDF
Link:https://gitee.com/openeuler/kernel/pulls/5828
Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5780
PR sync from: Pu Lehui <pulehui@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/UKT3JETAXT3EFXD2ZWVZOGHOUPJX2I7I/
https://gitee.com/src-openeuler/kernel/issues/I932VH
Link:https://gitee.com/openeuler/kernel/pulls/5818
Reviewed-by: Xu Kuohai <xukuohai@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5787
PR sync from: Pu Lehui <pulehui@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/DN3EODWSKDLHJAS6BFKUURFWDVQ7NYZV/
https://gitee.com/src-openeuler/kernel/issues/I93ED4
Link:https://gitee.com/openeuler/kernel/pulls/5814
Reviewed-by: Xu Kuohai <xukuohai@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.8-rc1
commit 8b13601d19c541158a6e18b278c00ba69ae37829
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I96G7Q
CVE: CVE-2023-52598
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8b13601d19c541158a6e18b278c00ba69ae37829
--------------------------------
[ Upstream commit 8b13601d19c541158a6e18b278c00ba69ae37829 ]
If the content of the floating point control (fpc) register of a traced
process is modified with the ptrace interface the new value is tested for
validity by temporarily loading it into the fpc register.
This may lead to corruption of the fpc register of the tracing process:
if an interrupt happens while the value is temporarily loaded into the
fpc register, and within interrupt context floating point or vector
registers are used, the current fp/vx registers are saved with
save_fpu_regs() assuming they belong to user space and will be loaded into
fp/vx registers when returning to user space.
test_fp_ctl() restores the original user space fpc register value, however
it will be discarded, when returning to user space.
In result the tracer will incorrectly continue to run with the value that
was supposed to be used for the traced process.
Fix this by saving fpu register contents with save_fpu_regs() before using
test_fp_ctl().
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Zheng Zucheng <zhengzucheng@huawei.com>
(cherry picked from commit d9c08632f5b31a645048b02d384722c271ba4240)
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/4764
PR sync from: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/3MRGQHW2R2LA46ZH6DMHUTX2CCUXKARV/
https://gitee.com/src-openeuler/kernel/issues/I93X0G
Link:https://gitee.com/openeuler/kernel/pulls/4801
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @ci-robot
PR sync from: Jinjiang Tu <tujinjiang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/GADNHTDLCMCCBKUYCKZGI7JZX7O5IF5A/
https://gitee.com/src-openeuler/kernel/issues/I94P5J
Link:https://gitee.com/openeuler/kernel/pulls/5792
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5788
PR sync from: Wenyu Huang <huangwenyu5@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/6ODYTTEQCMNUV22JH6YYDND2RGMQR7V4/
Maurizio Lombardi (2):
nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU
length
nvmet-tcp: Fix the H2C expected PDU len calculation
--
2.34.1
https://gitee.com/src-openeuler/kernel/issues/I93ED1
Link:https://gitee.com/openeuler/kernel/pulls/5799
Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5789
PR sync from: Luo Gengkun <luogengkun2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/PJKT4QQ4F2IEREVGJUB6SILVPAIAC5IV/
https://gitee.com/src-openeuler/kernel/issues/I94P3R
Link:https://gitee.com/openeuler/kernel/pulls/5819
Reviewed-by: Xu Kuohai <xukuohai@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.8-rc6
commit b33fb5b801c6db408b774a68e7c8722796b59ecc
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EDF
CVE: CVE-2024-26597
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b33fb5b801c6db408b774a68e7c8722796b59ecc
--------------------------------
The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
global out-of-bounds read when parsing the netlink attributes. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:284 [inline]
print_report+0x172/0x475 mm/kasan/report.c:395
kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
validate_nla lib/nlattr.c:386 [inline]
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
__nla_parse+0x3e/0x50 lib/nlattr.c:697
nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]
__rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594
rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0x154/0x190 net/socket.c:734
____sys_sendmsg+0x6df/0x840 net/socket.c:2482
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
__sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fdcf2072359
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359
RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000
</TASK>
The buggy address belongs to the variable:
rmnet_policy+0x30/0xe0
The buggy address belongs to the physical page:
page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07
ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
^
ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9
According to the comment of `nla_parse_nested_deprecated`, the maxtype
should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.
Fixes: 14452ca3b5ce ("net: qualcomm: rmnet: Export mux_id and flags to netlink")
Signed-off-by: Lin Ma <linma@zju.edu.cn>
Reviewed-by: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Link: https://lore.kernel.org/r/20240110061400.3356108-1-linma@zju.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 101422291e81dd8b3c3693dd5478c2f9d7b1f824)
|
|
UAF bugs
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5724
PR sync from: liwei <liwei728@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/QPDI6Y7IOUTFEY3LUXCSLQEEGQMICLRV/
https://gitee.com/src-openeuler/kernel/issues/I9DD86
Link:https://gitee.com/openeuler/kernel/pulls/5777
Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
in xsave buffer
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/4772
PR sync from: liwei <liwei728@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/MFBLI2HNCXNFLUVJBWO2JP6LZY7QY3UH/
https://gitee.com/src-openeuler/kernel/issues/I93HD8
Link:https://gitee.com/openeuler/kernel/pulls/4780
Reviewed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
mainline inclusion
from mainline-v6.6-rc6
commit e53899771a02f798d436655efbd9d4b46c0f9265
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94P3R
CVE: CVE-2023-52476
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e53899771a02f798d436655efbd9d4b46c0f9265
--------------------------------
We found that a panic can occur when a vsyscall is made while LBR sampling
is active. If the vsyscall is interrupted (NMI) for perf sampling, this
call sequence can occur (most recent at top):
__insn_get_emulate_prefix()
insn_get_emulate_prefix()
insn_get_prefixes()
insn_get_opcode()
decode_branch_type()
get_branch_type()
intel_pmu_lbr_filter()
intel_pmu_handle_irq()
perf_event_nmi_handler()
Within __insn_get_emulate_prefix() at frame 0, a macro is called:
peek_nbyte_next(insn_byte_t, insn, i)
Within this macro, this dereference occurs:
(insn)->next_byte
Inspecting registers at this point, the value of the next_byte field is the
address of the vsyscall made, for example the location of the vsyscall
version of gettimeofday() at 0xffffffffff600000. The access to an address
in the vsyscall region will trigger an oops due to an unhandled page fault.
To fix the bug, filtering for vsyscalls can be done when
determining the branch type. This patch will return
a "none" branch if a kernel address if found to lie in the
vsyscall region.
Suggested-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Conflicts:
arch/x86/events/utils.c
Signed-off-by: Luo Gengkun <luogengkun2@huawei.com>
(cherry picked from commit 3d005917bc01f894298b956090eeec65f2f98325)
|
|
mainline inclusion
from mainline-v6.8-rc1
commit 22c7fa171a02d310e3a3f6ed46a698ca8a0060ed
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I932VH
CVE: CVE-2024-26589
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22c7fa171a02d310e3a3f6ed46a698ca8a0060ed
--------------------------------
For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
for validation. However, variable offset ptr alu is not prohibited
for this ptr kind. So the variable offset is not checked.
The following prog is accepted:
func#0 @0
0: R1=ctx() R10=fp0
0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx()
1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys()
2: (b7) r8 = 1024 ; R8_w=1024
3: (37) r8 /= 1 ; R8_w=scalar()
4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,
smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
5: (0f) r7 += r8
mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024
mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
=(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
var_off=(0x0; 0x400))
6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar()
7: (95) exit
This prog loads flow_keys to r7, and adds the variable offset r8
to r7, and finally causes out-of-bounds access:
BUG: unable to handle page fault for address: ffffc90014c80038
[...]
Call Trace:
<TASK>
bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]
__bpf_prog_run include/linux/filter.h:651 [inline]
bpf_prog_run include/linux/filter.h:658 [inline]
bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]
bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991
bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]
__sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
__do_sys_bpf kernel/bpf/syscall.c:5561 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Fix this by rejecting ptr alu with variable offset on flow_keys.
Applying the patch rejects the program with "R7 pointer arithmetic
on flow_keys prohibited".
Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
Signed-off-by: Hao Sun <sunhao.th@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/bpf/20240115082028.9992-1-sunhao.th@gmail.com
Signed-off-by: Pu Lehui <pulehui@huawei.com>
(cherry picked from commit 7807e02487695acc451212f0dc13c3c5f7fd1ff8)
|
|
stable inclusion
from stable-v5.10.209
commit 2757f17972d87773b3677777f5682510f13c66ef
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93ED4
CVE: CVE-2023-52462
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2757f17972d87773b3677777f5682510f13c66ef
--------------------------------
[ Upstream commit ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae ]
When register is spilled onto a stack as a 1/2/4-byte register, we set
slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it,
depending on actual spill size). So to check if some stack slot has
spilled register we need to consult slot_type[7], not slot_type[0].
To avoid the need to remember and double-check this in the future, just
use is_spilled_reg() helper.
Fixes: 27113c59b6d0 ("bpf: Check the other end of slot_type for STACK_SPILL")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20231205184248.1502704-4-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
(cherry picked from commit b6ff704c0d0e0db3c76c6e99aef3c2d7443f4c37)
|
|
snapshot deleted subvolume
Merge Pull Request from: @openeuler-sync-bot
Origin pull request:
https://gitee.com/openeuler/kernel/pulls/5642
PR sync from: Long Li <leo.lilong@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LASGUEBH3GUCEGCE4KSLAVOWJCDHJO3L/
https://gitee.com/src-openeuler/kernel/issues/I9BV23
Link:https://gitee.com/openeuler/kernel/pulls/5766
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
|
|
stable inclusion
from stable-v5.10.214
commit 0de2e62067d2a6733a5b8ca24066d9bbdfefaf47
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93ED1
CVE: CVE-2023-52454
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=0de2e62067d2a6733a5b8ca24066d9bbdfefaf47
--------------------------------
[ Upstream commit 9a1abc24850eb759e36a2f8869161c3b7254c904 ]
The nvmet_tcp_handle_h2c_data_pdu() function should take into
consideration the possibility that the header digest and/or the data
digests are enabled when calculating the expected PDU length, before
comparing it to the value stored in cmd->pdu_len.
Fixes: efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Wenyu Huang <huangwenyu5@huawei.com>
(cherry picked from commit 8881a21538dfb6a9e20100da8da250f648d0c634)
|
|
stable inclusion
from stable-v5.10.214
commit f775f2621c2ac5cc3a0b3a64665dad4fb146e510
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93ED1
CVE: CVE-2023-52454
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=f775f2621c2ac5cc3a0b3a64665dad4fb146e510
--------------------------------
[ Upstream commit efa56305908ba20de2104f1b8508c6a7401833be ]
If the host sends an H2CData command with an invalid DATAL,
the kernel may crash in nvmet_tcp_build_pdu_iovec().
Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]
Call trace:
process_one_work+0x174/0x3c8
worker_thread+0x2d0/0x3e8
kthread+0x104/0x110
Fix the bug by raising a fatal error if DATAL isn't coherent
with the packet size.
Also, the PDU length should never exceed the MAXH2CDATA parameter which
has been communicated to the host in nvmet_tcp_handle_icreq().
Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Wenyu Huang <huangwenyu5@huawei.com>
(cherry picked from commit ac153a695415d95ba01adf64a394f295a968f07b)
|
|
stable inclusion
from stable-v5.10.199
commit 241f230324337ed5eae3846a554fb6d15169872c
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I94P5J
CVE: CVE-2023-52477
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=241f230324337ed5eae3846a554fb6d15169872c
--------------------------------
commit f74a7afc224acd5e922c7a2e52244d891bbe44ee upstream.
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev->bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev->bos will be NULL and those accesses will result in a
crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30
Fall back to a default behavior if the BOS descriptor isn't accessible
and skip all the functionalities that depend on it: LPM support checks,
Super Speed capabilitiy checks, U1/U2 states setup.
Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230830100418.1952143-1-ricardo.canuelo@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: sanglipeng <sanglipeng1@jd.com>
Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
|
