- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] xfs: fix unlink vs cluster buffer instantiation race
by Long Li 26 Jun '24

26 Jun '24

From: Dave Chinner <dchinner(a)redhat.com> mainline inclusion from mainline-v6.10-rc2 commit 348a1983cf4cf5099fc398438a968443af4c9f65 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA8F77 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Luis has been reporting an assert failure when freeing an inode cluster during inode inactivation for a while. The assert looks like: XFS: Assertion failed: bp->b_flags & XBF_DONE, file: fs/xfs/xfs_trans_buf.c, line: 241 ------------[ cut here ]------------ kernel BUG at fs/xfs/xfs_message.c:102! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 73 Comm: kworker/4:1 Not tainted 6.10.0-rc1 #4 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: xfs-inodegc/loop5 xfs_inodegc_worker [xfs] RIP: 0010:assfail (fs/xfs/xfs_message.c:102) xfs RSP: 0018:ffff88810188f7f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88816e748250 RCX: 1ffffffff844b0e7 RDX: 0000000000000004 RSI: ffff88810188f558 RDI: ffffffffc2431fa0 RBP: 1ffff11020311f01 R08: 0000000042431f9f R09: ffffed1020311e9b R10: ffff88810188f4df R11: ffffffffac725d70 R12: ffff88817a3f4000 R13: ffff88812182f000 R14: ffff88810188f998 R15: ffffffffc2423f80 FS: 0000000000000000(0000) GS:ffff8881c8400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fe9d0f109c CR3: 000000014426c002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> xfs_trans_read_buf_map (fs/xfs/xfs_trans_buf.c:241 (discriminator 1)) xfs xfs_imap_to_bp (fs/xfs/xfs_trans.h:210 fs/xfs/libxfs/xfs_inode_buf.c:138) xfs xfs_inode_item_precommit (fs/xfs/xfs_inode_item.c:145) xfs xfs_trans_run_precommits (fs/xfs/xfs_trans.c:931) xfs __xfs_trans_commit (fs/xfs/xfs_trans.c:966) xfs xfs_inactive_ifree (fs/xfs/xfs_inode.c:1811) xfs xfs_inactive (fs/xfs/xfs_inode.c:2013) xfs xfs_inodegc_worker (fs/xfs/xfs_icache.c:1841 fs/xfs/xfs_icache.c:1886) xfs process_one_work (kernel/workqueue.c:3231) worker_thread (kernel/workqueue.c:3306 (discriminator 2) kernel/workqueue.c:3393 (discriminator 2)) kthread (kernel/kthread.c:389) ret_from_fork (arch/x86/kernel/process.c:147) ret_from_fork_asm (arch/x86/entry/entry_64.S:257) </TASK> And occurs when the the inode precommit handlers is attempt to look up the inode cluster buffer to attach the inode for writeback. The trail of logic that I can reconstruct is as follows. 1. the inode is clean when inodegc runs, so it is not attached to a cluster buffer when precommit runs. 2. #1 implies the inode cluster buffer may be clean and not pinned by dirty inodes when inodegc runs. 3. #2 implies that the inode cluster buffer can be reclaimed by memory pressure at any time. 4. The assert failure implies that the cluster buffer was attached to the transaction, but not marked done. It had been accessed earlier in the transaction, but not marked done. 5. #4 implies the cluster buffer has been invalidated (i.e. marked stale). 6. #5 implies that the inode cluster buffer was instantiated uninitialised in the transaction in xfs_ifree_cluster(), which only instantiates the buffers to invalidate them and never marks them as done. Given factors 1-3, this issue is highly dependent on timing and environmental factors. Hence the issue can be very difficult to reproduce in some situations, but highly reliable in others. Luis has an environment where it can be reproduced easily by g/531 but, OTOH, I've reproduced it only once in ~2000 cycles of g/531. I think the fix is to have xfs_ifree_cluster() set the XBF_DONE flag on the cluster buffers, even though they may not be initialised. The reasons why I think this is safe are: 1. A buffer cache lookup hit on a XBF_STALE buffer will clear the XBF_DONE flag. Hence all future users of the buffer know they have to re-initialise the contents before use and mark it done themselves. 2. xfs_trans_binval() sets the XFS_BLI_STALE flag, which means the buffer remains locked until the journal commit completes and the buffer is unpinned. Hence once marked XBF_STALE/XFS_BLI_STALE by xfs_ifree_cluster(), the only context that can access the freed buffer is the currently running transaction. 3. #2 implies that future buffer lookups in the currently running transaction will hit the transaction match code and not the buffer cache. Hence XBF_STALE and XFS_BLI_STALE will not be cleared unless the transaction initialises and logs the buffer with valid contents again. At which point, the buffer will be marked marked XBF_DONE again, so having XBF_DONE already set on the stale buffer is a moot point. 4. #2 also implies that any concurrent access to that cluster buffer will block waiting on the buffer lock until the inode cluster has been fully freed and is no longer an active inode cluster buffer. 5. #4 + #1 means that any future user of the disk range of that buffer will always see the range of disk blocks covered by the cluster buffer as not done, and hence must initialise the contents themselves. 6. Setting XBF_DONE in xfs_ifree_cluster() then means the unlinked inode precommit code will see a XBF_DONE buffer from the transaction match as it expects. It can then attach the stale but newly dirtied inode to the stale but newly dirtied cluster buffer without unexpected failures. The stale buffer will then sail through the journal and do the right thing with the attached stale inode during unpin. Hence the fix is just one line of extra code. The explanation of why we have to set XBF_DONE in xfs_ifree_cluster, OTOH, is long and complex.... Fixes: 82842fee6e59 ("xfs: fix AGF vs inode cluster buffer deadlock") Signed-off-by: Dave Chinner <dchinner(a)redhat.com> Tested-by: Luis Chamberlain <mcgrof(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_inode.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index 2546f291e7cd..19c8df069b75 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -2318,11 +2318,26 @@ xfs_ifree_cluster( * This buffer may not have been correctly initialised as we * didn't read it from disk. That's not important because we are * only using to mark the buffer as stale in the log, and to - * attach stale cached inodes on it. That means it will never be - * dispatched for IO. If it is, we want to know about it, and we - * want it to fail. We can acheive this by adding a write - * verifier to the buffer. + * attach stale cached inodes on it. + * + * For the inode that triggered the cluster freeing, this + * attachment may occur in xfs_inode_item_precommit() after we + * have marked this buffer stale. If this buffer was not in + * memory before xfs_ifree_cluster() started, it will not be + * marked XBF_DONE and this will cause problems later in + * xfs_inode_item_precommit() when we trip over a (stale, !done) + * buffer to attached to the transaction. + * + * Hence we have to mark the buffer as XFS_DONE here. This is + * safe because we are also marking the buffer as XBF_STALE and + * XFS_BLI_STALE. That means it will never be dispatched for + * IO and it won't be unlocked until the cluster freeing has + * been committed to the journal and the buffer unpinned. If it + * is written, we want to know about it, and we want it to + * fail. We can acheive this by adding a write verifier to the + * buffer. */ + bp->b_flags |= XBF_DONE; bp->b_ops = &xfs_inode_buf_ops; /* -- 2.39.2

2 1

[PATCH OLK-6.6] watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
by Xiongfeng Wang 26 Jun '24

26 Jun '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit 573601521277119f2e2ba5f28ae6e87fc594f4d4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D7P CVE: CVE-2024-38630 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen. Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released. Fixes: e09d9c3e9f85 ("watchdog: cpu5wdt.c: add missing del_timer call") Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> Link: https://lore.kernel.org/r/20240324140444.119584-1-duoming@zju.edu.cn Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)linux-watchdog.org> Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> --- drivers/watchdog/cpu5wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/cpu5wdt.c b/drivers/watchdog/cpu5wdt.c index 688b112e712b..9f279c0e13a6 100644 --- a/drivers/watchdog/cpu5wdt.c +++ b/drivers/watchdog/cpu5wdt.c @@ -252,7 +252,7 @@ static void cpu5wdt_exit(void) if (cpu5wdt_device.queue) { cpu5wdt_device.queue = 0; wait_for_completion(&cpu5wdt_device.stop); - del_timer(&cpu5wdt_device.timer); + timer_shutdown_sync(&cpu5wdt_device.timer); } misc_deregister(&cpu5wdt_misc); -- 2.20.1

2 1

[PATCH OLK-5.10] watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
by Xiongfeng Wang 26 Jun '24

26 Jun '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit 573601521277119f2e2ba5f28ae6e87fc594f4d4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D7P CVE: CVE-2024-38630 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen. Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released. Fixes: e09d9c3e9f85 ("watchdog: cpu5wdt.c: add missing del_timer call") Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> Link: https://lore.kernel.org/r/20240324140444.119584-1-duoming@zju.edu.cn Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)linux-watchdog.org> Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> --- drivers/watchdog/cpu5wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/cpu5wdt.c b/drivers/watchdog/cpu5wdt.c index 9867a3a936df..91adfb55c972 100644 --- a/drivers/watchdog/cpu5wdt.c +++ b/drivers/watchdog/cpu5wdt.c @@ -252,7 +252,7 @@ static void cpu5wdt_exit(void) if (cpu5wdt_device.queue) { cpu5wdt_device.queue = 0; wait_for_completion(&cpu5wdt_device.stop); - del_timer(&cpu5wdt_device.timer); + timer_shutdown_sync(&cpu5wdt_device.timer); } misc_deregister(&cpu5wdt_misc); -- 2.20.1

2 1

[PATCH OLK-6.6] blk-wbt: don't throttle swap writes in direct reclaim
by Baokun Li 26 Jun '24

26 Jun '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA8D5J Reference: https://lore.kernel.org/r/20240604030522.3686177-1-libaokun@huaweicloud.com/ -------------------------------- Now we avoid throttling swap writes by determining whether the current process is kswapd (aka current_is_kswapd()), but swap writes can come from either kswapd or direct reclaim, so the swap writes from direct reclaim will still be throttled. When a process holds a lock to allocate a free page, and enters direct reclaim because there is no free memory, then it might trigger a hung due to the wbt throttling that causes other processes to fail to get the lock. Both kswapd and direct reclaim set the REQ_SWAP flag, so use REQ_SWAP instead of current_is_kswapd() to avoid throttling swap writes. Also renamed WBT_KSWAPD to WBT_SWAP and WBT_RWQ_KSWAPD to WBT_RWQ_SWAP. Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Yu Kuai <yukuai3(a)huawei.com> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- block/blk-wbt.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/block/blk-wbt.c b/block/blk-wbt.c index f8fda9cf583e..296cdfea7c2a 100644 --- a/block/blk-wbt.c +++ b/block/blk-wbt.c @@ -36,7 +36,7 @@ enum wbt_flags { WBT_TRACKED = 1, /* write, tracked for throttling */ WBT_READ = 2, /* read */ - WBT_KSWAPD = 4, /* write, from kswapd */ + WBT_SWAP = 4, /* write, from swap_writepage() */ WBT_DISCARD = 8, /* discard */ WBT_NR_BITS = 4, /* number of bits */ @@ -44,7 +44,7 @@ enum wbt_flags { enum { WBT_RWQ_BG = 0, - WBT_RWQ_KSWAPD, + WBT_RWQ_SWAP, WBT_RWQ_DISCARD, WBT_NUM_RWQ, }; @@ -173,8 +173,8 @@ static bool wb_recent_wait(struct rq_wb *rwb) static inline struct rq_wait *get_rq_wait(struct rq_wb *rwb, enum wbt_flags wb_acct) { - if (wb_acct & WBT_KSWAPD) - return &rwb->rq_wait[WBT_RWQ_KSWAPD]; + if (wb_acct & WBT_SWAP) + return &rwb->rq_wait[WBT_RWQ_SWAP]; else if (wb_acct & WBT_DISCARD) return &rwb->rq_wait[WBT_RWQ_DISCARD]; @@ -529,7 +529,7 @@ static bool close_io(struct rq_wb *rwb) time_before(now, rwb->last_comp + HZ / 10); } -#define REQ_HIPRIO (REQ_SYNC | REQ_META | REQ_PRIO) +#define REQ_HIPRIO (REQ_SYNC | REQ_META | REQ_PRIO | REQ_SWAP) static inline unsigned int get_limit(struct rq_wb *rwb, blk_opf_t opf) { @@ -540,13 +540,13 @@ static inline unsigned int get_limit(struct rq_wb *rwb, blk_opf_t opf) /* * At this point we know it's a buffered write. If this is - * kswapd trying to free memory, or REQ_SYNC is set, then + * swap trying to free memory, or REQ_SYNC is set, then * it's WB_SYNC_ALL writeback, and we'll use the max limit for * that. If the write is marked as a background write, then use * the idle limit, or go to normal if we haven't had competing * IO for a bit. */ - if ((opf & REQ_HIPRIO) || wb_recent_wait(rwb) || current_is_kswapd()) + if ((opf & REQ_HIPRIO) || wb_recent_wait(rwb)) limit = rwb->rq_depth.max_depth; else if ((opf & REQ_BACKGROUND) || close_io(rwb)) { /* @@ -623,8 +623,8 @@ static enum wbt_flags bio_to_wbt_flags(struct rq_wb *rwb, struct bio *bio) if (bio_op(bio) == REQ_OP_READ) { flags = WBT_READ; } else if (wbt_should_throttle(bio)) { - if (current_is_kswapd()) - flags |= WBT_KSWAPD; + if (bio->bi_opf & REQ_SWAP) + flags |= WBT_SWAP; if (bio_op(bio) == REQ_OP_DISCARD) flags |= WBT_DISCARD; flags |= WBT_TRACKED; -- 2.31.1

2 1

[PATCH OLK-6.6 0/2] CVE-2024-38610
by Xiongfeng Wang 26 Jun '24

26 Jun '24

Christoph Hellwig (1): virt: acrn: stop using follow_pfn David Hildenbrand (1): drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() drivers/virt/acrn/mm.c | 61 +++++++++++++++++++++++++++++++++--------- 1 file changed, 49 insertions(+), 12 deletions(-) -- 2.20.1

2 3

[PATCH openEuler-1.0-LTS] um: Add winch to winch_handlers before registering winch IRQ
by Chen Zhongjin 26 Jun '24

26 Jun '24

From: Roberto Sassu <roberto.sassu(a)huawei.com> stable inclusion from stable-v4.19.316 commit 66ea9a7c6824821476914bed21a476cd20094f33 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YJR CVE: CVE-2024-39292 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a0fbbd36c156b9f7b2276871d499c9943dfe5101 ] Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails. Fixes: 42a359e31a0e ("uml: SIGIO support cleanup") Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> Reviewed-by: Johannes Berg <johannes(a)sipsolutions.net> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- arch/um/drivers/line.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c index 7e524efed584..71e26488dfde 100644 --- a/arch/um/drivers/line.c +++ b/arch/um/drivers/line.c @@ -683,24 +683,26 @@ void register_winch_irq(int fd, int tty_fd, int pid, struct tty_port *port, goto cleanup; } - *winch = ((struct winch) { .list = LIST_HEAD_INIT(winch->list), - .fd = fd, + *winch = ((struct winch) { .fd = fd, .tty_fd = tty_fd, .pid = pid, .port = port, .stack = stack }); + spin_lock(&winch_handler_lock); + list_add(&winch->list, &winch_handlers); + spin_unlock(&winch_handler_lock); + if (um_request_irq(WINCH_IRQ, fd, IRQ_READ, winch_interrupt, IRQF_SHARED, "winch", winch) < 0) { printk(KERN_ERR "register_winch_irq - failed to register " "IRQ\n"); + spin_lock(&winch_handler_lock); + list_del(&winch->list); + spin_unlock(&winch_handler_lock); goto out_free; } - spin_lock(&winch_handler_lock); - list_add(&winch->list, &winch_handlers); - spin_unlock(&winch_handler_lock); - return; out_free: -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2021-47434
by Yuan Can 26 Jun '24

26 Jun '24

Mathias Nyman (1): xhci: Fix commad ring abort, write all 64 bits to CRCR register. Pavankumar Kondeti (1): xhci: Fix command ring pointer corruption while aborting a command drivers/usb/host/xhci-ring.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) -- 2.17.1

2 3

[PATCH OLK-5.10] net/mlx5: Add a timeout to acquire the command queue semaphore
by Zhengchao Shao 26 Jun '24

26 Jun '24

From: Akiva Goldberger <agoldberger(a)nvidia.com> mainline inclusion from mainline-v6.10-rc1 commit 485d65e1357123a697c591a5aeb773994b247ad7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S89 CVE: CVE-2024-38556 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion. Kernel log example: mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion Fixes: 8e715cd613a1 ("net/mlx5: Set command entry semaphore up once got index free") Signed-off-by: Akiva Goldberger <agoldberger(a)nvidia.com> Reviewed-by: Moshe Shemesh <moshe(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Link: https://lore.kernel.org/r/20240509112951.590184-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlx5/core/cmd.c [The conflict occurs because the commit 5945e1adeab5("net/mlx5: Read timeout values from init segment") and 58db72869a9f("net/mlx5: Re-organize mlx5_cmd struct") and 8f5100da56b3("net/mlx5e: Fix a race in command alloc flow") and 7cb5eb937231("net/mlx5: Introduce and use opcode getter in command interface") and f086470122d5("net/mlx5: cmdif, Return value improvements") are not merged. MLX5_CMD_TIMEOUT_MSEC is used for timeout and cannot be configured by users. struct mlx5_cmd does not contain the var variable and directly references to sem.] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 36 +++++++++++++++---- include/linux/mlx5/driver.h | 1 + 2 files changed, 30 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c index bb1dba03de7c..f1478c6ec765 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c @@ -900,18 +900,30 @@ static void cmd_work_handler(struct work_struct *work) struct mlx5_cmd_work_ent *ent = container_of(work, struct mlx5_cmd_work_ent, work); struct mlx5_cmd *cmd = ent->cmd; struct mlx5_core_dev *dev = container_of(cmd, struct mlx5_core_dev, cmd); - unsigned long cb_timeout = msecs_to_jiffies(MLX5_CMD_TIMEOUT_MSEC); + unsigned long timeout = msecs_to_jiffies(MLX5_CMD_TIMEOUT_MSEC); struct mlx5_cmd_layout *lay; - struct semaphore *sem; unsigned long flags; bool poll_cmd = ent->polling; int alloc_ret; int cmd_mode; complete(&ent->handling); - sem = ent->page_queue ? &cmd->pages_sem : &cmd->sem; - down(sem); if (!ent->page_queue) { + if (down_timeout(&cmd->sem, timeout)) { + mlx5_core_warn(dev, "%s(0x%x) timed out while waiting for a slot.\n", + mlx5_command_str(ent->op), ent->op); + if (ent->callback) { + ent->callback(-EBUSY, ent->context); + mlx5_free_cmd_msg(dev, ent->out); + free_msg(dev, ent->in); + cmd_ent_put(ent); + } else { + ent->ret = -EBUSY; + complete(&ent->done); + } + complete(&ent->slotted); + return; + } alloc_ret = cmd_alloc_index(cmd); if (alloc_ret < 0) { mlx5_core_err_rl(dev, "failed to allocate command entry\n"); @@ -924,11 +936,12 @@ static void cmd_work_handler(struct work_struct *work) ent->ret = -EAGAIN; complete(&ent->done); } - up(sem); + up(&cmd->sem); return; } ent->idx = alloc_ret; } else { + down(&cmd->pages_sem); ent->idx = cmd->max_reg_cmds; spin_lock_irqsave(&cmd->alloc_lock, flags); clear_bit(ent->idx, &cmd->bitmask); @@ -936,6 +949,8 @@ static void cmd_work_handler(struct work_struct *work) } cmd->ent_arr[ent->idx] = ent; + + complete(&ent->slotted); lay = get_inst(cmd, ent->idx); ent->lay = lay; memset(lay, 0, sizeof(*lay)); @@ -955,7 +970,7 @@ static void cmd_work_handler(struct work_struct *work) ent->ts1 = ktime_get_ns(); cmd_mode = cmd->mode; - if (ent->callback && schedule_delayed_work(&ent->cb_timeout_work, cb_timeout)) + if (ent->callback && schedule_delayed_work(&ent->cb_timeout_work, timeout)) cmd_ent_get(ent); set_bit(MLX5_CMD_ENT_STATE_PENDING_COMP, &ent->state); @@ -1056,6 +1071,9 @@ static int wait_func(struct mlx5_core_dev *dev, struct mlx5_cmd_work_ent *ent) ent->ret = -ECANCELED; goto out_err; } + + wait_for_completion(&ent->slotted); + if (cmd->mode == CMD_MODE_POLLING || ent->polling) wait_for_completion(&ent->done); else if (!wait_for_completion_timeout(&ent->done, timeout)) @@ -1072,6 +1090,9 @@ static int wait_func(struct mlx5_core_dev *dev, struct mlx5_cmd_work_ent *ent) mlx5_core_warn(dev, "%s(0x%x) canceled on out of queue timeout.\n", mlx5_command_str(msg_to_opcode(ent->in)), msg_to_opcode(ent->in)); + } else if (err == -EBUSY) { + mlx5_core_warn(dev, "%s(0x%x) timeout while waiting for command semaphore.\n", + mlx5_command_str(ent->op), ent->op); } mlx5_core_dbg(dev, "err %d, delivery status %s(%d)\n", err, deliv_status_to_str(ent->status), ent->status); @@ -1113,6 +1134,7 @@ static int mlx5_cmd_invoke(struct mlx5_core_dev *dev, struct mlx5_cmd_msg *in, ent->polling = force_polling; init_completion(&ent->handling); + init_completion(&ent->slotted); if (!callback) init_completion(&ent->done); @@ -1130,7 +1152,7 @@ static int mlx5_cmd_invoke(struct mlx5_core_dev *dev, struct mlx5_cmd_msg *in, goto out; /* mlx5_cmd_comp_handler() will put(ent) */ err = wait_func(dev, ent); - if (err == -ETIMEDOUT || err == -ECANCELED) + if (err == -ETIMEDOUT || err == -ECANCELED || err == -EBUSY) goto out_free; ds = ent->ts2 - ent->ts1; diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h index 2cd89af4dbf6..63feb2878c7a 100644 --- a/include/linux/mlx5/driver.h +++ b/include/linux/mlx5/driver.h @@ -762,6 +762,7 @@ struct mlx5_cmd_work_ent { void *context; int idx; struct completion handling; + struct completion slotted; struct completion done; struct mlx5_cmd *cmd; struct work_struct work; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] net/mlx5: Add a timeout to acquire the command queue semaphore
by Zhengchao Shao 26 Jun '24

26 Jun '24

From: Akiva Goldberger <agoldberger(a)nvidia.com> mainline inclusion from mainline-v6.10-rc1 commit 485d65e1357123a697c591a5aeb773994b247ad7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S89 CVE: CVE-2024-38556 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion. Kernel log example: mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion Fixes: 8e715cd613a1 ("net/mlx5: Set command entry semaphore up once got index free") Signed-off-by: Akiva Goldberger <agoldberger(a)nvidia.com> Reviewed-by: Moshe Shemesh <moshe(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Link: https://lore.kernel.org/r/20240509112951.590184-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlx5/core/cmd.c [The conflict occurs because the commit 5945e1adeab5("net/mlx5: Read timeout values from init segment") and 58db72869a9f("net/mlx5: Re-organize mlx5_cmd struct") and 8f5100da56b3("net/mlx5e: Fix a race in command alloc flow") and 7cb5eb937231("net/mlx5: Introduce and use opcode getter in command interface") and f086470122d5("net/mlx5: cmdif, Return value improvements") are not merged. MLX5_CMD_TIMEOUT_MSEC is used for timeout and cannot be configured by users. struct mlx5_cmd does not contain the var variable and directly references to sem.] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 36 +++++++++++++++---- include/linux/mlx5/driver.h | 1 + 2 files changed, 30 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c index fb196d312548..6c7efba80c97 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c @@ -900,18 +900,30 @@ static void cmd_work_handler(struct work_struct *work) struct mlx5_cmd_work_ent *ent = container_of(work, struct mlx5_cmd_work_ent, work); struct mlx5_cmd *cmd = ent->cmd; struct mlx5_core_dev *dev = container_of(cmd, struct mlx5_core_dev, cmd); - unsigned long cb_timeout = msecs_to_jiffies(MLX5_CMD_TIMEOUT_MSEC); + unsigned long timeout = msecs_to_jiffies(MLX5_CMD_TIMEOUT_MSEC); struct mlx5_cmd_layout *lay; - struct semaphore *sem; unsigned long flags; bool poll_cmd = ent->polling; int alloc_ret; int cmd_mode; complete(&ent->handling); - sem = ent->page_queue ? &cmd->pages_sem : &cmd->sem; - down(sem); if (!ent->page_queue) { + if (down_timeout(&cmd->sem, timeout)) { + mlx5_core_warn(dev, "%s(0x%x) timed out while waiting for a slot.\n", + mlx5_command_str(ent->op), ent->op); + if (ent->callback) { + ent->callback(-EBUSY, ent->context); + mlx5_free_cmd_msg(dev, ent->out); + free_msg(dev, ent->in); + cmd_ent_put(ent); + } else { + ent->ret = -EBUSY; + complete(&ent->done); + } + complete(&ent->slotted); + return; + } alloc_ret = cmd_alloc_index(cmd); if (alloc_ret < 0) { mlx5_core_err_rl(dev, "failed to allocate command entry\n"); @@ -924,11 +936,12 @@ static void cmd_work_handler(struct work_struct *work) ent->ret = -EAGAIN; complete(&ent->done); } - up(sem); + up(&cmd->sem); return; } ent->idx = alloc_ret; } else { + down(&cmd->pages_sem); ent->idx = cmd->max_reg_cmds; spin_lock_irqsave(&cmd->alloc_lock, flags); clear_bit(ent->idx, &cmd->bitmask); @@ -936,6 +949,8 @@ static void cmd_work_handler(struct work_struct *work) } cmd->ent_arr[ent->idx] = ent; + + complete(&ent->slotted); lay = get_inst(cmd, ent->idx); ent->lay = lay; memset(lay, 0, sizeof(*lay)); @@ -955,7 +970,7 @@ static void cmd_work_handler(struct work_struct *work) ent->ts1 = ktime_get_ns(); cmd_mode = cmd->mode; - if (ent->callback && schedule_delayed_work(&ent->cb_timeout_work, cb_timeout)) + if (ent->callback && schedule_delayed_work(&ent->cb_timeout_work, timeout)) cmd_ent_get(ent); set_bit(MLX5_CMD_ENT_STATE_PENDING_COMP, &ent->state); @@ -1056,6 +1071,9 @@ static int wait_func(struct mlx5_core_dev *dev, struct mlx5_cmd_work_ent *ent) ent->ret = -ECANCELED; goto out_err; } + + wait_for_completion(&ent->slotted); + if (cmd->mode == CMD_MODE_POLLING || ent->polling) wait_for_completion(&ent->done); else if (!wait_for_completion_timeout(&ent->done, timeout)) @@ -1072,6 +1090,9 @@ static int wait_func(struct mlx5_core_dev *dev, struct mlx5_cmd_work_ent *ent) mlx5_core_warn(dev, "%s(0x%x) canceled on out of queue timeout.\n", mlx5_command_str(msg_to_opcode(ent->in)), msg_to_opcode(ent->in)); + } else if (err == -EBUSY) { + mlx5_core_warn(dev, "%s(0x%x) timeout while waiting for command semaphore.\n", + mlx5_command_str(ent->op), ent->op); } mlx5_core_dbg(dev, "err %d, delivery status %s(%d)\n", err, deliv_status_to_str(ent->status), ent->status); @@ -1113,6 +1134,7 @@ static int mlx5_cmd_invoke(struct mlx5_core_dev *dev, struct mlx5_cmd_msg *in, ent->polling = force_polling; init_completion(&ent->handling); + init_completion(&ent->slotted); if (!callback) init_completion(&ent->done); @@ -1130,7 +1152,7 @@ static int mlx5_cmd_invoke(struct mlx5_core_dev *dev, struct mlx5_cmd_msg *in, goto out; /* mlx5_cmd_comp_handler() will put(ent) */ err = wait_func(dev, ent); - if (err == -ETIMEDOUT || err == -ECANCELED) + if (err == -ETIMEDOUT || err == -ECANCELED || err == -EBUSY) goto out_free; ds = ent->ts2 - ent->ts1; diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h index 41fbb4793394..f3695ef9db60 100644 --- a/include/linux/mlx5/driver.h +++ b/include/linux/mlx5/driver.h @@ -756,6 +756,7 @@ struct mlx5_cmd_work_ent { void *context; int idx; struct completion handling; + struct completion slotted; struct completion done; struct mlx5_cmd *cmd; struct work_struct work; -- 2.34.1

2 1

[PATCH OLK-6.6] io_uring: check for non-NULL file pointer in io_file_can_poll()
by Yifan Qiao 26 Jun '24

26 Jun '24

From: Jens Axboe <axboe(a)kernel.dk> stable inclusion from stable-v6.6.35 commit 43cfac7b88adedfb26c27834386992650f1642f3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEH CVE: CVE-2024-39371 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5fc16fa5f13b3c06fdb959ef262050bd810416a2 upstream. In earlier kernels, it was possible to trigger a NULL pointer dereference off the forced async preparation path, if no file had been assigned. The trace leading to that looks as follows: BUG: kernel NULL pointer dereference, address: 00000000000000b0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022 RIP: 0010:io_buffer_select+0xc3/0x210 Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246 RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040 RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700 RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020 R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8 R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000 FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0 Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x14d/0x420 ? do_user_addr_fault+0x61/0x6a0 ? exc_page_fault+0x6c/0x150 ? asm_exc_page_fault+0x22/0x30 ? io_buffer_select+0xc3/0x210 __io_import_iovec+0xb5/0x120 io_readv_prep_async+0x36/0x70 io_queue_sqe_fallback+0x20/0x260 io_submit_sqes+0x314/0x630 __do_sys_io_uring_enter+0x339/0xbc0 ? __do_sys_io_uring_register+0x11b/0xc50 ? vm_mmap_pgoff+0xce/0x160 do_syscall_64+0x5f/0x180 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x55e0a110a67e Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6 because the request is marked forced ASYNC and has a bad file fd, and hence takes the forced async prep path. Current kernels with the request async prep cleaned up can no longer hit this issue, but for ease of backporting, let's add this safety check in here too as it really doesn't hurt. For both cases, this will inevitably end with a CQE posted with -EBADF. Cc: stable(a)vger.kernel.org Fixes: a76c0b31eef5 ("io_uring: commit non-pollable provided mapped buffers upfront") Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- io_uring/kbuf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c index 26a00920042c..702c08c26cd4 100644 --- a/io_uring/kbuf.c +++ b/io_uring/kbuf.c @@ -168,7 +168,8 @@ static void __user *io_ring_buffer_select(struct io_kiocb *req, size_t *len, req->buf_list = bl; req->buf_index = buf->bid; - if (issue_flags & IO_URING_F_UNLOCKED || !file_can_poll(req->file)) { + if (issue_flags & IO_URING_F_UNLOCKED || + (req->file && !file_can_poll(req->file))) { /* * If we came in unlocked, we have no choice but to consume the * buffer here, otherwise nothing ensures that the buffer won't -- 2.39.2

2 1

[PATCH OLK-6.6 0/2] CVE-2024-38662
by Pu Lehui 26 Jun '24

26 Jun '24

Jakub Sitnicki (2): bpf: Allow delete from sockmap/sockhash only if update is allowed Revert "bpf, sockmap: Prevent lock inversion deadlock in map delete elem" kernel/bpf/verifier.c | 10 +++++++--- net/core/sock_map.c | 6 ------ 2 files changed, 7 insertions(+), 9 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS 0/2] quota: Fix rcu annotations of inode dquot pointers
by Baokun Li 26 Jun '24

26 Jun '24

Jan Kara (1): quota: Fix rcu annotations of inode dquot pointers Jiang Biao (1): fs/quota: erase unused but set variable warning fs/quota/dquot.c | 71 +++++++++++++++++++++++++++++------------------- 1 file changed, 43 insertions(+), 28 deletions(-) -- 2.31.1

2 3

[PATCH OLK-6.6 0/1] fix CVE-2024-38621
by Liao Chen 26 Jun '24

26 Jun '24

media: stk1160: fix bounds checking in stk1160_copy_video() Dan Carpenter (1): media: stk1160: fix bounds checking in stk1160_copy_video() drivers/media/usb/stk1160/stk1160-video.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) -- 2.34.1

2 2

[PATCH OLK-5.10 v2 0/2] CVE-2024-27032
by Xiongfeng Wang 26 Jun '24

26 Jun '24

Chao Yu (2): f2fs: fix to check return value of f2fs_reserve_new_block() f2fs: fix to avoid potential panic during recovery fs/f2fs/f2fs.h | 5 +++++ fs/f2fs/recovery.c | 26 ++++++++++++++++++-------- 2 files changed, 23 insertions(+), 8 deletions(-) -- 2.20.1

2 3

[PATCH openEuler-22.03-LTS-SP1 v2 0/2] CVE-2024-27032
by Xiongfeng Wang 26 Jun '24

26 Jun '24

Chao Yu (2): f2fs: fix to check return value of f2fs_reserve_new_block() f2fs: fix to avoid potential panic during recovery fs/f2fs/f2fs.h | 5 +++++ fs/f2fs/recovery.c | 26 ++++++++++++++++++-------- 2 files changed, 23 insertions(+), 8 deletions(-) -- 2.20.1

2 3

[PATCH OLK-6.6] bpf: Fix verifier assumptions about socket->sk
by Tengda Wu 26 Jun '24

26 Jun '24

From: Alexei Starovoitov <ast(a)kernel.org> mainline inclusion from mainline-v6.10-rc1 commit 0db63c0b86e981a1e97d2596d64ceceba1a5470e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA77YV CVE: CVE-2024-38566 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The verifier assumes that 'sk' field in 'struct socket' is valid and non-NULL when 'socket' pointer itself is trusted and non-NULL. That may not be the case when socket was just created and passed to LSM socket_accept hook. Fix this verifier assumption and adjust tests. Reported-by: Liam Wisehart <liamwisehart(a)meta.com> Acked-by: Kumar Kartikeya Dwivedi <memxor(a)gmail.com> Fixes: 6fcd486b3a0a ("bpf: Refactor RCU enforcement in the verifier.") Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Link: https://lore.kernel.org/r/20240427002544.68803-1-alexei.starovoitov@gmail.c… Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Conflicts: kernel/bpf/verifier.c [this is because we did not backport commit 36d8bdf75a93 ("bpf: Add alloc/xchg/direct_access support for local percpu kptr")] since it is a feature commit] Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/bpf/verifier.c | 23 +++++++++++++++---- .../bpf/progs/bench_local_storage_create.c | 5 ++-- .../selftests/bpf/progs/local_storage.c | 20 ++++++++-------- .../testing/selftests/bpf/progs/lsm_cgroup.c | 8 +++++-- 4 files changed, 38 insertions(+), 18 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 1fcba0c46f6e..555c7801d90f 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2543,6 +2543,8 @@ static void mark_btf_ld_reg(struct bpf_verifier_env *env, regs[regno].type = PTR_TO_BTF_ID | flag; regs[regno].btf = btf; regs[regno].btf_id = btf_id; + if (type_may_be_null(flag)) + regs[regno].id = ++env->id_gen; } #define DEF_NOT_SUBREG (0) @@ -5375,8 +5377,6 @@ static int check_map_kptr_access(struct bpf_verifier_env *env, u32 regno, rcu_safe_kptr(kptr_field) && in_rcu_cs(env) ? PTR_MAYBE_NULL | MEM_RCU : PTR_MAYBE_NULL | PTR_UNTRUSTED); - /* For mark_ptr_or_null_reg */ - val_reg->id = ++env->id_gen; } else if (class == BPF_STX) { val_reg = reg_state(env, value_regno); if (!register_is_null(val_reg) && @@ -5686,7 +5686,8 @@ static bool is_trusted_reg(const struct bpf_reg_state *reg) return true; /* Types listed in the reg2btf_ids are always trusted */ - if (reg2btf_ids[base_type(reg->type)]) + if (reg2btf_ids[base_type(reg->type)] && + !bpf_type_has_unsafe_modifiers(reg->type)) return true; /* If a register is not referenced, it is trusted if it has the @@ -6265,6 +6266,7 @@ static int bpf_map_direct_read(struct bpf_map *map, int off, int size, u64 *val, #define BTF_TYPE_SAFE_RCU(__type) __PASTE(__type, __safe_rcu) #define BTF_TYPE_SAFE_RCU_OR_NULL(__type) __PASTE(__type, __safe_rcu_or_null) #define BTF_TYPE_SAFE_TRUSTED(__type) __PASTE(__type, __safe_trusted) +#define BTF_TYPE_SAFE_TRUSTED_OR_NULL(__type) __PASTE(__type, __safe_trusted_or_null) /* * Allow list few fields as RCU trusted or full trusted. @@ -6328,7 +6330,7 @@ BTF_TYPE_SAFE_TRUSTED(struct dentry) { struct inode *d_inode; }; -BTF_TYPE_SAFE_TRUSTED(struct socket) { +BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct socket) { struct sock *sk; }; @@ -6363,11 +6365,20 @@ static bool type_is_trusted(struct bpf_verifier_env *env, BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct linux_binprm)); BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct file)); BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct dentry)); - BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct socket)); return btf_nested_type_is_trusted(&env->log, reg, field_name, btf_id, "__safe_trusted"); } +static bool type_is_trusted_or_null(struct bpf_verifier_env *env, + struct bpf_reg_state *reg, + const char *field_name, u32 btf_id) +{ + BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED_OR_NULL(struct socket)); + + return btf_nested_type_is_trusted(&env->log, reg, field_name, btf_id, + "__safe_trusted_or_null"); +} + static int check_ptr_to_btf_access(struct bpf_verifier_env *env, struct bpf_reg_state *regs, int regno, int off, int size, @@ -6476,6 +6487,8 @@ static int check_ptr_to_btf_access(struct bpf_verifier_env *env, */ if (type_is_trusted(env, reg, field_name, btf_id)) { flag |= PTR_TRUSTED; + } else if (type_is_trusted_or_null(env, reg, field_name, btf_id)) { + flag |= PTR_TRUSTED | PTR_MAYBE_NULL; } else if (in_rcu_cs(env) && !type_may_be_null(reg->type)) { if (type_is_rcu(env, reg, field_name, btf_id)) { /* ignore __rcu tag and mark it MEM_RCU */ diff --git a/tools/testing/selftests/bpf/progs/bench_local_storage_create.c b/tools/testing/selftests/bpf/progs/bench_local_storage_create.c index e4bfbba6c193..c8ec0d0368e4 100644 --- a/tools/testing/selftests/bpf/progs/bench_local_storage_create.c +++ b/tools/testing/selftests/bpf/progs/bench_local_storage_create.c @@ -61,14 +61,15 @@ SEC("lsm.s/socket_post_create") int BPF_PROG(socket_post_create, struct socket *sock, int family, int type, int protocol, int kern) { + struct sock *sk = sock->sk; struct storage *stg; __u32 pid; pid = bpf_get_current_pid_tgid() >> 32; - if (pid != bench_pid) + if (pid != bench_pid || !sk) return 0; - stg = bpf_sk_storage_get(&sk_storage_map, sock->sk, NULL, + stg = bpf_sk_storage_get(&sk_storage_map, sk, NULL, BPF_LOCAL_STORAGE_GET_F_CREATE); if (stg) diff --git a/tools/testing/selftests/bpf/progs/local_storage.c b/tools/testing/selftests/bpf/progs/local_storage.c index bc8ea56671a1..3bf75f4ea690 100644 --- a/tools/testing/selftests/bpf/progs/local_storage.c +++ b/tools/testing/selftests/bpf/progs/local_storage.c @@ -140,11 +140,12 @@ int BPF_PROG(socket_bind, struct socket *sock, struct sockaddr *address, { __u32 pid = bpf_get_current_pid_tgid() >> 32; struct local_storage *storage; + struct sock *sk = sock->sk; - if (pid != monitored_pid) + if (pid != monitored_pid || !sk) return 0; - storage = bpf_sk_storage_get(&sk_storage_map, sock->sk, 0, 0); + storage = bpf_sk_storage_get(&sk_storage_map, sk, 0, 0); if (!storage) return 0; @@ -155,24 +156,24 @@ int BPF_PROG(socket_bind, struct socket *sock, struct sockaddr *address, /* This tests that we can associate multiple elements * with the local storage. */ - storage = bpf_sk_storage_get(&sk_storage_map2, sock->sk, 0, + storage = bpf_sk_storage_get(&sk_storage_map2, sk, 0, BPF_LOCAL_STORAGE_GET_F_CREATE); if (!storage) return 0; - if (bpf_sk_storage_delete(&sk_storage_map2, sock->sk)) + if (bpf_sk_storage_delete(&sk_storage_map2, sk)) return 0; - storage = bpf_sk_storage_get(&sk_storage_map2, sock->sk, 0, + storage = bpf_sk_storage_get(&sk_storage_map2, sk, 0, BPF_LOCAL_STORAGE_GET_F_CREATE); if (!storage) return 0; - if (bpf_sk_storage_delete(&sk_storage_map, sock->sk)) + if (bpf_sk_storage_delete(&sk_storage_map, sk)) return 0; /* Ensure that the sk_storage_map is disconnected from the storage. */ - if (!sock->sk->sk_bpf_storage || sock->sk->sk_bpf_storage->smap) + if (!sk->sk_bpf_storage || sk->sk_bpf_storage->smap) return 0; sk_storage_result = 0; @@ -185,11 +186,12 @@ int BPF_PROG(socket_post_create, struct socket *sock, int family, int type, { __u32 pid = bpf_get_current_pid_tgid() >> 32; struct local_storage *storage; + struct sock *sk = sock->sk; - if (pid != monitored_pid) + if (pid != monitored_pid || !sk) return 0; - storage = bpf_sk_storage_get(&sk_storage_map, sock->sk, 0, + storage = bpf_sk_storage_get(&sk_storage_map, sk, 0, BPF_LOCAL_STORAGE_GET_F_CREATE); if (!storage) return 0; diff --git a/tools/testing/selftests/bpf/progs/lsm_cgroup.c b/tools/testing/selftests/bpf/progs/lsm_cgroup.c index 02c11d16b692..d7598538aa2d 100644 --- a/tools/testing/selftests/bpf/progs/lsm_cgroup.c +++ b/tools/testing/selftests/bpf/progs/lsm_cgroup.c @@ -103,11 +103,15 @@ static __always_inline int real_bind(struct socket *sock, int addrlen) { struct sockaddr_ll sa = {}; + struct sock *sk = sock->sk; - if (sock->sk->__sk_common.skc_family != AF_PACKET) + if (!sk) + return 1; + + if (sk->__sk_common.skc_family != AF_PACKET) return 1; - if (sock->sk->sk_kern_sock) + if (sk->sk_kern_sock) return 1; bpf_probe_read_kernel(&sa, sizeof(sa), address); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
by Tengda Wu 26 Jun '24

26 Jun '24

mainline inclusion from mainline-v6.10-rc1 commit 543576ec15b17c0c93301ac8297333c7b6e84ac7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S6Q CVE: CVE-2024-38564 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association. Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks. Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment") Link: https://lore.kernel.org/bpf/0000000000004792a90615a1dde0@google.com/ Reported-by: syzbot+838346b979830606c854(a)syzkaller.appspotmail.com Signed-off-by: Stanislav Fomichev <sdf(a)google.com> Acked-by: Eduard Zingerman <eddyz87(a)gmail.com> Link: https://lore.kernel.org/r/20240426231621.2716876-2-sdf@google.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Conflicts: kernel/bpf/syscall.c [Although this mainline patch itself has no conflicts, due to the lack of ptype and attach_type_to_prog_type declarations which comes from unnecessary commit db8eae6bc5c7 and 3505cb9fa26c, we fix it manually] Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/bpf/syscall.c | 53 +++++++++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 23 deletions(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index 6c8122ae938f..da8154c4706c 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -2945,29 +2945,6 @@ static int bpf_raw_tracepoint_open(const union bpf_attr *attr) return err; } -static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog, - enum bpf_attach_type attach_type) -{ - switch (prog->type) { - case BPF_PROG_TYPE_CGROUP_SOCK: - case BPF_PROG_TYPE_CGROUP_SOCK_ADDR: - case BPF_PROG_TYPE_CGROUP_SOCKOPT: - case BPF_PROG_TYPE_SK_LOOKUP: - return attach_type == prog->expected_attach_type ? 0 : -EINVAL; - case BPF_PROG_TYPE_CGROUP_SKB: - if (!capable(CAP_NET_ADMIN)) - /* cg-skb progs can be loaded by unpriv user. - * check permissions at attach time. - */ - return -EPERM; - return prog->enforce_expected_attach_type && - prog->expected_attach_type != attach_type ? - -EINVAL : 0; - default: - return 0; - } -} - static enum bpf_prog_type attach_type_to_prog_type(enum bpf_attach_type attach_type) { @@ -3022,6 +2999,36 @@ attach_type_to_prog_type(enum bpf_attach_type attach_type) } } +static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog, + enum bpf_attach_type attach_type) +{ + enum bpf_prog_type ptype; + + switch (prog->type) { + case BPF_PROG_TYPE_CGROUP_SOCK: + case BPF_PROG_TYPE_CGROUP_SOCK_ADDR: + case BPF_PROG_TYPE_CGROUP_SOCKOPT: + case BPF_PROG_TYPE_SK_LOOKUP: + return attach_type == prog->expected_attach_type ? 0 : -EINVAL; + case BPF_PROG_TYPE_CGROUP_SKB: + if (!capable(CAP_NET_ADMIN)) + /* cg-skb progs can be loaded by unpriv user. + * check permissions at attach time. + */ + return -EPERM; + + ptype = attach_type_to_prog_type(attach_type); + if (prog->type != ptype) + return -EINVAL; + + return prog->enforce_expected_attach_type && + prog->expected_attach_type != attach_type ? + -EINVAL : 0; + default: + return 0; + } +} + #define BPF_PROG_ATTACH_LAST_FIELD replace_bpf_fd #define BPF_F_ATTACH_MASK \ -- 2.34.1

2 1

[PATCH OLK-6.6] bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
by Tengda Wu 26 Jun '24

26 Jun '24

From: Stanislav Fomichev <sdf(a)google.com> mainline inclusion from mainline-v6.10-rc1 commit 543576ec15b17c0c93301ac8297333c7b6e84ac7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S6Q CVE: CVE-2024-38564 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association. Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks. Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment") Link: https://lore.kernel.org/bpf/0000000000004792a90615a1dde0@google.com/ Reported-by: syzbot+838346b979830606c854(a)syzkaller.appspotmail.com Signed-off-by: Stanislav Fomichev <sdf(a)google.com> Acked-by: Eduard Zingerman <eddyz87(a)gmail.com> Link: https://lore.kernel.org/r/20240426231621.2716876-2-sdf@google.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/bpf/syscall.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index a1c254037437..ade28c519165 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -3812,6 +3812,11 @@ static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog, * check permissions at attach time. */ return -EPERM; + + ptype = attach_type_to_prog_type(attach_type); + if (prog->type != ptype) + return -EINVAL; + return prog->enforce_expected_attach_type && prog->expected_attach_type != attach_type ? -EINVAL : 0; -- 2.34.1

2 1

[PATCH OLK-5.10] bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
by Tengda Wu 26 Jun '24

26 Jun '24

mainline inclusion from mainline-v6.10-rc1 commit 543576ec15b17c0c93301ac8297333c7b6e84ac7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S6Q CVE: CVE-2024-38564 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association. Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks. Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment") Link: https://lore.kernel.org/bpf/0000000000004792a90615a1dde0@google.com/ Reported-by: syzbot+838346b979830606c854(a)syzkaller.appspotmail.com Signed-off-by: Stanislav Fomichev <sdf(a)google.com> Acked-by: Eduard Zingerman <eddyz87(a)gmail.com> Link: https://lore.kernel.org/r/20240426231621.2716876-2-sdf@google.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Conflicts: kernel/bpf/syscall.c [Although this mainline patch itself has no conflicts, due to the lack of ptype and attach_type_to_prog_type declarations which comes from unnecessary commit db8eae6bc5c7 and 3505cb9fa26c, we fix it manually] Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/bpf/syscall.c | 53 +++++++++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 23 deletions(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index 7ccdb89b08c7..18cf6755c760 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -2948,29 +2948,6 @@ static int bpf_raw_tracepoint_open(const union bpf_attr *attr) return err; } -static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog, - enum bpf_attach_type attach_type) -{ - switch (prog->type) { - case BPF_PROG_TYPE_CGROUP_SOCK: - case BPF_PROG_TYPE_CGROUP_SOCK_ADDR: - case BPF_PROG_TYPE_CGROUP_SOCKOPT: - case BPF_PROG_TYPE_SK_LOOKUP: - return attach_type == prog->expected_attach_type ? 0 : -EINVAL; - case BPF_PROG_TYPE_CGROUP_SKB: - if (!capable(CAP_NET_ADMIN)) - /* cg-skb progs can be loaded by unpriv user. - * check permissions at attach time. - */ - return -EPERM; - return prog->enforce_expected_attach_type && - prog->expected_attach_type != attach_type ? - -EINVAL : 0; - default: - return 0; - } -} - static enum bpf_prog_type attach_type_to_prog_type(enum bpf_attach_type attach_type) { @@ -3032,6 +3009,36 @@ attach_type_to_prog_type(enum bpf_attach_type attach_type) } } +static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog, + enum bpf_attach_type attach_type) +{ + enum bpf_prog_type ptype; + + switch (prog->type) { + case BPF_PROG_TYPE_CGROUP_SOCK: + case BPF_PROG_TYPE_CGROUP_SOCK_ADDR: + case BPF_PROG_TYPE_CGROUP_SOCKOPT: + case BPF_PROG_TYPE_SK_LOOKUP: + return attach_type == prog->expected_attach_type ? 0 : -EINVAL; + case BPF_PROG_TYPE_CGROUP_SKB: + if (!capable(CAP_NET_ADMIN)) + /* cg-skb progs can be loaded by unpriv user. + * check permissions at attach time. + */ + return -EPERM; + + ptype = attach_type_to_prog_type(attach_type); + if (prog->type != ptype) + return -EINVAL; + + return prog->enforce_expected_attach_type && + prog->expected_attach_type != attach_type ? + -EINVAL : 0; + default: + return 0; + } +} + #define BPF_PROG_ATTACH_LAST_FIELD replace_bpf_fd #define BPF_F_ATTACH_MASK \ -- 2.34.1

2 1

[PATCH OLK-6.6] jffs2: prevent xattr node from overflowing the eraseblock
by Wang Zhaolong 26 Jun '24

26 Jun '24

From: Ilya Denisyev <dev(a)elkcl.ru> mainline inclusion from mainline-v6.10-rc1 commit c6854e5a267c28300ff045480b5a7ee7f6f1d913 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEU CVE: CVE-2024-38599 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker. Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as: jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead This breaks the filesystem and can lead to KASAN crashes such as: BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)") Signed-off-by: Ilya Denisyev <dev(a)elkcl.ru> Link: https://lore.kernel.org/r/20240412155357.237803-1-dev@elkcl.ru Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/jffs2/xattr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/jffs2/xattr.c b/fs/jffs2/xattr.c index 1e65b7b06c22..17ac0d088759 100644 --- a/fs/jffs2/xattr.c +++ b/fs/jffs2/xattr.c @@ -1150,6 +1150,9 @@ int do_jffs2_setxattr(struct inode *inode, int xprefix, const char *xname, return rc; request = PAD(sizeof(struct jffs2_raw_xattr) + strlen(xname) + 1 + size); + if (request > c->sector_size - c->cleanmarker_size) + return -ERANGE; + rc = jffs2_reserve_space(c, request, &length, ALLOC_NORMAL, JFFS2_SUMMARY_XATTR_SIZE); if (rc) { -- 2.34.3

2 1

[PATCH openEuler-22.03-LTS-SP1] jffs2: prevent xattr node from overflowing the eraseblock
by Wang Zhaolong 26 Jun '24

26 Jun '24

From: Ilya Denisyev <dev(a)elkcl.ru> mainline inclusion from mainline-v6.10-rc1 commit c6854e5a267c28300ff045480b5a7ee7f6f1d913 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEU CVE: CVE-2024-38599 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker. Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as: jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead This breaks the filesystem and can lead to KASAN crashes such as: BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)") Signed-off-by: Ilya Denisyev <dev(a)elkcl.ru> Link: https://lore.kernel.org/r/20240412155357.237803-1-dev@elkcl.ru Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/jffs2/xattr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/jffs2/xattr.c b/fs/jffs2/xattr.c index b2d6072f34af..b79ba11dfbe1 100644 --- a/fs/jffs2/xattr.c +++ b/fs/jffs2/xattr.c @@ -1146,6 +1146,9 @@ int do_jffs2_setxattr(struct inode *inode, int xprefix, const char *xname, return rc; request = PAD(sizeof(struct jffs2_raw_xattr) + strlen(xname) + 1 + size); + if (request > c->sector_size - c->cleanmarker_size) + return -ERANGE; + rc = jffs2_reserve_space(c, request, &length, ALLOC_NORMAL, JFFS2_SUMMARY_XATTR_SIZE); if (rc) { -- 2.34.3

2 1

[PATCH OLK-5.10] jffs2: prevent xattr node from overflowing the eraseblock
by Wang Zhaolong 26 Jun '24

26 Jun '24

From: Ilya Denisyev <dev(a)elkcl.ru> mainline inclusion from mainline-v6.10-rc1 commit c6854e5a267c28300ff045480b5a7ee7f6f1d913 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEU CVE: CVE-2024-38599 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker. Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as: jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead This breaks the filesystem and can lead to KASAN crashes such as: BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)") Signed-off-by: Ilya Denisyev <dev(a)elkcl.ru> Link: https://lore.kernel.org/r/20240412155357.237803-1-dev@elkcl.ru Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/jffs2/xattr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/jffs2/xattr.c b/fs/jffs2/xattr.c index eff9e410b058..0fedc3b8b8df 100644 --- a/fs/jffs2/xattr.c +++ b/fs/jffs2/xattr.c @@ -1151,6 +1151,9 @@ int do_jffs2_setxattr(struct inode *inode, int xprefix, const char *xname, return rc; request = PAD(sizeof(struct jffs2_raw_xattr) + strlen(xname) + 1 + size); + if (request > c->sector_size - c->cleanmarker_size) + return -ERANGE; + rc = jffs2_reserve_space(c, request, &length, ALLOC_NORMAL, JFFS2_SUMMARY_XATTR_SIZE); if (rc) { -- 2.34.3

2 1

[PATCH OLK-5.10 0/2] CVE-2024-27032
by Xiongfeng Wang 26 Jun '24

26 Jun '24

Jann Horn (1): fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected Li Nan (1): block: fix WARNING in init_blk_queue_async_dispatch -- 2.20.1

2 3

[PATCH openEuler-1.0-LTS] jffs2: prevent xattr node from overflowing the eraseblock
by Wang Zhaolong 26 Jun '24

26 Jun '24

From: Ilya Denisyev <dev(a)elkcl.ru> mainline inclusion from mainline-v6.10-rc1 commit c6854e5a267c28300ff045480b5a7ee7f6f1d913 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SEU CVE: CVE-2024-38599 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker. Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as: jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead This breaks the filesystem and can lead to KASAN crashes such as: BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)") Signed-off-by: Ilya Denisyev <dev(a)elkcl.ru> Link: https://lore.kernel.org/r/20240412155357.237803-1-dev@elkcl.ru Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/jffs2/xattr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/jffs2/xattr.c b/fs/jffs2/xattr.c index da3e18503c65..a239e5a538a5 100644 --- a/fs/jffs2/xattr.c +++ b/fs/jffs2/xattr.c @@ -1106,6 +1106,9 @@ int do_jffs2_setxattr(struct inode *inode, int xprefix, const char *xname, return rc; request = PAD(sizeof(struct jffs2_raw_xattr) + strlen(xname) + 1 + size); + if (request > c->sector_size - c->cleanmarker_size) + return -ERANGE; + rc = jffs2_reserve_space(c, request, &length, ALLOC_NORMAL, JFFS2_SUMMARY_XATTR_SIZE); if (rc) { -- 2.34.3

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-27032
by Xiongfeng Wang 26 Jun '24

26 Jun '24

Chao Yu (2): f2fs: fix to check return value of f2fs_reserve_new_block() f2fs: fix to avoid potential panic during recovery fs/f2fs/f2fs.h | 5 +++++ fs/f2fs/recovery.c | 26 ++++++++++++++++++-------- 2 files changed, 23 insertions(+), 8 deletions(-) -- 2.20.1

2 3

[PATCH openEuler-22.03-LTS-SP1] netfilter: nft_set_pipapo: .walk does not deal with generations
by Wang Hai 25 Jun '24

25 Jun '24

From: Pablo Neira Ayuso <pablo(a)netfilter.org> stable inclusion from stable-v5.10.186 commit 2a90da8e0dd50f42e577988f4219f4f4cd3616b7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5O8 CVE: CVE-2024-27017 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2b84e215f87443c74ac0aa7f76bb172d43a87033 ] The .walk callback iterates over the current active set, but it might be useful to iterate over the next generation set. Use the generation mask to determine what set view (either current or next generation) is use for the walk iteration. Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- net/netfilter/nft_set_pipapo.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/netfilter/nft_set_pipapo.c b/net/netfilter/nft_set_pipapo.c index 9ca18f4c4eaf..c3f16880f64b 100644 --- a/net/netfilter/nft_set_pipapo.c +++ b/net/netfilter/nft_set_pipapo.c @@ -1971,12 +1971,16 @@ static void nft_pipapo_walk(const struct nft_ctx *ctx, struct nft_set *set, struct nft_set_iter *iter) { struct nft_pipapo *priv = nft_set_priv(set); + struct net *net = read_pnet(&set->net); struct nft_pipapo_match *m; struct nft_pipapo_field *f; int i, r; rcu_read_lock(); - m = rcu_dereference(priv->match); + if (iter->genmask == nft_genmask_cur(net)) + m = rcu_dereference(priv->match); + else + m = priv->clone; if (unlikely(!m)) goto out; -- 2.17.1

2 1

[PATCH OLK-6.6] rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
by Yang Yingliang 25 Jun '24

25 Jun '24

From: Nikita Kiryushin <kiryushin(a)ancud.ru> mainline inclusion from mainline-v6.10-rc1 commit cc5645fddb0ce28492b15520306d092730dffa48 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGB CVE: CVE-2024-38577 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- There is a possibility of buffer overflow in show_rcu_tasks_trace_gp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible. Use snprintf() with buffer size instead of sprintf(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: edf3775f0ad6 ("rcu-tasks: Add count for idle tasks on offline CPUs") Signed-off-by: Nikita Kiryushin <kiryushin(a)ancud.ru> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org> Signed-off-by: Uladzislau Rezki (Sony) <urezki(a)gmail.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/rcu/tasks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 65e000ca332c..305e960c08ac 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1938,7 +1938,7 @@ void show_rcu_tasks_trace_gp_kthread(void) { char buf[64]; - sprintf(buf, "N%lu h:%lu/%lu/%lu", + snprintf(buf, sizeof(buf), "N%lu h:%lu/%lu/%lu", data_race(n_trc_holdouts), data_race(n_heavy_reader_ofl_updates), data_race(n_heavy_reader_updates), -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
by Yang Yingliang 25 Jun '24

25 Jun '24

From: Nikita Kiryushin <kiryushin(a)ancud.ru> mainline inclusion from mainline-v6.10-rc1 commit cc5645fddb0ce28492b15520306d092730dffa48 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGB CVE: CVE-2024-38577 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- There is a possibility of buffer overflow in show_rcu_tasks_trace_gp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible. Use snprintf() with buffer size instead of sprintf(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: edf3775f0ad6 ("rcu-tasks: Add count for idle tasks on offline CPUs") Signed-off-by: Nikita Kiryushin <kiryushin(a)ancud.ru> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org> Signed-off-by: Uladzislau Rezki (Sony) <urezki(a)gmail.com> Conflicts: kernel/rcu/tasks.h [yyl: adjust context] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/rcu/tasks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index c5624ab0580c..25d636c39efc 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1238,7 +1238,7 @@ static void show_rcu_tasks_trace_gp_kthread(void) { char buf[64]; - sprintf(buf, "N%d h:%lu/%lu/%lu", atomic_read(&trc_n_readers_need_end), + snprintf(buf, sizeof(buf), "N%d h:%lu/%lu/%lu", atomic_read(&trc_n_readers_need_end), data_race(n_heavy_reader_ofl_updates), data_race(n_heavy_reader_updates), data_race(n_heavy_reader_attempts)); -- 2.25.1

2 1

[PATCH OLK-5.10] rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
by Yang Yingliang 25 Jun '24

25 Jun '24

From: Nikita Kiryushin <kiryushin(a)ancud.ru> mainline inclusion from mainline-v6.10-rc1 commit cc5645fddb0ce28492b15520306d092730dffa48 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGB CVE: CVE-2024-38577 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- There is a possibility of buffer overflow in show_rcu_tasks_trace_gp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible. Use snprintf() with buffer size instead of sprintf(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: edf3775f0ad6 ("rcu-tasks: Add count for idle tasks on offline CPUs") Signed-off-by: Nikita Kiryushin <kiryushin(a)ancud.ru> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org> Signed-off-by: Uladzislau Rezki (Sony) <urezki(a)gmail.com> Conflicts: kernel/rcu/tasks.h [yyl: adjust context] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/rcu/tasks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index c5624ab0580c..25d636c39efc 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1238,7 +1238,7 @@ static void show_rcu_tasks_trace_gp_kthread(void) { char buf[64]; - sprintf(buf, "N%d h:%lu/%lu/%lu", atomic_read(&trc_n_readers_need_end), + snprintf(buf, sizeof(buf), "N%d h:%lu/%lu/%lu", atomic_read(&trc_n_readers_need_end), data_race(n_heavy_reader_ofl_updates), data_race(n_heavy_reader_updates), data_race(n_heavy_reader_attempts)); -- 2.25.1

2 1

[PATCH OLK-6.6] blk-cgroup: fix list corruption from resetting io stat
by Li Lingfeng 25 Jun '24

25 Jun '24

From: Ming Lei <ming.lei(a)redhat.com> mainline inclusion from mainline-v6.10-rc1 commit 6da6680632792709cecf2b006f2fe3ca7857e791 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YJP CVE: CVE-2024-38663 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/… -------------------------------- Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part. Cc: Tejun Heo <tj(a)kernel.org> Cc: Waiman Long <longman(a)redhat.com> Cc: Jay Shin <jaeshin(a)redhat.com> Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Acked-by: Tejun Heo <tj(a)kernel.org> Reviewed-by: Waiman Long <longman(a)redhat.com> Link: https://lore.kernel.org/r/20240515013157.443672-2-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- block/blk-cgroup.c | 58 ++++++++++++++++++++++++++++------------------ 1 file changed, 35 insertions(+), 23 deletions(-) diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c index 9c29eff62e3f..94ad38fa5c74 100644 --- a/block/blk-cgroup.c +++ b/block/blk-cgroup.c @@ -619,12 +619,45 @@ static void blkg_destroy_all(struct gendisk *disk) spin_unlock_irq(&q->queue_lock); } +static void blkg_iostat_set(struct blkg_iostat *dst, struct blkg_iostat *src) +{ + int i; + + for (i = 0; i < BLKG_IOSTAT_NR; i++) { + dst->bytes[i] = src->bytes[i]; + dst->ios[i] = src->ios[i]; + } +} + +static void __blkg_clear_stat(struct blkg_iostat_set *bis) +{ + struct blkg_iostat cur = {0}; + unsigned long flags; + + flags = u64_stats_update_begin_irqsave(&bis->sync); + blkg_iostat_set(&bis->cur, &cur); + blkg_iostat_set(&bis->last, &cur); + u64_stats_update_end_irqrestore(&bis->sync, flags); +} + +static void blkg_clear_stat(struct blkcg_gq *blkg) +{ + int cpu; + + for_each_possible_cpu(cpu) { + struct blkg_iostat_set *s = per_cpu_ptr(blkg->iostat_cpu, cpu); + + __blkg_clear_stat(s); + } + __blkg_clear_stat(&blkg->iostat); +} + static int blkcg_reset_stats(struct cgroup_subsys_state *css, struct cftype *cftype, u64 val) { struct blkcg *blkcg = css_to_blkcg(css); struct blkcg_gq *blkg; - int i, cpu; + int i; mutex_lock(&blkcg_pol_mutex); spin_lock_irq(&blkcg->lock); @@ -635,18 +668,7 @@ static int blkcg_reset_stats(struct cgroup_subsys_state *css, * anyway. If you get hit by a race, retry. */ hlist_for_each_entry(blkg, &blkcg->blkg_list, blkcg_node) { - for_each_possible_cpu(cpu) { - struct blkg_iostat_set *bis = - per_cpu_ptr(blkg->iostat_cpu, cpu); - memset(bis, 0, sizeof(*bis)); - - /* Re-initialize the cleared blkg_iostat_set */ - u64_stats_init(&bis->sync); - bis->blkg = blkg; - } - memset(&blkg->iostat, 0, sizeof(blkg->iostat)); - u64_stats_init(&blkg->iostat.sync); - + blkg_clear_stat(blkg); for (i = 0; i < BLKCG_MAX_POLS; i++) { struct blkcg_policy *pol = blkcg_policy[i]; @@ -949,16 +971,6 @@ void blkg_conf_exit(struct blkg_conf_ctx *ctx) } EXPORT_SYMBOL_GPL(blkg_conf_exit); -static void blkg_iostat_set(struct blkg_iostat *dst, struct blkg_iostat *src) -{ - int i; - - for (i = 0; i < BLKG_IOSTAT_NR; i++) { - dst->bytes[i] = src->bytes[i]; - dst->ios[i] = src->ios[i]; - } -} - static void blkg_iostat_add(struct blkg_iostat *dst, struct blkg_iostat *src) { int i; -- 2.31.1

2 1

[PATCH OLK-6.6] blk-cgroup: fix list corruption from reorder of WRITE ->lqueued
by Li Lingfeng 25 Jun '24

25 Jun '24

From: Ming Lei <ming.lei(a)redhat.com> mainline inclusion from mainline-v6.10-rc1 commit d0aac2363549e12cc79b8e285f13d5a9f42fd08e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7YKI CVE: CVE-2024-38384 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/… -------------------------------- __blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start is being executed. If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one stat instance being added in blk_cgroup_bio_start(), then the local list in __blkcg_rstat_flush() could be corrupted. Fix the issue by adding one barrier. Cc: Tejun Heo <tj(a)kernel.org> Cc: Waiman Long <longman(a)redhat.com> Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Link: https://lore.kernel.org/r/20240515013157.443672-3-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- block/blk-cgroup.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c index 9c29eff62e3f..7b4d0066ed1c 100644 --- a/block/blk-cgroup.c +++ b/block/blk-cgroup.c @@ -1024,6 +1024,16 @@ static void __blkcg_rstat_flush(struct blkcg *blkcg, int cpu) struct blkg_iostat cur; unsigned int seq; + /* + * Order assignment of `next_bisc` from `bisc->lnode.next` in + * llist_for_each_entry_safe and clearing `bisc->lqueued` for + * avoiding to assign `next_bisc` with new next pointer added + * in blk_cgroup_bio_start() in case of re-ordering. + * + * The pair barrier is implied in llist_add() in blk_cgroup_bio_start(). + */ + smp_mb(); + WRITE_ONCE(bisc->lqueued, false); /* fetch the current per-cpu values */ -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2022-48737
by GONG, Ruiqi 25 Jun '24

25 Jun '24

Fix of CVE-2022-48737. Mark Brown (2): ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx() ASoC: ops: Fix bounds check for _sx controls sound/soc/soc-ops.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) -- 2.25.1

2 3

[openEuler-22.03-LTS-SP1 0/2] CVE-2024-27032
by Xiongfeng Wang 25 Jun '24

25 Jun '24

Chao Yu (2): f2fs: fix to check return value of f2fs_reserve_new_block() f2fs: fix to avoid potential panic during recovery fs/f2fs/f2fs.h | 5 +++++ fs/f2fs/recovery.c | 26 ++++++++++++++++++-------- 2 files changed, 23 insertions(+), 8 deletions(-) -- 2.20.1

1 2

[OLK-5.10 0/2] CVE-2024-27032
by Xiongfeng Wang 25 Jun '24

25 Jun '24

Chao Yu (2): f2fs: fix to check return value of f2fs_reserve_new_block() f2fs: fix to avoid potential panic during recovery fs/f2fs/f2fs.h | 5 +++++ fs/f2fs/recovery.c | 26 ++++++++++++++++++-------- 2 files changed, 23 insertions(+), 8 deletions(-) -- 2.20.1

1 0

[PATCH openEuler-22.03-LTS-SP1] net/mlx5: Discard command completions in internal error
by Zhengchao Shao 25 Jun '24

25 Jun '24

From: Akiva Goldberger <agoldberger(a)nvidia.com> stable inclusion from stable-v5.10.219 commit f6fbb8535e990f844371086ab2c1221f71f993d3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SA3 CVE: CVE-2024-38555 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit db9b31aa9bc56ff0d15b78f7e827d61c4a096e40 ] Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually. Kernel log: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Call Trace: <IRQ> ? __warn+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0xa0 common_interrupt+0x7b/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 Fixes: 51d138c2610a ("net/mlx5: Fix health error state handling") Signed-off-by: Akiva Goldberger <agoldberger(a)nvidia.com> Reviewed-by: Moshe Shemesh <moshe(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Link: https://lore.kernel.org/r/20240509112951.590184-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c index 56a4729cb903..fb196d312548 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c @@ -1521,6 +1521,9 @@ static int cmd_comp_notifier(struct notifier_block *nb, dev = container_of(cmd, struct mlx5_core_dev, cmd); eqe = data; + if (dev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) + return NOTIFY_DONE; + mlx5_cmd_comp_handler(dev, be32_to_cpu(eqe->data.cmd.vector), false); return NOTIFY_OK; -- 2.34.1

2 1

[PATCH OLK-5.10] net/mlx5: Discard command completions in internal error
by Zhengchao Shao 25 Jun '24

25 Jun '24

From: Akiva Goldberger <agoldberger(a)nvidia.com> stable inclusion from stable-v5.10.219 commit f6fbb8535e990f844371086ab2c1221f71f993d3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SA3 CVE: CVE-2024-38555 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit db9b31aa9bc56ff0d15b78f7e827d61c4a096e40 ] Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually. Kernel log: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Call Trace: <IRQ> ? __warn+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0xa0 common_interrupt+0x7b/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 Fixes: 51d138c2610a ("net/mlx5: Fix health error state handling") Signed-off-by: Akiva Goldberger <agoldberger(a)nvidia.com> Reviewed-by: Moshe Shemesh <moshe(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Link: https://lore.kernel.org/r/20240509112951.590184-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c index bb1dba03de7c..e5f805c3935e 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c @@ -1521,6 +1521,9 @@ static int cmd_comp_notifier(struct notifier_block *nb, dev = container_of(cmd, struct mlx5_core_dev, cmd); eqe = data; + if (dev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) + return NOTIFY_DONE; + mlx5_cmd_comp_handler(dev, be32_to_cpu(eqe->data.cmd.vector), false); return NOTIFY_OK; -- 2.34.1

2 1

[PATCH OLK-5.10 0/1] fix CVE-2024-38621
by Liao Chen 25 Jun '24

25 Jun '24

media: stk1160: fix bounds checking in stk1160_copy_video() Dan Carpenter (1): media: stk1160: fix bounds checking in stk1160_copy_video() drivers/media/usb/stk1160/stk1160-video.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS 0/1] CVE-2022-48715
by Chen Ridong 25 Jun '24

25 Jun '24

*** BLURB HERE *** John Meneghini (1): scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) -- 2.34.1

2 2

[PATCH v2 OLK-6.6] ASoC: mediatek: Assign dummy when codec not specified for a DAI link
by liwei 25 Jun '24

25 Jun '24

From: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> mainline inclusion from mainline-v6.10-rc1 commit 5f39231888c63f0a7708abc86b51b847476379d8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SG2 CVE: CVE-2024-38551 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- MediaTek sound card drivers are checking whether a DAI link is present and used on a board to assign the correct parameters and this is done by checking the codec DAI names at probe time. If no real codec is present, assign the dummy codec to the DAI link to avoid NULL pointer during string comparison. Fixes: 4302187d955f ("ASoC: mediatek: common: add soundcard driver common code") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Link: https://msgid.link/r/20240313110147.1267793-5-angelogioacchino.delregno@col… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- sound/soc/mediatek/common/mtk-soundcard-driver.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/mediatek/common/mtk-soundcard-driver.c b/sound/soc/mediatek/common/mtk-soundcard-driver.c index a58e1e3674de..000a086a8cf4 100644 --- a/sound/soc/mediatek/common/mtk-soundcard-driver.c +++ b/sound/soc/mediatek/common/mtk-soundcard-driver.c @@ -22,7 +22,11 @@ static int set_card_codec_info(struct snd_soc_card *card, codec_node = of_get_child_by_name(sub_node, "codec"); if (!codec_node) { - dev_dbg(dev, "%s no specified codec\n", dai_link->name); + dev_dbg(dev, "%s no specified codec: setting dummy.\n", dai_link->name); + + dai_link->codecs = &snd_soc_dummy_dlc; + dai_link->num_codecs = 1; + dai_link->dynamic = 1; return 0; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/1] fix CVE-2024-38621
by Liao Chen 25 Jun '24

25 Jun '24

media: stk1160: fix bounds checking in stk1160_copy_video() Dan Carpenter (1): media: stk1160: fix bounds checking in stk1160_copy_video() drivers/media/usb/stk1160/stk1160-video.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) -- 2.34.1

2 2

[PATCH OLK-5.10] cvm: delete dead code and resolve macro definition holes
by Ju Fu 25 Jun '24

25 Jun '24

virtcca inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I9TM0T -------------------------------- delete dead code and resolve macro definition holes Signed-off-by: Ju Fu <fuju1(a)huawei.com> --- arch/arm64/include/asm/kvm_tmi.h | 34 ++++++++++---------------------- arch/arm64/kvm/cvm.c | 1 - arch/arm64/kvm/tmi.c | 26 +----------------------- 3 files changed, 11 insertions(+), 50 deletions(-) diff --git a/arch/arm64/include/asm/kvm_tmi.h b/arch/arm64/include/asm/kvm_tmi.h index b89680f31..eef64936f 100644 --- a/arch/arm64/include/asm/kvm_tmi.h +++ b/arch/arm64/include/asm/kvm_tmi.h @@ -206,28 +206,24 @@ struct tmi_tec_run { * always invoked by the Normal world, forward by SPMD and handled by the * TMM. */ -#define TMI_FNUM_VERSION U(0x260) +#define TMI_FNUM_VERSION_REQ U(0x260) #define TMI_FNUM_MEM_INFO_SHOW U(0x261) #define TMI_FNUM_DATA_CREATE U(0x262) #define TMI_FNUM_DATA_DESTROY U(0x263) #define TMI_FNUM_CVM_ACTIVATE U(0x264) #define TMI_FNUM_CVM_CREATE U(0x265) #define TMI_FNUM_CVM_DESTROY U(0x266) -#define TMI_FNUM_TEC_CREATE U(0x27A) -#define TMI_FNUM_TEC_DESTROY U(0x27B) -#define TMI_FNUM_TEC_ENTER U(0x27C) -#define TMI_FNUM_TTT_CREATE U(0x27D) -#define TMI_FNUM_TTT_MAP_UNPROTECTED U(0x27F) -#define TMI_FNUM_TTT_MAP_PROTECTED U(0x280) -#define TMI_FNUM_TTT_UNMAP_UNPROTECTED U(0x282) -#define TMI_FNUM_TTT_UNMAP_PROTECTED U(0x283) -#define TMI_FNUM_PSCI_COMPLETE U(0x284) -#define TMI_FNUM_FEATURES U(0x285) -#define TMI_FNUM_TTT_MAP_RANGE U(0x286) -#define TMI_FNUM_TTT_UNMAP_RANGE U(0x287) +#define TMI_FNUM_TEC_CREATE U(0x267) +#define TMI_FNUM_TEC_DESTROY U(0x268) +#define TMI_FNUM_TEC_ENTER U(0x269) +#define TMI_FNUM_TTT_CREATE U(0x26A) +#define TMI_FNUM_PSCI_COMPLETE U(0x26B) +#define TMI_FNUM_FEATURES U(0x26C) +#define TMI_FNUM_TTT_MAP_RANGE U(0x26D) +#define TMI_FNUM_TTT_UNMAP_RANGE U(0x26E) /* TMI SMC64 PIDs handled by the SPMD */ -#define TMI_TMM_VESION TMI_FID(SMC_64, TMI_FNUM_VERSION) +#define TMI_TMM_VERSION_REQ TMI_FID(SMC_64, TMI_FNUM_VERSION_REQ) #define TMI_TMM_DATA_CREATE TMI_FID(SMC_64, TMI_FNUM_DATA_CREATE) #define TMI_TMM_DATA_DESTROY TMI_FID(SMC_64, TMI_FNUM_DATA_DESTROY) #define TMI_TMM_CVM_ACTIVATE TMI_FID(SMC_64, TMI_FNUM_CVM_ACTIVATE) @@ -237,10 +233,6 @@ struct tmi_tec_run { #define TMI_TMM_TEC_DESTROY TMI_FID(SMC_64, TMI_FNUM_TEC_DESTROY) #define TMI_TMM_TEC_ENTER TMI_FID(SMC_64, TMI_FNUM_TEC_ENTER) #define TMI_TMM_TTT_CREATE TMI_FID(SMC_64, TMI_FNUM_TTT_CREATE) -#define TMI_TMM_TTT_MAP_UNPROTECTED TMI_FID(SMC_64, TMI_FNUM_TTT_MAP_UNPROTECTED) -#define TMI_TMM_TTT_MAP_PROTECTED TMI_FID(SMC_64, TMI_FNUM_TTT_MAP_PROTECTED) -#define TMI_TMM_TTT_UNMAP_UNPROTECTED TMI_FID(SMC_64, TMI_FNUM_TTT_UNMAP_UNPROTECTED) -#define TMI_TMM_TTT_UNMAP_PROTECTED TMI_FID(SMC_64, TMI_FNUM_TTT_UNMAP_PROTECTED) #define TMI_TMM_PSCI_COMPLETE TMI_FID(SMC_64, TMI_FNUM_PSCI_COMPLETE) #define TMI_TMM_FEATURES TMI_FID(SMC_64, TMI_FNUM_FEATURES) #define TMI_TMM_MEM_INFO_SHOW TMI_FID(SMC_64, TMI_FNUM_MEM_INFO_SHOW) @@ -331,8 +323,6 @@ static inline bool is_armv8_4_sel2_present(void) ID_AA64PFR0_SEL2_MASK) == 1UL; } -u64 phys_to_cvm_phys(u64 phys); - u64 tmi_version(void); u64 tmi_data_create(u64 data, u64 rd, u64 map_addr, u64 src, u64 level); u64 tmi_data_destroy(u64 rd, u64 map_addr, u64 level); @@ -343,14 +333,10 @@ u64 tmi_tec_create(u64 numa_set, u64 rd, u64 mpidr, u64 params_ptr); u64 tmi_tec_destroy(u64 tec); u64 tmi_tec_enter(u64 tec, u64 run_ptr); u64 tmi_ttt_create(u64 numa_set, u64 rd, u64 map_addr, u64 level); -u64 tmi_ttt_map_unprotected(u64 rd, u64 map_addr, u64 level, u64 ttte); -u64 tmi_ttt_unmap_unprotected(u64 rd, u64 map_addr, u64 level, u64 ns); -u64 tmi_ttt_unmap_protected(u64 rd, u64 map_addr, u64 level); u64 tmi_psci_complete(u64 calling_tec, u64 target_tec); u64 tmi_features(u64 index); u64 tmi_ttt_map_range(u64 rd, u64 map_addr, u64 size, u64 cur_node, u64 target_node); u64 tmi_ttt_unmap_range(u64 rd, u64 map_addr, u64 size, u64 node_id); - u64 tmi_mem_info_show(u64 mem_info_addr); void kvm_cvm_vcpu_put(struct kvm_vcpu *vcpu); diff --git a/arch/arm64/kvm/cvm.c b/arch/arm64/kvm/cvm.c index 73b8daede..08fad30d1 100644 --- a/arch/arm64/kvm/cvm.c +++ b/arch/arm64/kvm/cvm.c @@ -171,7 +171,6 @@ int kvm_arm_create_cvm(struct kvm *kvm) pgd_sz = kvm_pgd_pages(pgt->ia_bits, pgt->start_level); - cvm->params->measurement_algo = 0; cvm->params->ttt_level_start = kvm->arch.mmu.pgt->start_level; cvm->params->ttt_num_start = pgd_sz; cvm->params->s2sz = VTCR_EL2_IPA(kvm->arch.vtcr); diff --git a/arch/arm64/kvm/tmi.c b/arch/arm64/kvm/tmi.c index 1fcf1a8cc..888f1a4a2 100644 --- a/arch/arm64/kvm/tmi.c +++ b/arch/arm64/kvm/tmi.c @@ -10,7 +10,7 @@ u64 tmi_version(void) { struct arm_smccc_res res; - arm_smccc_1_1_smc(TMI_TMM_VESION, &res); + arm_smccc_1_1_smc(TMI_TMM_VERSION_REQ, &res); return res.a1; } @@ -86,30 +86,6 @@ u64 tmi_ttt_create(u64 numa_set, u64 rd, u64 map_addr, u64 level) return res.a1; } -u64 tmi_ttt_map_unprotected(u64 rd, u64 map_addr, u64 level, u64 ttte) -{ - struct arm_smccc_res res; - - arm_smccc_1_1_smc(TMI_TMM_TTT_MAP_UNPROTECTED, rd, map_addr, level, ttte, &res); - return res.a1; -} - -u64 tmi_ttt_unmap_unprotected(u64 rd, u64 map_addr, u64 level, u64 ns) -{ - struct arm_smccc_res res; - - arm_smccc_1_1_smc(TMI_TMM_TTT_UNMAP_UNPROTECTED, rd, map_addr, level, ns, &res); - return res.a1; -} - -u64 tmi_ttt_unmap_protected(u64 rd, u64 map_addr, u64 level) -{ - struct arm_smccc_res res; - - arm_smccc_1_1_smc(TMI_TMM_TTT_UNMAP_PROTECTED, rd, map_addr, level, &res); - return res.a1; -} - u64 tmi_psci_complete(u64 calling_tec, u64 target_tec) { struct arm_smccc_res res; -- 2.25.1.windows.1

2 1

[PATCH OLK-6.6] ASoC: mediatek: Assign dummy when codec not specified for a DAI link
by liwei 25 Jun '24

25 Jun '24

From: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> mainline inclusion from mainline-v6.10-rc1 commit 5f39231888c63f0a7708abc86b51b847476379d8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SG2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- MediaTek sound card drivers are checking whether a DAI link is present and used on a board to assign the correct parameters and this is done by checking the codec DAI names at probe time. If no real codec is present, assign the dummy codec to the DAI link to avoid NULL pointer during string comparison. Fixes: 4302187d955f ("ASoC: mediatek: common: add soundcard driver common code") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Link: https://msgid.link/r/20240313110147.1267793-5-angelogioacchino.delregno@col… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- sound/soc/mediatek/common/mtk-soundcard-driver.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/mediatek/common/mtk-soundcard-driver.c b/sound/soc/mediatek/common/mtk-soundcard-driver.c index a58e1e3674de..000a086a8cf4 100644 --- a/sound/soc/mediatek/common/mtk-soundcard-driver.c +++ b/sound/soc/mediatek/common/mtk-soundcard-driver.c @@ -22,7 +22,11 @@ static int set_card_codec_info(struct snd_soc_card *card, codec_node = of_get_child_by_name(sub_node, "codec"); if (!codec_node) { - dev_dbg(dev, "%s no specified codec\n", dai_link->name); + dev_dbg(dev, "%s no specified codec: setting dummy.\n", dai_link->name); + + dai_link->codecs = &snd_soc_dummy_dlc; + dai_link->num_codecs = 1; + dai_link->dynamic = 1; return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] hid: cp2112: Fix duplicate workqueue initialization
by Yuan Can 25 Jun '24

25 Jun '24

From: Danny Kaehn <danny.kaehn(a)plexus.com> stable inclusion from stable-v5.15.139 commit df0daac2709473531d6a3472997cc65301ac06d6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RFR6 CVE: CVE-2023-52853 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c. Initialize the workqueue within _probe instead. Fixes: 13de9cca514e ("HID: cp2112: add IRQ chip handling") Signed-off-by: Danny Kaehn <danny.kaehn(a)plexus.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Conflicts: drivers/hid/hid-cp2112.c [Fix context] Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- drivers/hid/hid-cp2112.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c index 172f20e88c6c..966504eea1bc 100644 --- a/drivers/hid/hid-cp2112.c +++ b/drivers/hid/hid-cp2112.c @@ -1157,8 +1157,6 @@ static unsigned int cp2112_gpio_irq_startup(struct irq_data *d) struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct cp2112_device *dev = gpiochip_get_data(gc); - INIT_DELAYED_WORK(&dev->gpio_poll_worker, cp2112_gpio_poll_callback); - if (!dev->gpio_poll) { dev->gpio_poll = true; schedule_delayed_work(&dev->gpio_poll_worker, 0); @@ -1353,6 +1351,8 @@ static int cp2112_probe(struct hid_device *hdev, const struct hid_device_id *id) girq->default_type = IRQ_TYPE_NONE; girq->handler = handle_simple_irq; + INIT_DELAYED_WORK(&dev->gpio_poll_worker, cp2112_gpio_poll_callback); + ret = gpiochip_add_data(&dev->gc, dev); if (ret < 0) { hid_err(hdev, "error registering gpio chip\n"); -- 2.17.1

2 1

[OLK-6.6] RDMA/hns: Fix some mutex UAF
by Chengchang Tang 25 Jun '24

25 Jun '24

From: wenglianfa <wenglianfa(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA5Z6R ---------------------------------------------------------------------- umem_unfree_list_mutex and mtr_unfree_list_mutex may be used after being destroyed. To fix it, The mutex is destroyed after it is used for the last time. Fixes: a91843046b2a ("RDMA/hns: Fix sleeping in spin_lock critical section") Signed-off-by: wenglianfa <wenglianfa(a)huawei.com> Signed-off-by: Guofeng Yue <yueguofeng(a)h-partners.com> --- drivers/infiniband/hw/hns/hns_roce_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c b/drivers/infiniband/hw/hns/hns_roce_main.c index 424dcf69d3b8..3628dbb250ab 100644 --- a/drivers/infiniband/hw/hns/hns_roce_main.c +++ b/drivers/infiniband/hw/hns/hns_roce_main.c @@ -1503,9 +1503,9 @@ void hns_roce_exit(struct hns_roce_dev *hr_dev, bool bond_cleanup) if (hr_dev->hw->hw_exit) hr_dev->hw->hw_exit(hr_dev); - hns_roce_teardown_hca(hr_dev); hns_roce_free_unfree_umem(hr_dev); hns_roce_free_unfree_mtr(hr_dev); + hns_roce_teardown_hca(hr_dev); hns_roce_cleanup_hem(hr_dev); if (hr_dev->cmd_mod) -- 2.33.0

1 0

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2022-48703
by Pu Lehui 25 Jun '24

25 Jun '24

Lee, Chun-Yi (1): thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR Rafael J. Wysocki (1): thermal: int340x_thermal: Consolidate priv->data_vault checks drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10 0/2] CVE-2022-48703
by Pu Lehui 25 Jun '24

25 Jun '24

Lee, Chun-Yi (1): thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR Rafael J. Wysocki (1): thermal: int340x_thermal: Consolidate priv->data_vault checks drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 3

[PATCH OLK-5.10] usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
by Guo Mengqi 25 Jun '24

25 Jun '24

From: Krishna Kurapati <quic_kriskura(a)quicinc.com> stable inclusion from stable-v5.10.211 commit 57ca0e16f393bb21d69734e536e383a3a4c665fd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q8M7 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 76c51146820c5dac629f21deafab0a7039bc3ccd upstream. It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list. Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy shows one byte coming in extra confirming that the byte is coming in from PC: Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722) According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize. Cc: <stable(a)vger.kernel.org> Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added") Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> Reviewed-by: Maciej Żenczykowski <maze(a)google.com> Link: https://lore.kernel.org/r/20240205074650.200304-1-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/usb/gadget/function/f_ncm.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c index d1e36941c924..e3b89b7c1d67 100644 --- a/drivers/usb/gadget/function/f_ncm.c +++ b/drivers/usb/gadget/function/f_ncm.c @@ -1349,7 +1349,15 @@ static int ncm_unwrap_ntb(struct gether *port, "Parsed NTB with %d frames\n", dgram_counter); to_process -= block_len; - if (to_process != 0) { + + /* + * Windows NCM driver avoids USB ZLPs by adding a 1-byte + * zero pad as needed. + */ + if (to_process == 1 && + (*(unsigned char *)(ntb_ptr + block_len) == 0x00)) { + to_process--; + } else if (to_process > 0) { ntb_ptr = (unsigned char *)(ntb_ptr + block_len); goto parse_ntb; } -- 2.17.1

2 1

[PATCH OLK-5.10] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected
by Guo Mengqi 25 Jun '24

25 Jun '24

From: Jann Horn <jannh(a)google.com> mainline inclusion from mainline-v6.3-rc1 commit 47d586913f2abec4d240bae33417f537fda987ec category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/IA5PIS CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Currently, filp_close() and generic_shutdown_super() use printk() to log messages when bugs are detected. This is problematic because infrastructure like syzkaller has no idea that this message indicates a bug. In addition, some people explicitly want their kernels to BUG() when kernel data corruption has been detected (CONFIG_BUG_ON_DATA_CORRUPTION). And finally, when generic_shutdown_super() detects remaining inodes on a system without CONFIG_BUG_ON_DATA_CORRUPTION, it would be nice if later accesses to a busy inode would at least crash somewhat cleanly rather than walking through freed memory. To address all three, use CHECK_DATA_CORRUPTION() when kernel bugs are detected. Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Christian Brauner (Microsoft) <brauner(a)kernel.org> Reviewed-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Christian Brauner (Microsoft) <brauner(a)kernel.org> Conflicts: include/linux/poison.h Signed-off-by: liwei <liwei728(a)huawei.com> --- fs/open.c | 5 +++-- fs/super.c | 21 +++++++++++++++++---- include/linux/poison.h | 3 +++ 3 files changed, 23 insertions(+), 6 deletions(-) diff --git a/fs/open.c b/fs/open.c index 8092178ceab0..926fd0598935 100644 --- a/fs/open.c +++ b/fs/open.c @@ -1285,8 +1285,9 @@ int filp_close(struct file *filp, fl_owner_t id) { int retval = 0; - if (!file_count(filp)) { - printk(KERN_ERR "VFS: Close: file count is 0\n"); + if (CHECK_DATA_CORRUPTION(file_count(filp) == 0, + "VFS: Close: file count is 0 (f_op=%ps)", + filp->f_op)) { return 0; } diff --git a/fs/super.c b/fs/super.c index db6345634f8b..db46a20da0c8 100644 --- a/fs/super.c +++ b/fs/super.c @@ -465,10 +465,23 @@ void generic_shutdown_super(struct super_block *sb) if (sop->put_super) sop->put_super(sb); - if (!list_empty(&sb->s_inodes)) { - printk("VFS: Busy inodes after unmount of %s. " - "Self-destruct in 5 seconds. Have a nice day...\n", - sb->s_id); + if (CHECK_DATA_CORRUPTION(!list_empty(&sb->s_inodes), + "VFS: Busy inodes after unmount of %s (%s)", + sb->s_id, sb->s_type->name)) { + /* + * Adding a proper bailout path here would be hard, but + * we can at least make it more likely that a later + * iput_final() or such crashes cleanly. + */ + struct inode *inode; + + spin_lock(&sb->s_inode_list_lock); + list_for_each_entry(inode, &sb->s_inodes, i_sb_list) { + inode->i_op = VFS_PTR_POISON; + inode->i_sb = VFS_PTR_POISON; + inode->i_mapping = VFS_PTR_POISON; + } + spin_unlock(&sb->s_inode_list_lock); } } spin_lock(&sb_lock); diff --git a/include/linux/poison.h b/include/linux/poison.h index 028133fb1405..a33190e56035 100644 --- a/include/linux/poison.h +++ b/include/linux/poison.h @@ -85,4 +85,7 @@ /********** net/core/page_pool.c **********/ #define PP_SIGNATURE (0x40 + POISON_POINTER_DELTA) +/********** VFS **********/ +#define VFS_PTR_POISON ((void *)(0xF5 + POISON_POINTER_DELTA)) + #endif -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] RDMA/hns: Fix deadlock on SRQ async events.
by Guo Mengqi 25 Jun '24

25 Jun '24

From: Chengchang Tang <tangchengchang(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit b46494b6f9c19f141114a57729e198698f40af37 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SF1 CVE: CVE-2024-38591 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock. Fixes: 81fce6291d99 ("RDMA/hns: Add SRQ asynchronous event support") Signed-off-by: Chengchang Tang <tangchengchang(a)huawei.com> Signed-off-by: Junxian Huang <huangjunxian6(a)hisilicon.com> Link: https://lore.kernel.org/r/20240412091616.370789-5-huangjunxian6@hisilicon.c… Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Conflicts: drivers/infiniband/hw/hns/hns_roce_main.c [The conflict occurs because the commit e4df3a25f0fa("[Backport] RDMA/hns: support RoCE bonding") has been merged. It contains hnae3.h] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/infiniband/hw/hns/hns_roce_srq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_srq.c b/drivers/infiniband/hw/hns/hns_roce_srq.c index 727c7a134102..a3999fc69719 100644 --- a/drivers/infiniband/hw/hns/hns_roce_srq.c +++ b/drivers/infiniband/hw/hns/hns_roce_srq.c @@ -122,7 +122,7 @@ static int alloc_srqc(struct hns_roce_dev *hr_dev, struct hns_roce_srq *srq) return ret; } - ret = xa_err(xa_store(&srq_table->xa, srq->srqn, srq, GFP_KERNEL)); + ret = xa_err(xa_store_irq(&srq_table->xa, srq->srqn, srq, GFP_KERNEL)); if (ret) { ibdev_err(ibdev, "failed to store SRQC, ret = %d.\n", ret); goto err_put; @@ -135,7 +135,7 @@ static int alloc_srqc(struct hns_roce_dev *hr_dev, struct hns_roce_srq *srq) return 0; err_xa: - xa_erase(&srq_table->xa, srq->srqn); + xa_erase_irq(&srq_table->xa, srq->srqn); err_put: hns_roce_table_put(hr_dev, &srq_table->table, srq->srqn); @@ -153,7 +153,7 @@ static void free_srqc(struct hns_roce_dev *hr_dev, struct hns_roce_srq *srq) dev_err(hr_dev->dev, "DESTROY_SRQ failed (%d) for SRQN %06lx\n", ret, srq->srqn); - xa_erase(&srq_table->xa, srq->srqn); + xa_erase_irq(&srq_table->xa, srq->srqn); if (refcount_dec_and_test(&srq->refcount)) complete(&srq->free); -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS 0/2] CVE-2021-47434
by Yuan Can 25 Jun '24

25 Jun '24

Mathias Nyman (1): xhci: Fix commad ring abort, write all 64 bits to CRCR register. Pavankumar Kondeti (1): xhci: Fix command ring pointer corruption while aborting a command drivers/usb/host/xhci-ring.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) -- 2.17.1

2 3

[PATCH openEuler-22.03-LTS-SP1] clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
by Guo Mengqi 25 Jun '24

25 Jun '24

From: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> stable inclusion from stable-v5.10.201 commit 3994387ba3564976731179c4d4a6d7850ddda71a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RFZV Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f57f78fbacf630430bf954e5a84caafdfea30c0 ] Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support") Signed-off-by: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> Link: https://lore.kernel.org/r/20230912093407.21505-2-jiasheng@iscas.ac.cn Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Signed-off-by: Stephen Boyd <sboyd(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/clk/mediatek/clk-mt6779.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/clk/mediatek/clk-mt6779.c b/drivers/clk/mediatek/clk-mt6779.c index 6e0d3a166729..cf720651fc53 100644 --- a/drivers/clk/mediatek/clk-mt6779.c +++ b/drivers/clk/mediatek/clk-mt6779.c @@ -1216,6 +1216,8 @@ static int clk_mt6779_apmixed_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK); + if (!clk_data) + return -ENOMEM; mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data); @@ -1236,6 +1238,8 @@ static int clk_mt6779_top_probe(struct platform_device *pdev) return PTR_ERR(base); clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK); + if (!clk_data) + return -ENOMEM; mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks), clk_data); -- 2.17.1

2 2

[PATCH openEuler-22.03-LTS-SP1] clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
by Guo Mengqi 25 Jun '24

25 Jun '24

From: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> stable inclusion from stable-v5.10.201 commit 3994387ba3564976731179c4d4a6d7850ddda71a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RFZV Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f57f78fbacf630430bf954e5a84caafdfea30c0 ] Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support") Signed-off-by: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> Link: https://lore.kernel.org/r/20230912093407.21505-2-jiasheng@iscas.ac.cn Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Signed-off-by: Stephen Boyd <sboyd(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/clk/mediatek/clk-mt6779.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/clk/mediatek/clk-mt6779.c b/drivers/clk/mediatek/clk-mt6779.c index 6e0d3a166729..cf720651fc53 100644 --- a/drivers/clk/mediatek/clk-mt6779.c +++ b/drivers/clk/mediatek/clk-mt6779.c @@ -1216,6 +1216,8 @@ static int clk_mt6779_apmixed_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK); + if (!clk_data) + return -ENOMEM; mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data); @@ -1236,6 +1238,8 @@ static int clk_mt6779_top_probe(struct platform_device *pdev) return PTR_ERR(base); clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK); + if (!clk_data) + return -ENOMEM; mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks), clk_data); -- 2.17.1

2 2

[PATCH OLK-5.10] ASoC: SOF: Fix DSP oops stack dump output contents
by Guo Mengqi 25 Jun '24

25 Jun '24

From: Yong Zhi <yong.zhi(a)intel.com> mainline inclusion from mainline-v5.15-rc4 commit ac4dfccb96571ca03af7cac64b7a0b2952c97f3a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4NJ CVE: CVE-2021-47381 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix @buf arg given to hex_dump_to_buffer() and stack address used in dump error output. Fixes: e657c18a01c8 ('ASoC: SOF: Add xtensa support') Signed-off-by: Yong Zhi <yong.zhi(a)intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta(a)gmail.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://lore.kernel.org/r/20210915063230.29711-1-peter.ujfalusi@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- sound/soc/sof/xtensa/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/xtensa/core.c b/sound/soc/sof/xtensa/core.c index bbb9a2282ed9..f6e3411b33cf 100644 --- a/sound/soc/sof/xtensa/core.c +++ b/sound/soc/sof/xtensa/core.c @@ -122,9 +122,9 @@ static void xtensa_stack(struct snd_sof_dev *sdev, void *oops, u32 *stack, * 0x0049fbb0: 8000f2d0 0049fc00 6f6c6c61 00632e63 */ for (i = 0; i < stack_words; i += 4) { - hex_dump_to_buffer(stack + i * 4, 16, 16, 4, + hex_dump_to_buffer(stack + i, 16, 16, 4, buf, sizeof(buf), false); - dev_err(sdev->dev, "0x%08x: %s\n", stack_ptr + i, buf); + dev_err(sdev->dev, "0x%08x: %s\n", stack_ptr + i * 4, buf); } } -- 2.17.1

2 2

[PATCH openEuler-22.03-LTS-SP1] ASoC: SOF: Fix DSP oops stack dump output contents
by Guo Mengqi 25 Jun '24

25 Jun '24

From: Yong Zhi <yong.zhi(a)intel.com> mainline inclusion from mainline-v5.15-rc4 commit ac4dfccb96571ca03af7cac64b7a0b2952c97f3a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4NJ CVE: CVE-2021-47381 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Fix @buf arg given to hex_dump_to_buffer() and stack address used in dump error output. Fixes: e657c18a01c8 ('ASoC: SOF: Add xtensa support') Signed-off-by: Yong Zhi <yong.zhi(a)intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta(a)gmail.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Link: https://lore.kernel.org/r/20210915063230.29711-1-peter.ujfalusi@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- sound/soc/sof/xtensa/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/xtensa/core.c b/sound/soc/sof/xtensa/core.c index bbb9a2282ed9..f6e3411b33cf 100644 --- a/sound/soc/sof/xtensa/core.c +++ b/sound/soc/sof/xtensa/core.c @@ -122,9 +122,9 @@ static void xtensa_stack(struct snd_sof_dev *sdev, void *oops, u32 *stack, * 0x0049fbb0: 8000f2d0 0049fc00 6f6c6c61 00632e63 */ for (i = 0; i < stack_words; i += 4) { - hex_dump_to_buffer(stack + i * 4, 16, 16, 4, + hex_dump_to_buffer(stack + i, 16, 16, 4, buf, sizeof(buf), false); - dev_err(sdev->dev, "0x%08x: %s\n", stack_ptr + i, buf); + dev_err(sdev->dev, "0x%08x: %s\n", stack_ptr + i * 4, buf); } } -- 2.17.1

2 2

[PATCH OLK-5.10] usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
by Guo Mengqi 25 Jun '24

25 Jun '24

From: Krishna Kurapati <quic_kriskura(a)quicinc.com> stable inclusion from stable-v5.10.211 commit 57ca0e16f393bb21d69734e536e383a3a4c665fd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q8M7 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 76c51146820c5dac629f21deafab0a7039bc3ccd upstream. It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list. Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy shows one byte coming in extra confirming that the byte is coming in from PC: Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722) According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize. Cc: <stable(a)vger.kernel.org> Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added") Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> Reviewed-by: Maciej Żenczykowski <maze(a)google.com> Link: https://lore.kernel.org/r/20240205074650.200304-1-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/usb/gadget/function/f_ncm.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c index d1e36941c924..e3b89b7c1d67 100644 --- a/drivers/usb/gadget/function/f_ncm.c +++ b/drivers/usb/gadget/function/f_ncm.c @@ -1349,7 +1349,15 @@ static int ncm_unwrap_ntb(struct gether *port, "Parsed NTB with %d frames\n", dgram_counter); to_process -= block_len; - if (to_process != 0) { + + /* + * Windows NCM driver avoids USB ZLPs by adding a 1-byte + * zero pad as needed. + */ + if (to_process == 1 && + (*(unsigned char *)(ntb_ptr + block_len) == 0x00)) { + to_process--; + } else if (to_process > 0) { ntb_ptr = (unsigned char *)(ntb_ptr + block_len); goto parse_ntb; } -- 2.17.1

2 1

[PATCH OLK-5.10] usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
by Guo Mengqi 25 Jun '24

25 Jun '24

From: Krishna Kurapati <quic_kriskura(a)quicinc.com> stable inclusion from stable-v5.10.211 commit 57ca0e16f393bb21d69734e536e383a3a4c665fd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q8M7 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 76c51146820c5dac629f21deafab0a7039bc3ccd upstream. It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list. Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy shows one byte coming in extra confirming that the byte is coming in from PC: Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722) According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize. Cc: <stable(a)vger.kernel.org> Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added") Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> Reviewed-by: Maciej Żenczykowski <maze(a)google.com> Link: https://lore.kernel.org/r/20240205074650.200304-1-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/usb/gadget/function/f_ncm.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c index d1e36941c924..e3b89b7c1d67 100644 --- a/drivers/usb/gadget/function/f_ncm.c +++ b/drivers/usb/gadget/function/f_ncm.c @@ -1349,7 +1349,15 @@ static int ncm_unwrap_ntb(struct gether *port, "Parsed NTB with %d frames\n", dgram_counter); to_process -= block_len; - if (to_process != 0) { + + /* + * Windows NCM driver avoids USB ZLPs by adding a 1-byte + * zero pad as needed. + */ + if (to_process == 1 && + (*(unsigned char *)(ntb_ptr + block_len) == 0x00)) { + to_process--; + } else if (to_process > 0) { ntb_ptr = (unsigned char *)(ntb_ptr + block_len); goto parse_ntb; } -- 2.17.1

2 1

[PATCH OLK-5.10 v3] block: fix WARNING in init_blk_queue_async_dispatch
by Li Nan 25 Jun '24

25 Jun '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA5AEP CVE: NA -------------------------------- WARNING will be triggered when __kmalloc greater than 1 page with GFP_NOFAIL. On system with a large number of cpus, init_blk_queue_async_dispatch() may attempt to allocate memory larger than 1 page, causing the WARING: WARNING: CPU: 4 PID: 1 at mm/page_alloc.c:3485 get_page_from_freelist+0x115c/0x1224 Modules linked in: CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.0-212.0.0.112.oe2203sp4.aarch64 #1 Call trace: get_page_from_freelist+0x115c/0x1224 __alloc_pages+0x254/0x11f0 alloc_page_interleave+0x24/0xb0 alloc_pages+0xf0/0x16c kmalloc_order+0x38/0x1c0 kmalloc_order_trace+0x34/0x130 __kmalloc+0x524/0x680 init_blk_queue_async_dispatch+0xe8/0x160 blk_dev_init+0xa8/0xd0 genhd_device_init+0x64/0xb4 do_one_initcall+0x50/0x2a0 do_initcall_level+0xe4/0x110 do_initcalls+0x80/0xb8 kernel_init_freeable+0x1c8/0x254 kernel_init+0x1c/0x144 ret_from_fork+0x10/0x18 Fix it by removing flag GFP_NOFAIL and panic kernel if allocation fails. Fixes: 204f600cbb0c ("block: support to dispatch bio asynchronously") Signed-off-by: Li Nan <linan122(a)huawei.com> --- v3: Add fix tag. block/blk-core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/block/blk-core.c b/block/blk-core.c index e3e2659d0673..bf3bfc3ed339 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -285,7 +285,9 @@ static void init_blk_queue_async_dispatch(void) init_waitqueue_head(&ctl->wait); ctl->bios = kmalloc_array(nr_cpu_ids, sizeof(struct async_bio), - GFP_KERNEL | __GFP_NOFAIL); + GFP_KERNEL); + if (!ctl->bios) + panic("Failed to alloc async bio array\n"); for (i = 0; i < nr_cpu_ids; ++i) { bio_list_init(&ctl->bios[i].list); spin_lock_init(&ctl->bios[i].lock); -- 2.39.2

2 1

[PATCH OLK-5.10] xfs: atomic write file dio convert to mark IOCB_ATOMIC
by Long Li 25 Jun '24

25 Jun '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I9VTE3 CVE: NA -------------------------------- Add mount option "atomicalways", If the file support atomic write, while the user initiates a direct I/O write, convert the write to atomic write, it makes database like Mysql could use atomic write without any other more modify. This also causes some direct writes (such as offset misalignment and invalid length) to the files which with atomic write enabled to return fails. Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_file.c | 4 ++++ fs/xfs/xfs_mount.h | 2 ++ fs/xfs/xfs_super.c | 6 +++++- 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index 49db1611de96..75928200d7e9 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -814,6 +814,10 @@ xfs_file_write_iter( return xfs_file_dax_write(iocb, from); if (iocb->ki_flags & IOCB_DIRECT) { + + if (xfs_inode_atomicwrites(ip) && + xfs_has_atomicalways(ip->i_mount)) + iocb->ki_flags |= IOCB_ATOMIC; /* * Allow a directio write to fall back to a buffered * write *only* in the case that we're doing a reflink diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index 888d6bf9bea7..6b952ff031b6 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -279,6 +279,7 @@ typedef struct xfs_mount { /* Mount features */ +#define XFS_FEAT_ATOMICALWAYS (1ULL << 47) /* convert dio to atomic writes always */ #define XFS_FEAT_NOATTR2 (1ULL << 48) /* disable attr2 creation */ #define XFS_FEAT_NOALIGN (1ULL << 49) /* ignore alignment */ #define XFS_FEAT_ALLOCSIZE (1ULL << 50) /* user specified allocation size */ @@ -365,6 +366,7 @@ __XFS_HAS_FEAT(dax_always, DAX_ALWAYS) __XFS_HAS_FEAT(dax_never, DAX_NEVER) __XFS_HAS_FEAT(norecovery, NORECOVERY) __XFS_HAS_FEAT(nouuid, NOUUID) +__XFS_HAS_FEAT(atomicalways, ATOMICALWAYS) /* * Operational mount state flags diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index d43f76a4b99a..0359713fefd8 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -116,7 +116,7 @@ enum { Opt_filestreams, Opt_quota, Opt_noquota, Opt_usrquota, Opt_grpquota, Opt_prjquota, Opt_uquota, Opt_gquota, Opt_pquota, Opt_uqnoenforce, Opt_gqnoenforce, Opt_pqnoenforce, Opt_qnoenforce, - Opt_discard, Opt_nodiscard, Opt_dax, Opt_dax_enum, + Opt_discard, Opt_nodiscard, Opt_dax, Opt_dax_enum, Opt_atomicalways, }; static const struct fs_parameter_spec xfs_fs_parameters[] = { @@ -161,6 +161,7 @@ static const struct fs_parameter_spec xfs_fs_parameters[] = { fsparam_flag("nodiscard", Opt_nodiscard), fsparam_flag("dax", Opt_dax), fsparam_enum("dax", Opt_dax_enum, dax_param_enums), + fsparam_flag("atomicalways", Opt_atomicalways), {} }; @@ -1361,6 +1362,9 @@ xfs_fc_parse_param( xfs_fs_warn_deprecated(fc, param, XFS_FEAT_NOATTR2, true); parsing_mp->m_features |= XFS_FEAT_NOATTR2; return 0; + case Opt_atomicalways: + parsing_mp->m_features |= XFS_FEAT_ATOMICALWAYS; + return 0; default: xfs_warn(parsing_mp, "unknown mount option [%s].", param->key); return -EINVAL; -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] mm/migrate: set swap entry values of THP tail pages properly.
by Liu Shixin 25 Jun '24

25 Jun '24

From: Zi Yan <ziy(a)nvidia.com> stable inclusion from stable-v4.19.312 commit 9e92cefdaa7537515dc0ff6cc73d46fa31b062fc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA82S5 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- The tail pages in a THP can have swap entry information stored in their private field. When migrating to a new page, all tail pages of the new page need to update ->private to avoid future data corruption. This fix is stable-only, since after commit 07e09c483cbe ("mm/huge_memory: work on folio->swap instead of page->private when splitting folio"), subpages of a swapcached THP no longer requires the maintenance. Adding THPs to the swapcache was introduced in commit 38d8b4e6bdc87 ("mm, THP, swap: delay splitting THP during swap out"), where each subpage of a THP added to the swapcache had its own swapcache entry and required the ->private field to point to the correct swapcache entry. Later, when THP migration functionality was implemented in commit 616b8371539a6 ("mm: thp: enable thp migration in generic path"), it initially did not handle the subpages of swapcached THPs, failing to update their ->private fields or replace the subpage pointers in the swapcache. Subsequently, commit e71769ae5260 ("mm: enable thp migration for shmem thp") addressed the swapcache update aspect. This patch fixes the update of subpage ->private fields. Closes: https://lore.kernel.org/linux-mm/1707814102-22682-1-git-send-email-quic_cha… Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path") Signed-off-by: Zi Yan <ziy(a)nvidia.com> Acked-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/migrate.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mm/migrate.c b/mm/migrate.c index dbe174f86cfd..f8c379a0b9b9 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -515,8 +515,12 @@ int migrate_page_move_mapping(struct address_space *mapping, if (PageSwapBacked(page)) { __SetPageSwapBacked(newpage); if (PageSwapCache(page)) { + int i; + SetPageSwapCache(newpage); - set_page_private(newpage, page_private(page)); + for (i = 0; i < (1 << compound_order(page)); i++) + set_page_private(newpage + i, + page_private(page + i)); } } else { VM_BUG_ON_PAGE(PageSwapCache(page), page); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/1] CVE-2024-38587
by Chen Ridong 25 Jun '24

25 Jun '24

*** BLURB HERE *** Dan Carpenter (1): speakup: Fix sizeof() vs ARRAY_SIZE() bug drivers/staging/speakup/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS 0/1] CVE-2024-38587
by Chen Ridong 25 Jun '24

25 Jun '24

*** BLURB HERE *** Dan Carpenter (1): speakup: Fix sizeof() vs ARRAY_SIZE() bug drivers/staging/speakup/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-6.6] mm: drop the 'anon_' prefix for swap-out mTHP counters
by Liu Shixin 25 Jun '24

25 Jun '24

From: Baolin Wang <baolin.wang(a)linux.alibaba.com> mainline inclusion from mainline-v6.10-rc3 commit 0d648dd5c899f33154b98a6aef6e3dab0f4de613 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA7H2V CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The mTHP swap related counters: 'anon_swpout' and 'anon_swpout_fallback' are confusing with an 'anon_' prefix, since the shmem can swap out non-anonymous pages. So drop the 'anon_' prefix to keep consistent with the old swap counter names. This is needed in 6.10-rcX to avoid having an inconsistent ABI out in the field. Link: https://lkml.kernel.org/r/7a8989c13299920d7589007a30065c3e2c19f0e0.17164317… Fixes: d0f048ac39f6 ("mm: add per-order mTHP anon_swpout and anon_swpout_fallback counters") Fixes: 42248b9d34ea ("mm: add docs for per-order mTHP counters and transhuge_page ABI") Signed-off-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Suggested-by: "Huang, Ying" <ying.huang(a)intel.com> Acked-by: Barry Song <baohua(a)kernel.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Lance Yang <ioworker0(a)gmail.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Zi Yan <ziy(a)nvidia.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- Documentation/admin-guide/mm/transhuge.rst | 4 ++-- include/linux/huge_mm.h | 4 ++-- mm/huge_memory.c | 8 ++++---- mm/page_io.c | 2 +- mm/vmscan.c | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index e66d1d7ee711..f9d692f049f6 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -496,11 +496,11 @@ anon_fault_fallback_charge instead falls back to using huge pages with lower orders or small pages even though the allocation was successful. -anon_swpout +swpout is incremented every time a huge page is swapped out in one piece without splitting. -anon_swpout_fallback +swpout_fallback is incremented if a huge page has to be split before swapout. Usually because failed to allocate some continuous swap space for the huge page. diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index 18f7cfb7fca4..0da01df3b283 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -267,8 +267,8 @@ enum mthp_stat_item { MTHP_STAT_ANON_FAULT_ALLOC, MTHP_STAT_ANON_FAULT_FALLBACK, MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE, - MTHP_STAT_ANON_SWPOUT, - MTHP_STAT_ANON_SWPOUT_FALLBACK, + MTHP_STAT_SWPOUT, + MTHP_STAT_SWPOUT_FALLBACK, __MTHP_STAT_COUNT }; diff --git a/mm/huge_memory.c b/mm/huge_memory.c index a6f087186630..32ddf09db52b 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -701,15 +701,15 @@ static struct kobj_attribute _name##_attr = __ATTR_RO(_name) DEFINE_MTHP_STAT_ATTR(anon_fault_alloc, MTHP_STAT_ANON_FAULT_ALLOC); DEFINE_MTHP_STAT_ATTR(anon_fault_fallback, MTHP_STAT_ANON_FAULT_FALLBACK); DEFINE_MTHP_STAT_ATTR(anon_fault_fallback_charge, MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE); -DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT); -DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK); +DEFINE_MTHP_STAT_ATTR(swpout, MTHP_STAT_SWPOUT); +DEFINE_MTHP_STAT_ATTR(swpout_fallback, MTHP_STAT_SWPOUT_FALLBACK); static struct attribute *stats_attrs[] = { &anon_fault_alloc_attr.attr, &anon_fault_fallback_attr.attr, &anon_fault_fallback_charge_attr.attr, - &anon_swpout_attr.attr, - &anon_swpout_fallback_attr.attr, + &swpout_attr.attr, + &swpout_fallback_attr.attr, NULL, }; diff --git a/mm/page_io.c b/mm/page_io.c index 80e49e536d37..f2b3c4eed688 100644 --- a/mm/page_io.c +++ b/mm/page_io.c @@ -212,7 +212,7 @@ static inline void count_swpout_vm_event(struct folio *folio) count_memcg_folio_events(folio, THP_SWPOUT, 1); count_vm_event(THP_SWPOUT); } - count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPOUT); + count_mthp_stat(folio_order(folio), MTHP_STAT_SWPOUT); #endif count_vm_events(PSWPOUT, folio_nr_pages(folio)); } diff --git a/mm/vmscan.c b/mm/vmscan.c index 44154c63ec6c..424652601c56 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1925,7 +1925,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, THP_SWPOUT_FALLBACK, 1); count_vm_event(THP_SWPOUT_FALLBACK); } - count_mthp_stat(order, MTHP_STAT_ANON_SWPOUT_FALLBACK); + count_mthp_stat(order, MTHP_STAT_SWPOUT_FALLBACK); #endif if (!add_to_swap(folio)) goto activate_locked_split; -- 2.25.1

2 1

[PATCH OLK-6.6 0/1] vfio/pci: fix potential memory leak in vfio_intx_enable()
by Huang Xiaojia 25 Jun '24

25 Jun '24

*** BLURB HERE *** Ye Bin (1): vfio/pci: fix potential memory leak in vfio_intx_enable() drivers/vfio/pci/vfio_pci_intrs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-5.10 v2] block: fix WARNING in init_blk_queue_async_dispatch
by Li Nan 25 Jun '24

25 Jun '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA5AEP CVE: NA -------------------------------- WARNING will be triggered when __kmalloc greater than 1 page with GFP_NOFAIL. On system with a large number of cpus, init_blk_queue_async_dispatch() may attempt to allocate memory larger than 1 page, causing the WARING: WARNING: CPU: 4 PID: 1 at mm/page_alloc.c:3485 get_page_from_freelist+0x115c/0x1224 Modules linked in: CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.0-212.0.0.112.oe2203sp4.aarch64 #1 Call trace: get_page_from_freelist+0x115c/0x1224 __alloc_pages+0x254/0x11f0 alloc_page_interleave+0x24/0xb0 alloc_pages+0xf0/0x16c kmalloc_order+0x38/0x1c0 kmalloc_order_trace+0x34/0x130 __kmalloc+0x524/0x680 init_blk_queue_async_dispatch+0xe8/0x160 blk_dev_init+0xa8/0xd0 genhd_device_init+0x64/0xb4 do_one_initcall+0x50/0x2a0 do_initcall_level+0xe4/0x110 do_initcalls+0x80/0xb8 kernel_init_freeable+0x1c8/0x254 kernel_init+0x1c/0x144 ret_from_fork+0x10/0x18 Fix it by removing flag GFP_NOFAIL and panic kernel if allocation fails. Signed-off-by: Li Nan <linan122(a)huawei.com> --- v2: Use panic instead of BUG_ON. Add patch head. block/blk-core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/block/blk-core.c b/block/blk-core.c index e3e2659d0673..bf3bfc3ed339 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -285,7 +285,9 @@ static void init_blk_queue_async_dispatch(void) init_waitqueue_head(&ctl->wait); ctl->bios = kmalloc_array(nr_cpu_ids, sizeof(struct async_bio), - GFP_KERNEL | __GFP_NOFAIL); + GFP_KERNEL); + if (!ctl->bios) + panic("Failed to alloc async bio array\n"); for (i = 0; i < nr_cpu_ids; ++i) { bio_list_init(&ctl->bios[i].list); spin_lock_init(&ctl->bios[i].lock); -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] kprobes: Fix possible use-after-free issue on kprobe registration
by Chen Zhongjin 25 Jun '24

25 Jun '24

From: Zheng Yejian <zhengyejian1(a)huawei.com> stable inclusion from stable-v5.10.216 commit 5062d1f4f07facbdade0f402d9a04a788f52e26d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QRI5 CVE: CVE-2024-35955 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8 upstream. When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE. Link: https://lore.kernel.org/all/20240410015802.265220-1-zhengyejian1@huawei.com/ Fixes: 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas") Cc: stable(a)vger.kernel.org Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> [Fix conflict due to lack dependency commit 223a76b268c9 ("kprobes: Fix coding style issues")] Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- kernel/kprobes.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index de4f8899ec3b..4548dec331ff 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1639,10 +1639,17 @@ static int check_kprobe_address_safe(struct kprobe *p, jump_label_lock(); preempt_disable(); - /* Ensure it is not in reserved area nor out of text */ - if (!(core_kernel_text((unsigned long) p->addr) || - is_module_text_address((unsigned long) p->addr)) || - in_gate_area_no_mm((unsigned long) p->addr) || + /* Ensure the address is in a text area, and find a module if exists. */ + *probed_mod = NULL; + if (!core_kernel_text((unsigned long) p->addr)) { + *probed_mod = __module_text_address((unsigned long) p->addr); + if (!(*probed_mod)) { + ret = -EINVAL; + goto out; + } + } + /* Ensure it is not in reserved area. */ + if (in_gate_area_no_mm((unsigned long) p->addr) || within_kprobe_blacklist((unsigned long) p->addr) || jump_label_text_reserved(p->addr, p->addr) || static_call_text_reserved(p->addr, p->addr) || @@ -1651,8 +1658,7 @@ static int check_kprobe_address_safe(struct kprobe *p, goto out; } - /* Check if are we probing a module */ - *probed_mod = __module_text_address((unsigned long) p->addr); + /* Get module refcount and reject __init functions for loaded modules. */ if (*probed_mod) { /* * We must hold a refcount of the probed module while updating -- 2.25.1

2 1

[PATCH OLK-6.6 0/1] Fix CVE-2024-31076
by Hongbo Li 25 Jun '24

25 Jun '24

Fix CVE-2024-31076. Dongli Zhang (1): genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline arch/x86/kernel/apic/vector.c | 9 ++++++--- kernel/irq/cpuhotplug.c | 16 ++++++++-------- 2 files changed, 14 insertions(+), 11 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] drm/mediatek: Add 0 size check to mtk_drm_gem_obj
by Liu Chuang 25 Jun '24

25 Jun '24

From: Justin Green <greenjustin(a)chromium.org> stable inclusion from stable-v4.19.316 commit 79078880795478d551a05acc41f957700030d364 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8E CVE: CVE-2024-38549 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1e4350095e8ab2577ee05f8c3b044e661b5af9a0 ] Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Justin Green <greenjustin(a)chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Reviewed-by: CK Hu <ck.hu(a)mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240307180051.4104425… Signed-off-by: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c b/drivers/gpu/drm/mediatek/mtk_drm_gem.c index b09a37a38e0a..079df67892df 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c @@ -26,6 +26,9 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev, size = round_up(size, PAGE_SIZE); + if (size == 0) + return ERR_PTR(-EINVAL); + mtk_gem_obj = kzalloc(sizeof(*mtk_gem_obj), GFP_KERNEL); if (!mtk_gem_obj) return ERR_PTR(-ENOMEM); -- 2.34.1

2 1

[PATCH] mm: drop the 'anon_' prefix for swap-out mTHP counters
by Liu Shixin 25 Jun '24

25 Jun '24

From: Baolin Wang <baolin.wang(a)linux.alibaba.com> mainline inclusion from mainline-v6.10-rc3 commit 0d648dd5c899f33154b98a6aef6e3dab0f4de613 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA7H2V CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The mTHP swap related counters: 'anon_swpout' and 'anon_swpout_fallback' are confusing with an 'anon_' prefix, since the shmem can swap out non-anonymous pages. So drop the 'anon_' prefix to keep consistent with the old swap counter names. This is needed in 6.10-rcX to avoid having an inconsistent ABI out in the field. Link: https://lkml.kernel.org/r/7a8989c13299920d7589007a30065c3e2c19f0e0.17164317… Fixes: d0f048ac39f6 ("mm: add per-order mTHP anon_swpout and anon_swpout_fallback counters") Fixes: 42248b9d34ea ("mm: add docs for per-order mTHP counters and transhuge_page ABI") Signed-off-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Suggested-by: "Huang, Ying" <ying.huang(a)intel.com> Acked-by: Barry Song <baohua(a)kernel.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Lance Yang <ioworker0(a)gmail.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Zi Yan <ziy(a)nvidia.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- Documentation/admin-guide/mm/transhuge.rst | 4 ++-- include/linux/huge_mm.h | 4 ++-- mm/huge_memory.c | 8 ++++---- mm/page_io.c | 2 +- mm/vmscan.c | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index e66d1d7ee711..f9d692f049f6 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -496,11 +496,11 @@ anon_fault_fallback_charge instead falls back to using huge pages with lower orders or small pages even though the allocation was successful. -anon_swpout +swpout is incremented every time a huge page is swapped out in one piece without splitting. -anon_swpout_fallback +swpout_fallback is incremented if a huge page has to be split before swapout. Usually because failed to allocate some continuous swap space for the huge page. diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index 18f7cfb7fca4..0da01df3b283 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -267,8 +267,8 @@ enum mthp_stat_item { MTHP_STAT_ANON_FAULT_ALLOC, MTHP_STAT_ANON_FAULT_FALLBACK, MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE, - MTHP_STAT_ANON_SWPOUT, - MTHP_STAT_ANON_SWPOUT_FALLBACK, + MTHP_STAT_SWPOUT, + MTHP_STAT_SWPOUT_FALLBACK, __MTHP_STAT_COUNT }; diff --git a/mm/huge_memory.c b/mm/huge_memory.c index a6f087186630..32ddf09db52b 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -701,15 +701,15 @@ static struct kobj_attribute _name##_attr = __ATTR_RO(_name) DEFINE_MTHP_STAT_ATTR(anon_fault_alloc, MTHP_STAT_ANON_FAULT_ALLOC); DEFINE_MTHP_STAT_ATTR(anon_fault_fallback, MTHP_STAT_ANON_FAULT_FALLBACK); DEFINE_MTHP_STAT_ATTR(anon_fault_fallback_charge, MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE); -DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT); -DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK); +DEFINE_MTHP_STAT_ATTR(swpout, MTHP_STAT_SWPOUT); +DEFINE_MTHP_STAT_ATTR(swpout_fallback, MTHP_STAT_SWPOUT_FALLBACK); static struct attribute *stats_attrs[] = { &anon_fault_alloc_attr.attr, &anon_fault_fallback_attr.attr, &anon_fault_fallback_charge_attr.attr, - &anon_swpout_attr.attr, - &anon_swpout_fallback_attr.attr, + &swpout_attr.attr, + &swpout_fallback_attr.attr, NULL, }; diff --git a/mm/page_io.c b/mm/page_io.c index 80e49e536d37..f2b3c4eed688 100644 --- a/mm/page_io.c +++ b/mm/page_io.c @@ -212,7 +212,7 @@ static inline void count_swpout_vm_event(struct folio *folio) count_memcg_folio_events(folio, THP_SWPOUT, 1); count_vm_event(THP_SWPOUT); } - count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPOUT); + count_mthp_stat(folio_order(folio), MTHP_STAT_SWPOUT); #endif count_vm_events(PSWPOUT, folio_nr_pages(folio)); } diff --git a/mm/vmscan.c b/mm/vmscan.c index 44154c63ec6c..424652601c56 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1925,7 +1925,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, THP_SWPOUT_FALLBACK, 1); count_vm_event(THP_SWPOUT_FALLBACK); } - count_mthp_stat(order, MTHP_STAT_ANON_SWPOUT_FALLBACK); + count_mthp_stat(order, MTHP_STAT_SWPOUT_FALLBACK); #endif if (!add_to_swap(folio)) goto activate_locked_split; -- 2.25.1

1 0

[PATCH OLK-5.10] drm/mediatek: Add 0 size check to mtk_drm_gem_obj
by Liu Chuang 25 Jun '24

25 Jun '24

From: Justin Green <greenjustin(a)chromium.org> stable inclusion from stable-v5.10.219 commit d17b75ee9c2e44d3a3682c4ea5ab713ea6073350 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8E CVE: CVE-2024-38549 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit 1e4350095e8ab2577ee05f8c3b044e661b5af9a0 ] Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Justin Green <greenjustin(a)chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Reviewed-by: CK Hu <ck.hu(a)mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240307180051.4104425… Signed-off-by: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c b/drivers/gpu/drm/mediatek/mtk_drm_gem.c index b20ea58907c2..1dac9cd20d46 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c @@ -21,6 +21,9 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev, size = round_up(size, PAGE_SIZE); + if (size == 0) + return ERR_PTR(-EINVAL); + mtk_gem_obj = kzalloc(sizeof(*mtk_gem_obj), GFP_KERNEL); if (!mtk_gem_obj) return ERR_PTR(-ENOMEM); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] drm/arm/malidp: fix a possible null pointer dereference
by Chen Zhongjin 25 Jun '24

25 Jun '24

From: Huai-Yuan Liu <qq810974084(a)gmail.com> stable inclusion from stable-v4.19.316 commit b6cc5dd06336ed8bb3a7a1fc5aaf7d5e88bc0818 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9T5PA CVE: CVE-2024-36014 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a1f95aede6285dba6dd036d907196f35ae3a11ea ] In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset. Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector") Signed-off-by: Huai-Yuan Liu <qq810974084(a)gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau(a)arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240407063053.5481-1-qq81097… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/gpu/drm/arm/malidp_mw.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c index 91472e5e0c8b..cc27ac25372f 100644 --- a/drivers/gpu/drm/arm/malidp_mw.c +++ b/drivers/gpu/drm/arm/malidp_mw.c @@ -69,7 +69,10 @@ static void malidp_mw_connector_reset(struct drm_connector *connector) __drm_atomic_helper_connector_destroy_state(connector->state); kfree(connector->state); - __drm_atomic_helper_connector_reset(connector, &mw_state->base); + connector->state = NULL; + + if (mw_state) + __drm_atomic_helper_connector_reset(connector, &mw_state->base); } static enum drm_connector_status -- 2.25.1

2 1

[PATCH OLK-5.10] block: fix WARNING in init_blk_queue_async_dispatch
by Li Nan 25 Jun '24

25 Jun '24

WARNING will be triggered when __kmalloc greater than 1 page with GFP_NOFAIL. On system with a large number of cpus, init_blk_queue_async_dispatch() may attempt to allocate memory larger than 1 page, causing the WARING: ------------[ cut here ]------------ WARNING: CPU: 4 PID: 1 at mm/page_alloc.c:3485 get_page_from_freelist+0x115c/0x1224 Modules linked in: CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.0-212.0.0.112.oe2203sp4.aarch64 #1 Call trace: get_page_from_freelist+0x115c/0x1224 __alloc_pages+0x254/0x11f0 alloc_page_interleave+0x24/0xb0 alloc_pages+0xf0/0x16c kmalloc_order+0x38/0x1c0 kmalloc_order_trace+0x34/0x130 __kmalloc+0x524/0x680 init_blk_queue_async_dispatch+0xe8/0x160 blk_dev_init+0xa8/0xd0 genhd_device_init+0x64/0xb4 do_one_initcall+0x50/0x2a0 do_initcall_level+0xe4/0x110 do_initcalls+0x80/0xb8 kernel_init_freeable+0x1c8/0x254 kernel_init+0x1c/0x144 ret_from_fork+0x10/0x18 ---[ end trace 5fed5af9086c724c ]--- Fix it by removing flag GFP_NOFAIL and panic kernel if allocation fails. Signed-off-by: Li Nan <linan122(a)huawei.com> --- block/blk-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/block/blk-core.c b/block/blk-core.c index e3e2659d0673..95f7d796482b 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -285,7 +285,8 @@ static void init_blk_queue_async_dispatch(void) init_waitqueue_head(&ctl->wait); ctl->bios = kmalloc_array(nr_cpu_ids, sizeof(struct async_bio), - GFP_KERNEL | __GFP_NOFAIL); + GFP_KERNEL); + BUG_ON(!ctl->bios); for (i = 0; i < nr_cpu_ids; ++i) { bio_list_init(&ctl->bios[i].list); spin_lock_init(&ctl->bios[i].lock); -- 2.39.2

2 1

[PATCH OLK-6.6] drm/mediatek: Add 0 size check to mtk_drm_gem_obj
by Liu Chuang 25 Jun '24

25 Jun '24

From: Justin Green <greenjustin(a)chromium.org> stable inclusion from stable-v6.6.33 commit af26ea99019caee1500bf7e60c861136c0bf8594 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8E CVE: CVE-2024-38549 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1e4350095e8ab2577ee05f8c3b044e661b5af9a0 ] Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Justin Green <greenjustin(a)chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Reviewed-by: CK Hu <ck.hu(a)mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240307180051.4104425… Signed-off-by: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c b/drivers/gpu/drm/mediatek/mtk_drm_gem.c index 4f2e3feabc0f..1bf229615b01 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c @@ -38,6 +38,9 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev, size = round_up(size, PAGE_SIZE); + if (size == 0) + return ERR_PTR(-EINVAL); + mtk_gem_obj = kzalloc(sizeof(*mtk_gem_obj), GFP_KERNEL); if (!mtk_gem_obj) return ERR_PTR(-ENOMEM); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] kprobes: Fix possible use-after-free issue on kprobe registration
by Chen Zhongjin 25 Jun '24

25 Jun '24

From: Zheng Yejian <zhengyejian1(a)huawei.com> stable inclusion from stable-v5.10.216 commit 5062d1f4f07facbdade0f402d9a04a788f52e26d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QRI5 CVE: CVE-2024-35955 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8 upstream. When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE. Link: https://lore.kernel.org/all/20240410015802.265220-1-zhengyejian1@huawei.com/ Fixes: 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas") Cc: stable(a)vger.kernel.org Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> [Fix conflict due to lack dependency commit 223a76b268c9 ("kprobes: Fix coding style issues")] Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: kernel/kprobes.c [This conflict because dependency commit 1efda38d6f9b ("kprobes: Prohibit probes in gate area") not merged] Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- kernel/kprobes.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 0990b9a5e47c..1a94cbc4572e 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1639,9 +1639,17 @@ static int check_kprobe_address_safe(struct kprobe *p, jump_label_lock(); preempt_disable(); - /* Ensure it is not in reserved area nor out of text */ - if (!(core_kernel_text((unsigned long) p->addr) || - is_module_text_address((unsigned long) p->addr)) || + /* Ensure the address is in a text area, and find a module if exists. */ + *probed_mod = NULL; + if (!core_kernel_text((unsigned long) p->addr)) { + *probed_mod = __module_text_address((unsigned long) p->addr); + if (!(*probed_mod)) { + ret = -EINVAL; + goto out; + } + } + /* Ensure it is not in reserved area. */ + if (in_gate_area_no_mm((unsigned long) p->addr) || within_kprobe_blacklist((unsigned long) p->addr) || jump_label_text_reserved(p->addr, p->addr) || static_call_text_reserved(p->addr, p->addr) || @@ -1650,8 +1658,7 @@ static int check_kprobe_address_safe(struct kprobe *p, goto out; } - /* Check if are we probing a module */ - *probed_mod = __module_text_address((unsigned long) p->addr); + /* Get module refcount and reject __init functions for loaded modules. */ if (*probed_mod) { /* * We must hold a refcount of the probed module while updating -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] drm/mediatek: Add 0 size check to mtk_drm_gem_obj
by Liu Chuang 25 Jun '24

25 Jun '24

From: Justin Green <greenjustin(a)chromium.org> stable inclusion from -v4.19.316 commit 79078880795478d551a05acc41f957700030d364 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8E CVE: CVE-2024-38549 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1e4350095e8ab2577ee05f8c3b044e661b5af9a0 ] Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Justin Green <greenjustin(a)chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Reviewed-by: CK Hu <ck.hu(a)mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240307180051.4104425… Signed-off-by: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c b/drivers/gpu/drm/mediatek/mtk_drm_gem.c index b09a37a38e0a..079df67892df 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c @@ -26,6 +26,9 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev, size = round_up(size, PAGE_SIZE); + if (size == 0) + return ERR_PTR(-EINVAL); + mtk_gem_obj = kzalloc(sizeof(*mtk_gem_obj), GFP_KERNEL); if (!mtk_gem_obj) return ERR_PTR(-ENOMEM); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/1] Fix CVE-2024-31076
by Hongbo Li 25 Jun '24

25 Jun '24

Fix CVE-2024-31076. Dongli Zhang (1): genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline arch/x86/kernel/apic/vector.c | 9 ++++++--- kernel/irq/cpuhotplug.c | 16 ++++++++-------- 2 files changed, 14 insertions(+), 11 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6] fs/ntfs3: Use variable length array instead of fixed size
by Long Li 25 Jun '24

25 Jun '24

From: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> mainline inclusion from mainline-v6.9-rc4 commit 1997cdc3e727526aa5d84b32f7cbb3f56459b7ef category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D5A CVE: CVE-2024-38623 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Should fix smatch warning: ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256) Fixes: 4534a70b7056f ("fs/ntfs3: Add headers and misc files") Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/r/202401091421.3RJ24Mn3-lkp@intel.com/ Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ntfs3/ntfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ntfs3/ntfs.h b/fs/ntfs3/ntfs.h index f61f5b3adb03..b70288cc5f6f 100644 --- a/fs/ntfs3/ntfs.h +++ b/fs/ntfs3/ntfs.h @@ -59,7 +59,7 @@ struct GUID { struct cpu_str { u8 len; u8 unused; - u16 name[10]; + u16 name[]; }; struct le_str { -- 2.39.2

2 1

[PATCH OLK-5.10 0/1] Fix CVE-2024-31076
by Hongbo Li 25 Jun '24

25 Jun '24

Fix CVE-2024-31076. Dongli Zhang (1): genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline arch/x86/kernel/apic/vector.c | 9 ++++++--- kernel/irq/cpuhotplug.c | 16 ++++++++-------- 2 files changed, 14 insertions(+), 11 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS 0/1] Fix CVE-2024-31076
by Hongbo Li 25 Jun '24

25 Jun '24

Backport CVE-2024-31076. Dongli Zhang (1): genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline arch/x86/kernel/apic/vector.c | 9 ++++++--- kernel/irq/cpuhotplug.c | 16 ++++++++-------- 2 files changed, 14 insertions(+), 11 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6] tracing/probes: fix error check in parse_btf_field()
by Zheng Yejian 25 Jun '24

25 Jun '24

From: Carlos López <clopez(a)suse.de> stable inclusion from stable-v6.6.33 commit ad4b202da2c498fefb69e5d87f67b946e7fe1e6a bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DBJ CVE: CVE-2024-36481 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e569eb34970281438e2b48a3ef11c87459fcfbcb ] btf_find_struct_member() might return NULL or an error via the ERR_PTR() macro. However, its caller in parse_btf_field() only checks for the NULL condition. Fix this by using IS_ERR() and returning the error up the stack. Link: https://lore.kernel.org/all/20240527094351.15687-1-clopez@suse.de/ Fixes: c440adfbe3025 ("tracing/probes: Support BTF based data structure field access") Signed-off-by: Carlos López <clopez(a)suse.de> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/trace_probe.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c index 34289f9c6707..ae162ba36a48 100644 --- a/kernel/trace/trace_probe.c +++ b/kernel/trace/trace_probe.c @@ -553,6 +553,10 @@ static int parse_btf_field(char *fieldname, const struct btf_type *type, anon_offs = 0; field = btf_find_struct_member(ctx->btf, type, fieldname, &anon_offs); + if (IS_ERR(field)) { + trace_probe_log_err(ctx->offset, BAD_BTF_TID); + return PTR_ERR(field); + } if (!field) { trace_probe_log_err(ctx->offset, NO_BTF_FIELD); return -ENOENT; -- 2.25.1

2 1

[openEuler-22.03-LTS-SP1] kprobes: Fix possible use-after-free issue on kprobe registration
by Chen Zhongjin 25 Jun '24

25 Jun '24

From: Zheng Yejian <zhengyejian1(a)huawei.com> stable inclusion from stable-v5.10.216 commit 5062d1f4f07facbdade0f402d9a04a788f52e26d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QRI5 CVE: CVE-2024-35955 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8 upstream. When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE. Link: https://lore.kernel.org/all/20240410015802.265220-1-zhengyejian1@huawei.com/ Fixes: 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas") Cc: stable(a)vger.kernel.org Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> [Fix conflict due to lack dependency commit 223a76b268c9 ("kprobes: Fix coding style issues")] Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: kernel/kprobes.c [This conflict because dependency commit 1efda38d6f9b ("kprobes: Prohibit probes in gate area") not merged] Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- kernel/kprobes.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 0990b9a5e47c..1a94cbc4572e 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1639,9 +1639,17 @@ static int check_kprobe_address_safe(struct kprobe *p, jump_label_lock(); preempt_disable(); - /* Ensure it is not in reserved area nor out of text */ - if (!(core_kernel_text((unsigned long) p->addr) || - is_module_text_address((unsigned long) p->addr)) || + /* Ensure the address is in a text area, and find a module if exists. */ + *probed_mod = NULL; + if (!core_kernel_text((unsigned long) p->addr)) { + *probed_mod = __module_text_address((unsigned long) p->addr); + if (!(*probed_mod)) { + ret = -EINVAL; + goto out; + } + } + /* Ensure it is not in reserved area. */ + if (in_gate_area_no_mm((unsigned long) p->addr) || within_kprobe_blacklist((unsigned long) p->addr) || jump_label_text_reserved(p->addr, p->addr) || static_call_text_reserved(p->addr, p->addr) || @@ -1650,8 +1658,7 @@ static int check_kprobe_address_safe(struct kprobe *p, goto out; } - /* Check if are we probing a module */ - *probed_mod = __module_text_address((unsigned long) p->addr); + /* Get module refcount and reject __init functions for loaded modules. */ if (*probed_mod) { /* * We must hold a refcount of the probed module while updating -- 2.25.1

1 0

[PATCH openEuler-22.03-LTS-SP1] RDMA/hns: Fix deadlock on SRQ async events.
by Zhengchao Shao 25 Jun '24

25 Jun '24

From: Chengchang Tang <tangchengchang(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit b46494b6f9c19f141114a57729e198698f40af37 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SF1 CVE: CVE-2024-38591 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock. Fixes: 81fce6291d99 ("RDMA/hns: Add SRQ asynchronous event support") Signed-off-by: Chengchang Tang <tangchengchang(a)huawei.com> Signed-off-by: Junxian Huang <huangjunxian6(a)hisilicon.com> Link: https://lore.kernel.org/r/20240412091616.370789-5-huangjunxian6@hisilicon.c… Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Conflicts: drivers/infiniband/hw/hns/hns_roce_main.c [The conflict occurs because the commit e4df3a25f0fa("[Backport] RDMA/hns: support RoCE bonding") has been merged. It contains hnae3.h] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/infiniband/hw/hns/hns_roce_srq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_srq.c b/drivers/infiniband/hw/hns/hns_roce_srq.c index 727c7a134102..a3999fc69719 100644 --- a/drivers/infiniband/hw/hns/hns_roce_srq.c +++ b/drivers/infiniband/hw/hns/hns_roce_srq.c @@ -122,7 +122,7 @@ static int alloc_srqc(struct hns_roce_dev *hr_dev, struct hns_roce_srq *srq) return ret; } - ret = xa_err(xa_store(&srq_table->xa, srq->srqn, srq, GFP_KERNEL)); + ret = xa_err(xa_store_irq(&srq_table->xa, srq->srqn, srq, GFP_KERNEL)); if (ret) { ibdev_err(ibdev, "failed to store SRQC, ret = %d.\n", ret); goto err_put; @@ -135,7 +135,7 @@ static int alloc_srqc(struct hns_roce_dev *hr_dev, struct hns_roce_srq *srq) return 0; err_xa: - xa_erase(&srq_table->xa, srq->srqn); + xa_erase_irq(&srq_table->xa, srq->srqn); err_put: hns_roce_table_put(hr_dev, &srq_table->table, srq->srqn); @@ -153,7 +153,7 @@ static void free_srqc(struct hns_roce_dev *hr_dev, struct hns_roce_srq *srq) dev_err(hr_dev->dev, "DESTROY_SRQ failed (%d) for SRQN %06lx\n", ret, srq->srqn); - xa_erase(&srq_table->xa, srq->srqn); + xa_erase_irq(&srq_table->xa, srq->srqn); if (refcount_dec_and_test(&srq->refcount)) complete(&srq->free); -- 2.34.1

2 1

[PATCH OLK-5.10 0/1] CVE-2024-38587
by Chen Ridong 24 Jun '24

24 Jun '24

*** BLURB HERE *** Dan Carpenter (1): speakup: Fix sizeof() vs ARRAY_SIZE() bug drivers/accessibility/speakup/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-6.6 0/1] CVE-2024-38587
by Chen Ridong 24 Jun '24

24 Jun '24

*** BLURB HERE *** Dan Carpenter (1): speakup: Fix sizeof() vs ARRAY_SIZE() bug drivers/accessibility/speakup/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS 0/2] net: lts v4.311 backport
by Dong Chenchen 24 Jun '24

24 Jun '24

net lts patch v4.311 backport Christophe JAILLET (1): net: sunrpc: Fix an off by one in rpc_sockaddr2uaddr() Shiming Cheng (1): ipv6: fib6_rules: flush route cache when rule is changed net/ipv6/fib6_rules.c | 6 ++++++ net/sunrpc/addr.c | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS] drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
by Pu Lehui 24 Jun '24

24 Jun '24

From: José Expósito <jose.exposito89(a)gmail.com> stable inclusion from stable-v4.19.228 commit ca63eeb70fcb53c42e1fe54e1735a54d8e7759fd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72C3 CVE: CVE-2022-48756 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5e761a2287234bc402ba7ef07129f5103bcd775c upstream. The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files") Addresses-Coverity-ID: 1493860 ("Null pointer dereference") Signed-off-by: José Expósito <jose.exposito89(a)gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Link: https://lore.kernel.org/r/20220116181844.7400-1-jose.exposito89@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c index 9a9fa0c75a13..fa0e33ca91ca 100644 --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c @@ -667,12 +667,14 @@ void __exit msm_dsi_phy_driver_unregister(void) int msm_dsi_phy_enable(struct msm_dsi_phy *phy, int src_pll_id, struct msm_dsi_phy_clk_request *clk_req) { - struct device *dev = &phy->pdev->dev; + struct device *dev; int ret; if (!phy || !phy->cfg->ops.enable) return -EINVAL; + dev = &phy->pdev->dev; + ret = dsi_phy_enable_resource(phy); if (ret) { dev_err(dev, "%s: resource enable failed, %d\n", -- 2.34.1

2 1

[PATCH OLK-5.10] fs: Use CHECK_DATA_CORRUPTION() when kernel bugs are detected
by liwei 24 Jun '24

24 Jun '24

From: Jann Horn <jannh(a)google.com> mainline inclusion from mainline-v6.3-rc1 commit 47d586913f2abec4d240bae33417f537fda987ec category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/IA5PIS CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Currently, filp_close() and generic_shutdown_super() use printk() to log messages when bugs are detected. This is problematic because infrastructure like syzkaller has no idea that this message indicates a bug. In addition, some people explicitly want their kernels to BUG() when kernel data corruption has been detected (CONFIG_BUG_ON_DATA_CORRUPTION). And finally, when generic_shutdown_super() detects remaining inodes on a system without CONFIG_BUG_ON_DATA_CORRUPTION, it would be nice if later accesses to a busy inode would at least crash somewhat cleanly rather than walking through freed memory. To address all three, use CHECK_DATA_CORRUPTION() when kernel bugs are detected. Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Christian Brauner (Microsoft) <brauner(a)kernel.org> Reviewed-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Christian Brauner (Microsoft) <brauner(a)kernel.org> Conflicts: include/linux/poison.h Signed-off-by: liwei <liwei728(a)huawei.com> --- fs/open.c | 5 +++-- fs/super.c | 21 +++++++++++++++++---- include/linux/poison.h | 3 +++ 3 files changed, 23 insertions(+), 6 deletions(-) diff --git a/fs/open.c b/fs/open.c index 8092178ceab0..926fd0598935 100644 --- a/fs/open.c +++ b/fs/open.c @@ -1285,8 +1285,9 @@ int filp_close(struct file *filp, fl_owner_t id) { int retval = 0; - if (!file_count(filp)) { - printk(KERN_ERR "VFS: Close: file count is 0\n"); + if (CHECK_DATA_CORRUPTION(file_count(filp) == 0, + "VFS: Close: file count is 0 (f_op=%ps)", + filp->f_op)) { return 0; } diff --git a/fs/super.c b/fs/super.c index db6345634f8b..db46a20da0c8 100644 --- a/fs/super.c +++ b/fs/super.c @@ -465,10 +465,23 @@ void generic_shutdown_super(struct super_block *sb) if (sop->put_super) sop->put_super(sb); - if (!list_empty(&sb->s_inodes)) { - printk("VFS: Busy inodes after unmount of %s. " - "Self-destruct in 5 seconds. Have a nice day...\n", - sb->s_id); + if (CHECK_DATA_CORRUPTION(!list_empty(&sb->s_inodes), + "VFS: Busy inodes after unmount of %s (%s)", + sb->s_id, sb->s_type->name)) { + /* + * Adding a proper bailout path here would be hard, but + * we can at least make it more likely that a later + * iput_final() or such crashes cleanly. + */ + struct inode *inode; + + spin_lock(&sb->s_inode_list_lock); + list_for_each_entry(inode, &sb->s_inodes, i_sb_list) { + inode->i_op = VFS_PTR_POISON; + inode->i_sb = VFS_PTR_POISON; + inode->i_mapping = VFS_PTR_POISON; + } + spin_unlock(&sb->s_inode_list_lock); } } spin_lock(&sb_lock); diff --git a/include/linux/poison.h b/include/linux/poison.h index 028133fb1405..a33190e56035 100644 --- a/include/linux/poison.h +++ b/include/linux/poison.h @@ -85,4 +85,7 @@ /********** net/core/page_pool.c **********/ #define PP_SIGNATURE (0x40 + POISON_POINTER_DELTA) +/********** VFS **********/ +#define VFS_PTR_POISON ((void *)(0xF5 + POISON_POINTER_DELTA)) + #endif -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] NFS: Fix an off by one in root_nfs_cat()
by Wang Zhaolong 24 Jun '24

24 Jun '24

From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> stable inclusion from stable-v4.19.311 commit 9bb320c5cea50e7fa82a477743a6a0546eaa37b3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA7XXI CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 698ad1a538da0b6bf969cfee630b4e3a026afb87 ] The intent is to check if 'dest' is truncated or not. So, >= should be used instead of >, because strlcat() returns the length of 'dest' and 'src' excluding the trailing NULL. Fixes: 56463e50d1fc ("NFS: Use super.c for NFSROOT mount option parsing") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Reviewed-by: Benjamin Coddington <bcodding(a)redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)hammerspace.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/nfs/nfsroot.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/nfs/nfsroot.c b/fs/nfs/nfsroot.c index effaa4247b91..c0f2e1751c33 100644 --- a/fs/nfs/nfsroot.c +++ b/fs/nfs/nfsroot.c @@ -169,10 +169,10 @@ static int __init root_nfs_cat(char *dest, const char *src, size_t len = strlen(dest); if (len && dest[len - 1] != ',') - if (strlcat(dest, ",", destlen) > destlen) + if (strlcat(dest, ",", destlen) >= destlen) return -1; - if (strlcat(dest, src, destlen) > destlen) + if (strlcat(dest, src, destlen) >= destlen) return -1; return 0; } -- 2.34.3

2 1

[PATCH OLK-6.6] block: refine the EOF check in blkdev_iomap_begin
by Li Nan 24 Jun '24

24 Jun '24

From: Christoph Hellwig <hch(a)lst.de> stable inclusion from stable-v6.6.33 commit 910717920c8c3f9386277a44c44d448058a18084 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SG8 CVE: CVE-2024-38604 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0c12028aec837f5a002009bbf68d179d506510e8 ] blkdev_iomap_begin rounds down the offset to the logical block size before stashing it in iomap->offset and checking that it still is inside the inode size. Check the i_size check to the raw pos value so that we don't try a zero size write if iter->pos is unaligned. Fixes: 487c607df790 ("block: use iomap for writes to block devices") Reported-by: syzbot+0a3683a0a6fecf909244(a)syzkaller.appspotmail.com Signed-off-by: Christoph Hellwig <hch(a)lst.de> Tested-by: syzbot+0a3683a0a6fecf909244(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20240503081042.2078062-1-hch@lst.de Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Nan <linan122(a)huawei.com> --- block/fops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/fops.c b/block/fops.c index 7e921f999182..33b724b1d963 100644 --- a/block/fops.c +++ b/block/fops.c @@ -387,7 +387,7 @@ static int blkdev_iomap_begin(struct inode *inode, loff_t offset, loff_t length, iomap->bdev = bdev; iomap->offset = ALIGN_DOWN(offset, bdev_logical_block_size(bdev)); - if (iomap->offset >= isize) + if (offset >= isize) return -EIO; iomap->type = IOMAP_MAPPED; iomap->addr = iomap->offset; -- 2.39.2

2 1

[PATCH OLK-6.6 0/1] vfio/pci: fix potential memory leak in vfio_intx_enable()
by Huang Xiaojia 24 Jun '24

24 Jun '24

*** BLURB HERE *** Ye Bin (1): vfio/pci: fix potential memory leak in vfio_intx_enable() drivers/vfio/pci/vfio_pci_intrs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-6.6] serial: max3100: Update uart_driver_registered on driver removal
by Yi Yang 24 Jun '24

24 Jun '24

From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> stable inclusion from stable-v6.6.33 commit e8a10089eddba40d4b2080c9d3fc2d2b2488f762 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D2Z CVE: CVE-2024-38633 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 712a1fcb38dc7cac6da63ee79a88708fbf9c45ec ] The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call. Fixes: 7831d56b0a35 ("tty: MAX3100") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20240402195306.269276-3-andriy.shevchenko@linux.i… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/max3100.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c index 5efb2b593be3..b6b395c59621 100644 --- a/drivers/tty/serial/max3100.c +++ b/drivers/tty/serial/max3100.c @@ -738,13 +738,14 @@ static int max3100_probe(struct spi_device *spi) mutex_lock(&max3100s_lock); if (!uart_driver_registered) { - uart_driver_registered = 1; retval = uart_register_driver(&max3100_uart_driver); if (retval) { printk(KERN_ERR "Couldn't register max3100 uart driver\n"); mutex_unlock(&max3100s_lock); return retval; } + + uart_driver_registered = 1; } for (i = 0; i < MAX_MAX3100; i++) @@ -830,6 +831,7 @@ static void max3100_remove(struct spi_device *spi) } pr_debug("removing max3100 driver\n"); uart_unregister_driver(&max3100_uart_driver); + uart_driver_registered = 0; mutex_unlock(&max3100s_lock); } -- 2.25.1

2 1

[PATCH OLK-5.10 0/1] vfio/pci: fix potential memory leak in vfio_intx_enable()
by Huang Xiaojia 24 Jun '24

24 Jun '24

*** BLURB HERE *** Ye Bin (1): vfio/pci: fix potential memory leak in vfio_intx_enable() drivers/vfio/pci/vfio_pci_intrs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/1] vfio/pci: fix potential memory leak in vfio_intx_enable()
by Huang Xiaojia 24 Jun '24

24 Jun '24

*** BLURB HERE *** Ye Bin (1): vfio/pci: fix potential memory leak in vfio_intx_enable() drivers/vfio/pci/vfio_pci_intrs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1] serial: max3100: Update uart_driver_registered on driver removal
by Yi Yang 24 Jun '24

24 Jun '24

From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> stable inclusion from stable-v5.10.219 commit e8e2a4339decad7e59425b594a98613402652d72 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D2Z CVE: CVE-2024-38633 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 712a1fcb38dc7cac6da63ee79a88708fbf9c45ec ] The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call. Fixes: 7831d56b0a35 ("tty: MAX3100") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20240402195306.269276-3-andriy.shevchenko@linux.i… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/max3100.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c index 371569a0fd00..fd1ce5ec3ba1 100644 --- a/drivers/tty/serial/max3100.c +++ b/drivers/tty/serial/max3100.c @@ -743,13 +743,14 @@ static int max3100_probe(struct spi_device *spi) mutex_lock(&max3100s_lock); if (!uart_driver_registered) { - uart_driver_registered = 1; retval = uart_register_driver(&max3100_uart_driver); if (retval) { printk(KERN_ERR "Couldn't register max3100 uart driver\n"); mutex_unlock(&max3100s_lock); return retval; } + + uart_driver_registered = 1; } for (i = 0; i < MAX_MAX3100; i++) @@ -835,6 +836,7 @@ static int max3100_remove(struct spi_device *spi) } pr_debug("removing max3100 driver\n"); uart_unregister_driver(&max3100_uart_driver); + uart_driver_registered = 0; mutex_unlock(&max3100s_lock); return 0; -- 2.25.1

2 1

[PATCH OLK-5.10] serial: max3100: Update uart_driver_registered on driver removal
by Yi Yang 24 Jun '24

24 Jun '24

From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> stable inclusion from stable-v5.10.219 commit e8e2a4339decad7e59425b594a98613402652d72 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D2Z CVE: CVE-2024-38633 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 712a1fcb38dc7cac6da63ee79a88708fbf9c45ec ] The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call. Fixes: 7831d56b0a35 ("tty: MAX3100") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20240402195306.269276-3-andriy.shevchenko@linux.i… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/max3100.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c index 371569a0fd00..fd1ce5ec3ba1 100644 --- a/drivers/tty/serial/max3100.c +++ b/drivers/tty/serial/max3100.c @@ -743,13 +743,14 @@ static int max3100_probe(struct spi_device *spi) mutex_lock(&max3100s_lock); if (!uart_driver_registered) { - uart_driver_registered = 1; retval = uart_register_driver(&max3100_uart_driver); if (retval) { printk(KERN_ERR "Couldn't register max3100 uart driver\n"); mutex_unlock(&max3100s_lock); return retval; } + + uart_driver_registered = 1; } for (i = 0; i < MAX_MAX3100; i++) @@ -835,6 +836,7 @@ static int max3100_remove(struct spi_device *spi) } pr_debug("removing max3100 driver\n"); uart_unregister_driver(&max3100_uart_driver); + uart_driver_registered = 0; mutex_unlock(&max3100s_lock); return 0; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] serial: max3100: Update uart_driver_registered on driver removal
by Yi Yang 24 Jun '24

24 Jun '24

From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> stable inclusion from stable-v4.19.316 commit 21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D2Z CVE: CVE-2024-38633 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 712a1fcb38dc7cac6da63ee79a88708fbf9c45ec ] The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call. Fixes: 7831d56b0a35 ("tty: MAX3100") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20240402195306.269276-3-andriy.shevchenko@linux.i… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/max3100.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c index 371569a0fd00..fd1ce5ec3ba1 100644 --- a/drivers/tty/serial/max3100.c +++ b/drivers/tty/serial/max3100.c @@ -743,13 +743,14 @@ static int max3100_probe(struct spi_device *spi) mutex_lock(&max3100s_lock); if (!uart_driver_registered) { - uart_driver_registered = 1; retval = uart_register_driver(&max3100_uart_driver); if (retval) { printk(KERN_ERR "Couldn't register max3100 uart driver\n"); mutex_unlock(&max3100s_lock); return retval; } + + uart_driver_registered = 1; } for (i = 0; i < MAX_MAX3100; i++) @@ -835,6 +836,7 @@ static int max3100_remove(struct spi_device *spi) } pr_debug("removing max3100 driver\n"); uart_unregister_driver(&max3100_uart_driver); + uart_driver_registered = 0; mutex_unlock(&max3100s_lock); return 0; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/1] vfio/pci: fix potential memory leak in vfio_intx_enable()
by Huang Xiaojia 24 Jun '24

24 Jun '24

*** BLURB HERE *** Ye Bin (1): vfio/pci: fix potential memory leak in vfio_intx_enable() drivers/vfio/pci/vfio_pci_intrs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-6.6 0/1] psi: using cpuacct_cgrp_id under CONFIG_CGROUP_CPUACCT
by Chen Ridong 24 Jun '24

24 Jun '24

*** BLURB HERE *** Joseph Qi (1): psi: using cpuacct_cgrp_id under CONFIG_CGROUP_CPUACCT kernel/sched/psi.c | 4 ++++ 1 file changed, 4 insertions(+) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1] RDMA/hns: Fix UAF for cq async event
by Zhengchao Shao 24 Jun '24

24 Jun '24

From: Chengchang Tang <tangchengchang(a)huawei.com> mainline inclusion from mainline-v6.10-rc1 commit a942ec2745ca864cd8512142100e4027dc306a42 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8C CVE: CVE-2024-38545 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF. Use the xa_lock() to protect the CQ refcount. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Chengchang Tang <tangchengchang(a)huawei.com> Signed-off-by: Junxian Huang <huangjunxian6(a)hisilicon.com> Link: https://lore.kernel.org/r/20240412091616.370789-6-huangjunxian6@hisilicon.c… Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Conflicts: drivers/infiniband/hw/hns/hns_roce_cq.c [The conflict occurs because the commit f0588567976e("RDMA/hns: Unified Log Printing Style") is not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/infiniband/hw/hns/hns_roce_cq.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/infiniband/hw/hns/hns_roce_cq.c b/drivers/infiniband/hw/hns/hns_roce_cq.c index 98dcbc40f964..01a18fbc5525 100644 --- a/drivers/infiniband/hw/hns/hns_roce_cq.c +++ b/drivers/infiniband/hw/hns/hns_roce_cq.c @@ -151,7 +151,7 @@ static int alloc_cqc(struct hns_roce_dev *hr_dev, struct hns_roce_cq *hr_cq) return ret; } - ret = xa_err(xa_store(&cq_table->array, hr_cq->cqn, hr_cq, GFP_KERNEL)); + ret = xa_err(xa_store_irq(&cq_table->array, hr_cq->cqn, hr_cq, GFP_KERNEL)); if (ret) { ibdev_err(ibdev, "failed to xa_store CQ, ret = %d.\n", ret); goto err_put; @@ -164,7 +164,7 @@ static int alloc_cqc(struct hns_roce_dev *hr_dev, struct hns_roce_cq *hr_cq) return 0; err_xa: - xa_erase(&cq_table->array, hr_cq->cqn); + xa_erase_irq(&cq_table->array, hr_cq->cqn); err_put: hns_roce_table_put(hr_dev, &cq_table->table, hr_cq->cqn); @@ -183,7 +183,7 @@ static void free_cqc(struct hns_roce_dev *hr_dev, struct hns_roce_cq *hr_cq) dev_err(dev, "DESTROY_CQ failed (%d) for CQN %06lx\n", ret, hr_cq->cqn); - xa_erase(&cq_table->array, hr_cq->cqn); + xa_erase_irq(&cq_table->array, hr_cq->cqn); /* Waiting interrupt process procedure carried out */ synchronize_irq(hr_dev->eq_table.eq[hr_cq->vector].irq); @@ -473,13 +473,6 @@ void hns_roce_cq_event(struct hns_roce_dev *hr_dev, u32 cqn, int event_type) struct ib_event event; struct ib_cq *ibcq; - hr_cq = xa_load(&hr_dev->cq_table.array, - cqn & (hr_dev->caps.num_cqs - 1)); - if (!hr_cq) { - dev_warn(dev, "Async event for bogus CQ 0x%06x\n", cqn); - return; - } - if (event_type != HNS_ROCE_EVENT_TYPE_CQ_ID_INVALID && event_type != HNS_ROCE_EVENT_TYPE_CQ_ACCESS_ERROR && event_type != HNS_ROCE_EVENT_TYPE_CQ_OVERFLOW) { @@ -488,7 +481,16 @@ void hns_roce_cq_event(struct hns_roce_dev *hr_dev, u32 cqn, int event_type) return; } - refcount_inc(&hr_cq->refcount); + xa_lock(&hr_dev->cq_table.array); + hr_cq = xa_load(&hr_dev->cq_table.array, + cqn & (hr_dev->caps.num_cqs - 1)); + if (hr_cq) + refcount_inc(&hr_cq->refcount); + xa_unlock(&hr_dev->cq_table.array); + if (!hr_cq) { + dev_warn(dev, "async event for bogus CQ 0x%06x\n", cqn); + return; + } ibcq = &hr_cq->ib_cq; if (ibcq->event_handler) { -- 2.34.1

2 1

[PATCH OLK-6.6] ALSA: core: Fix NULL module pointer assignment at card init
by Li Huafei 24 Jun '24

24 Jun '24

From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v6.6.33 commit e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5L CVE: CVE-2024-38605 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 39381fe7394e5eafac76e7e9367e7351138a29c1 upstream. The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare. Fixes: 81033c6b584b ("ALSA: core: Warn on empty module") Reported-by: Xu Yang <xu.yang_2(a)nxp.com> Closes: https://lore.kernel.org/r/20240520170349.2417900-1-xu.yang_2@nxp.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Tested-by: Xu Yang <xu.yang_2(a)nxp.com> Link: https://lore.kernel.org/r/20240522070442.17786-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- sound/core/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/core/init.c b/sound/core/init.c index 22c0d217b8608..f8dfc8d7010e2 100644 --- a/sound/core/init.c +++ b/sound/core/init.c @@ -312,8 +312,8 @@ static int snd_card_init(struct snd_card *card, struct device *parent, card->number = idx; #ifdef MODULE WARN_ON(!module); - card->module = module; #endif + card->module = module; INIT_LIST_HEAD(&card->devices); init_rwsem(&card->controls_rwsem); rwlock_init(&card->ctl_files_rwlock); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ALSA: core: Fix NULL module pointer assignment at card init
by Li Huafei 24 Jun '24

24 Jun '24

From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v5.10.219 commit d7ff29a429b56f04783152ad7bbd7233b740e434 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S5L CVE: CVE-2024-38605 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 39381fe7394e5eafac76e7e9367e7351138a29c1 upstream. The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare. Fixes: 81033c6b584b ("ALSA: core: Warn on empty module") Reported-by: Xu Yang <xu.yang_2(a)nxp.com> Closes: https://lore.kernel.org/r/20240520170349.2417900-1-xu.yang_2@nxp.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Tested-by: Xu Yang <xu.yang_2(a)nxp.com> Link: https://lore.kernel.org/r/20240522070442.17786-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- sound/core/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/core/init.c b/sound/core/init.c index 9f5270c90a10a..b6dd43005c272 100644 --- a/sound/core/init.c +++ b/sound/core/init.c @@ -206,8 +206,8 @@ int snd_card_new(struct device *parent, int idx, const char *xid, card->number = idx; #ifdef MODULE WARN_ON(!module); - card->module = module; #endif + card->module = module; INIT_LIST_HEAD(&card->devices); init_rwsem(&card->controls_rwsem); rwlock_init(&card->ctl_files_rwlock); -- 2.25.1

2 1