- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
by Wang Tao 26 Nov '25

26 Nov '25

From: Justin Tee <justin.tee(a)broadcom.com> mainline inclusion from mainline-v6.3-rc1 commit 21681b81b9ae548c5dae7ae00d931197a27f480c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICY9M3 CVE: CVE-2023-53282 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine: BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool. Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Conflicts: drivers/scsi/lpfc/lpfc_sli.c [Context conflicts.] Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- drivers/scsi/lpfc/lpfc_sli.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index 371bce9b7490..2602070506b1 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -19797,6 +19797,7 @@ lpfc_wr_object(struct lpfc_hba *phba, struct list_head *dmabuf_list, struct lpfc_mbx_wr_object *wr_object; LPFC_MBOXQ_t *mbox; int rc = 0, i = 0; + int mbox_status = 0; uint32_t shdr_status, shdr_add_status, shdr_change_status, shdr_csf; uint32_t mbox_tmo; struct lpfc_dmabuf *dmabuf; @@ -19841,11 +19842,15 @@ lpfc_wr_object(struct lpfc_hba *phba, struct list_head *dmabuf_list, wr_object->u.request.bde_count = i; bf_set(lpfc_wr_object_write_length, &wr_object->u.request, written); if (!phba->sli4_hba.intr_enable) - rc = lpfc_sli_issue_mbox(phba, mbox, MBX_POLL); + mbox_status = lpfc_sli_issue_mbox(phba, mbox, MBX_POLL); else { mbox_tmo = lpfc_mbox_tmo_val(phba, mbox); - rc = lpfc_sli_issue_mbox_wait(phba, mbox, mbox_tmo); + mbox_status = lpfc_sli_issue_mbox_wait(phba, mbox, mbox_tmo); } + + /* The mbox status needs to be maintained to detect MBOX_TIMEOUT. */ + rc = mbox_status; + /* The IOCTL status is embedded in the mailbox subheader. */ shdr_status = bf_get(lpfc_mbox_hdr_status, &wr_object->header.cfg_shdr.response); @@ -19890,10 +19895,7 @@ lpfc_wr_object(struct lpfc_hba *phba, struct list_head *dmabuf_list, break; } } - if (!phba->sli4_hba.intr_enable) - mempool_free(mbox, phba->mbox_mem_pool); - else if (rc != MBX_TIMEOUT) - mempool_free(mbox, phba->mbox_mem_pool); + if (shdr_status || shdr_add_status || rc) { lpfc_printf_log(phba, KERN_ERR, LOG_TRACE_EVENT, "3025 Write Object mailbox failed with " @@ -19903,6 +19905,12 @@ lpfc_wr_object(struct lpfc_hba *phba, struct list_head *dmabuf_list, *offset = shdr_add_status; } else *offset += wr_object->u.response.actual_write_length; + + if (!phba->sli4_hba.intr_enable) + mempool_free(mbox, phba->mbox_mem_pool); + else if (mbox_status != MBX_TIMEOUT) + mempool_free(mbox, phba->mbox_mem_pool); + return rc; } -- 2.34.1

2 1

[PATCH OLK-6.6] dm-stripe: fix a possible integer overflow
by Wang Tao 26 Nov '25

26 Nov '25

From: Mikulas Patocka <mpatocka(a)redhat.com> mainline inclusion from mainline-v6.17-rc7 commit 1071d560afb4c245c2076494226df47db5a35708 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID0U8Z CVE: CVE-2025-39940 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt; Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Reviewed-by: John Garry <john.g.garry(a)oracle.com> Suggested-by: Dongsheng Yang <dongsheng.yang(a)linux.dev> Cc: stable(a)vger.kernel.org Conflicts: drivers/md/dm-stripe.c [Context conflicts] Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- drivers/md/dm-stripe.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/md/dm-stripe.c b/drivers/md/dm-stripe.c index e2854a3cbd28..efc289c3a573 100644 --- a/drivers/md/dm-stripe.c +++ b/drivers/md/dm-stripe.c @@ -456,10 +456,13 @@ static void stripe_io_hints(struct dm_target *ti, struct queue_limits *limits) { struct stripe_c *sc = ti->private; - unsigned int chunk_size = sc->chunk_size << SECTOR_SHIFT; + unsigned int io_min, io_opt; - blk_limits_io_min(limits, chunk_size); - blk_limits_io_opt(limits, chunk_size * sc->stripes); + if (!check_shl_overflow(sc->chunk_size, SECTOR_SHIFT, &io_min) && + !check_mul_overflow(io_min, sc->stripes, &io_opt)) { + blk_limits_io_min(limits, io_min); + blk_limits_io_opt(limits, io_opt); + } } static struct target_type stripe_target = { -- 2.34.1

2 1

[PATCH OLK-6.6] sched/rt: Fix race in push_rt_task
by Wang Tao 26 Nov '25

26 Nov '25

From: Harshit Agarwal <harshit(a)nutanix.com> mainline inclusion from mainline-v6.16-rc1 commit 690e47d1403e90b7f2366f03b52ed3304194c793 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICK4N0 CVE: CVE-2025-38234 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Overview ======== When a CPU chooses to call push_rt_task and picks a task to push to another CPU's runqueue then it will call find_lock_lowest_rq method which would take a double lock on both CPUs' runqueues. If one of the locks aren't readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (on_rq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list. Crashes ======= This bug resulted in quite a few flavors of crashes triggering kernel panics with various crash signatures such as assert failures, page faults, null pointer dereferences, and queue corruption errors all coming from scheduler itself. Some of the crashes: -> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? pick_next_task_rt+0x6e/0x1d0 ? do_error_trap+0x64/0xa0 ? pick_next_task_rt+0x6e/0x1d0 ? exc_invalid_op+0x4c/0x60 ? pick_next_task_rt+0x6e/0x1d0 ? asm_exc_invalid_op+0x12/0x20 ? pick_next_task_rt+0x6e/0x1d0 __schedule+0x5cb/0x790 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: kernel NULL pointer dereference, address: 00000000000000c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? __warn+0x8a/0xe0 ? exc_page_fault+0x3d6/0x520 ? asm_exc_page_fault+0x1e/0x30 ? pick_next_task_rt+0xb5/0x1d0 ? pick_next_task_rt+0x8c/0x1d0 __schedule+0x583/0x7e0 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: unable to handle page fault for address: ffff9464daea5900 kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p)) -> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? dequeue_top_rt_rq+0xa2/0xb0 ? do_error_trap+0x64/0xa0 ? dequeue_top_rt_rq+0xa2/0xb0 ? exc_invalid_op+0x4c/0x60 ? dequeue_top_rt_rq+0xa2/0xb0 ? asm_exc_invalid_op+0x12/0x20 ? dequeue_top_rt_rq+0xa2/0xb0 dequeue_rt_entity+0x1f/0x70 dequeue_task_rt+0x2d/0x70 __schedule+0x1a8/0x7e0 ? blk_finish_plug+0x25/0x40 schedule+0x3c/0xb0 futex_wait_queue_me+0xb6/0x120 futex_wait+0xd9/0x240 do_futex+0x344/0xa90 ? get_mm_exe_file+0x30/0x60 ? audit_exe_compare+0x58/0x70 ? audit_filter_rules.constprop.26+0x65e/0x1220 __x64_sys_futex+0x148/0x1f0 do_syscall_64+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x62/0xc7 -> BUG: unable to handle page fault for address: ffff8cf3608bc2c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? spurious_kernel_fault+0x171/0x1c0 ? exc_page_fault+0x3b6/0x520 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? asm_exc_page_fault+0x1e/0x30 ? _cond_resched+0x15/0x30 ? futex_wait_queue_me+0xc8/0x120 ? futex_wait+0xd9/0x240 ? try_to_wake_up+0x1b8/0x490 ? futex_wake+0x78/0x160 ? do_futex+0xcd/0xa90 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? plist_del+0x6a/0xd0 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? dequeue_pushable_task+0x20/0x70 ? __schedule+0x382/0x7e0 ? asm_sysvec_reschedule_ipi+0xa/0x20 ? schedule+0x3c/0xb0 ? exit_to_user_mode_prepare+0x9e/0x150 ? irqentry_exit_to_user_mode+0x5/0x30 ? asm_sysvec_reschedule_ipi+0x12/0x20 Above are some of the common examples of the crashes that were observed due to this issue. Details ======= Let's look at the following scenario to understand this race. 1) CPU A enters push_rt_task a) CPU A has chosen next_task = task p. b) CPU A calls find_lock_lowest_rq(Task p, CPU Z’s rq). c) CPU A identifies CPU X as a destination CPU (X < Z). d) CPU A enters double_lock_balance(CPU Z’s rq, CPU X’s rq). e) Since X is lower than Z, CPU A unlocks CPU Z’s rq. Someone else has locked CPU X’s rq, and thus, CPU A must wait. 2) At CPU Z a) Previous task has completed execution and thus, CPU Z enters schedule, locks its own rq after CPU A releases it. b) CPU Z dequeues previous task and begins executing task p. c) CPU Z unlocks its rq. d) Task p yields the CPU (ex. by doing IO or waiting to acquire a lock) which triggers the schedule function on CPU Z. e) CPU Z enters schedule again, locks its own rq, and dequeues task p. f) As part of dequeue, it sets p.on_rq = 0 and unlocks its rq. 3) At CPU B a) CPU B enters try_to_wake_up with input task p. b) Since CPU Z dequeued task p, p.on_rq = 0, and CPU B updates B.state = WAKING. c) CPU B via select_task_rq determines CPU Y as the target CPU. 4) The race a) CPU A acquires CPU X’s lock and relocks CPU Z. b) CPU A reads task p.cpu = Z and incorrectly concludes task p is still on CPU Z. c) CPU A failed to notice task p had been dequeued from CPU Z while CPU A was waiting for locks in double_lock_balance. If CPU A knew that task p had been dequeued, it would return NULL forcing push_rt_task to give up the task p's migration. d) CPU B updates task p.cpu = Y and calls ttwu_queue. e) CPU B locks Ys rq. CPU B enqueues task p onto Y and sets task p.on_rq = 1. f) CPU B unlocks CPU Y, triggering memory synchronization. g) CPU A reads task p.on_rq = 1, cementing its assumption that task p has not migrated. h) CPU A decides to migrate p to CPU X. This leads to A dequeuing p from Y's queue and various crashes down the line. Solution ======== The solution here is fairly simple. After obtaining the lock (at 4a), the check is enhanced to make sure that the task is still at the head of the pushable tasks list. If not, then it is anyway not suitable for being pushed out. Testing ======= The fix is tested on a cluster of 3 nodes, where the panics due to this are hit every couple of days. A fix similar to this was deployed on such cluster and was stable for more than 30 days. Co-developed-by: Jon Kohler <jon(a)nutanix.com> Signed-off-by: Jon Kohler <jon(a)nutanix.com> Co-developed-by: Gauri Patwardhan <gauri.patwardhan(a)nutanix.com> Signed-off-by: Gauri Patwardhan <gauri.patwardhan(a)nutanix.com> Co-developed-by: Rahul Chunduru <rahul.chunduru(a)nutanix.com> Signed-off-by: Rahul Chunduru <rahul.chunduru(a)nutanix.com> Signed-off-by: Harshit Agarwal <harshit(a)nutanix.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> Reviewed-by: Phil Auld <pauld(a)redhat.com> Tested-by: Will Ton <william.ton(a)nutanix.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20250225180553.167995-1-harshit@nutanix.com Conflicts: kernel/sched/rt.c [The conflict is caused by not merging patch af0c8b2bf67b("sched: Split scheduler and execution contexts"), and it is a context conflict.] Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- kernel/sched/rt.c | 52 +++++++++++++++++++++++------------------------ 1 file changed, 25 insertions(+), 27 deletions(-) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index e2eaa8ffd009..549b9ecfda7d 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -1972,6 +1972,26 @@ static int find_lowest_rq(struct task_struct *task) return -1; } +static struct task_struct *pick_next_pushable_task(struct rq *rq) +{ + struct task_struct *p; + + if (!has_pushable_tasks(rq)) + return NULL; + + p = plist_first_entry(&rq->rt.pushable_tasks, + struct task_struct, pushable_tasks); + + BUG_ON(rq->cpu != task_cpu(p)); + BUG_ON(task_current(rq, p)); + BUG_ON(p->nr_cpus_allowed <= 1); + + BUG_ON(!task_on_rq_queued(p)); + BUG_ON(!rt_task(p)); + + return p; +} + /* Will lock the rq it finds */ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) { @@ -2002,18 +2022,16 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) /* * We had to unlock the run queue. In * the mean time, task could have - * migrated already or had its affinity changed. - * Also make sure that it wasn't scheduled on its rq. + * migrated already or had its affinity changed, + * therefore check if the task is still at the + * head of the pushable tasks list. * It is possible the task was scheduled, set * "migrate_disabled" and then got preempted, so we must * check the task migration disable flag here too. */ - if (unlikely(task_rq(task) != rq || + if (unlikely(is_migration_disabled(task) || !cpumask_test_cpu(lowest_rq->cpu, &task->cpus_mask) || - task_on_cpu(rq, task) || - !rt_task(task) || - is_migration_disabled(task) || - !task_on_rq_queued(task))) { + task != pick_next_pushable_task(rq))) { double_unlock_balance(rq, lowest_rq); lowest_rq = NULL; @@ -2033,26 +2051,6 @@ static struct rq *find_lock_lowest_rq(struct task_struct *task, struct rq *rq) return lowest_rq; } -static struct task_struct *pick_next_pushable_task(struct rq *rq) -{ - struct task_struct *p; - - if (!has_pushable_tasks(rq)) - return NULL; - - p = plist_first_entry(&rq->rt.pushable_tasks, - struct task_struct, pushable_tasks); - - BUG_ON(rq->cpu != task_cpu(p)); - BUG_ON(task_current(rq, p)); - BUG_ON(p->nr_cpus_allowed <= 1); - - BUG_ON(!task_on_rq_queued(p)); - BUG_ON(!rt_task(p)); - - return p; -} - /* * If the current CPU has more than one RT task, see if the non * running task can migrate over to a CPU that is running a task -- 2.34.1

2 1

[PATCH OLK-6.6] blk-ioinf: accumulate total latency properly across sampling periods
by Baokun Li 26 Nov '25

26 Nov '25

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/ID0C1D -------------------------------- QoS evaluation based on delta_stat should only be performed when the number of samples exceeds IOINF_MIN_SAMPLES. Otherwise, abnormal cases in small sample sets may cause overly aggressive adjustments. Therefore, when updating delta_stat, it is only reset if the number of I/Os exceeds IOINF_MIN_SAMPLES; otherwise, sampling results are accumulated across multiple periods until the total sample count reaches at least IOINF_MIN_SAMPLES. However, when accumulating across multiple periods, the average latency was treated as total latency, leading to underestimated values. Fix this by introducing a variable to track total latency. In addition, since the update logic for read and write is identical, a helper function ioinf_update_delta_io_stat() is added to avoid code duplication. Fixes: 4192ef0b0776 ("blk-ioinf: add rqos/inflight/stat debufs interface") Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- block/blk-ioinf.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/block/blk-ioinf.c b/block/blk-ioinf.c index 623c2715802b..1be9c690d8a4 100644 --- a/block/blk-ioinf.c +++ b/block/blk-ioinf.c @@ -680,20 +680,24 @@ static void ioinf_sample_cpu_lat(struct ioinf_lat_stat *cur, int cpu, cur->write.met += pstat->write.met; } +static inline void ioinf_update_delta_io_stat(struct ioinf_io_stat cur, + struct ioinf_io_stat last, struct ioinf_io_stat *delta) +{ + u64 lat = delta->nr * delta->lat; + + delta->nr += cur.nr - last.nr; + delta->met += cur.met - last.met; + if (delta->nr > 0) { + lat += cur.lat - last.lat; + delta->lat = div_u64(lat, delta->nr); + } +} + static void ioinf_update_delta_stat(struct ioinf_lat_stat *cur, struct ioinf_lat_stat *last, struct ioinf_lat_stat *delta) { - delta->read.nr += cur->read.nr - last->read.nr; - delta->read.met += cur->read.met - last->read.met; - delta->read.lat += cur->read.lat - last->read.lat; - if (delta->read.nr > 0) - delta->read.lat = div_u64(delta->read.lat, delta->read.nr); - - delta->write.nr += cur->write.nr - last->write.nr; - delta->write.met += cur->write.met - last->write.met; - delta->write.lat += cur->write.lat - last->write.lat; - if (delta->write.nr > 0) - delta->write.lat = div_u64(delta->write.lat, delta->write.nr); + ioinf_update_delta_io_stat(cur->read, last->read, &delta->read); + ioinf_update_delta_io_stat(cur->write, last->write, &delta->write); } static void ioinf_sample_lat(struct ioinf *inf) -- 2.46.1

2 1

[PATCH OLK-6.6] usbnet: Fix using smp_processor_id() in preemptible code warnings
by Jiacheng Yu 26 Nov '25

26 Nov '25

From: Zqiang <qiang.zhang(a)linux.dev> stable inclusion from stable-v6.17.5 commit 0134c7bff14bd50314a4f92b182850ddfc38e255 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID6BA2 CVE: CVE-2025-40164 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 327cd4b68b4398b6c24f10eb2b2533ffbfc10185 ] Syzbot reported the following warning: BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879 caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f For historical and portability reasons, the netif_rx() is usually run in the softirq or interrupt context, this commit therefore add local_bh_disable/enable() protection in the usbnet_resume_rx(). Fixes: 43daa96b166c ("usbnet: Stop RX Q on MTU change") Link: https://syzkaller.appspot.com/bug?id=81f55dfa587ee544baaaa5a359a060512228c1… Suggested-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Zqiang <qiang.zhang(a)linux.dev> Link: https://patch.msgid.link/20251011070518.7095-1-qiang.zhang@linux.dev Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- drivers/net/usb/usbnet.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index ac0458b96738..c4134303d395 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -702,6 +702,7 @@ void usbnet_resume_rx(struct usbnet *dev) struct sk_buff *skb; int num = 0; + local_bh_disable(); clear_bit(EVENT_RX_PAUSED, &dev->flags); while ((skb = skb_dequeue(&dev->rxq_pause)) != NULL) { @@ -710,6 +711,7 @@ void usbnet_resume_rx(struct usbnet *dev) } tasklet_schedule(&dev->bh); + local_bh_enable(); netif_dbg(dev, rx_status, dev->net, "paused rx queue disabled, %d skbs requeued\n", num); -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] sched: Fix race between yield_to() and try_to_wake_up()
by Xia Fukun 26 Nov '25

26 Nov '25

From: Tianchen Ding <dtcccc(a)linux.alibaba.com> mainline inclusion from mainline-v6.18-rc1 commit 5d808c78d97251af1d3a3e4f253e7d6c39fd871e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID8CE7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- We met a SCHED_WARN in set_next_buddy(): __warn_printk set_next_buddy yield_to_task_fair yield_to kvm_vcpu_yield_to [kvm] ... After a short dig, we found the rq_lock held by yield_to() may not be exactly the rq that the target task belongs to. There is a race window against try_to_wake_up(). CPU0 target_task blocking on CPU1 lock rq0 & rq1 double check task_rq == p_rq, ok woken to CPU2 (lock task_pi & rq2) task_rq = rq2 yield_to_task_fair (w/o lock rq2) In this race window, yield_to() is operating the task w/o the correct lock. Fix this by taking task pi_lock first. Fixes: d95f41220065 ("sched: Add yield_to(task, preempt) functionality") Signed-off-by: Tianchen Ding <dtcccc(a)linux.alibaba.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/20241231055020.6521-1-dtcccc@linux.alibaba.com Conflicts: kernel/sched/syscalls.c kernel/sched/core.c [Context differences.] Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- kernel/sched/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 4149f554debd..f7fa066b05ba 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5144,7 +5144,7 @@ int __sched yield_to(struct task_struct *p, bool preempt) unsigned long flags; int yielded = 0; - local_irq_save(flags); + raw_spin_lock_irqsave(&p->pi_lock, flags); rq = this_rq(); again: @@ -5187,7 +5187,7 @@ int __sched yield_to(struct task_struct *p, bool preempt) out_unlock: double_rq_unlock(rq, p_rq); out_irq: - local_irq_restore(flags); + raw_spin_unlock_irqrestore(&p->pi_lock, flags); if (yielded > 0) schedule(); -- 2.34.1

2 1

[PATCH OLK-6.6 00/11] xsched: XCU Partition
by Zicheng Qu 26 Nov '25

26 Nov '25

Zicheng Qu (11): xsched: unify log prefix format and remove duplicated prefix macros xsched: enforce valid xsched scheduler config dependencies xsched: add missing spin_unlock() in xcu_move_task() error path xsched: avoid sleeping while holding spinlock in xcu_move_task() xsched: remove parent->lock and rely on cgroup_mutex for shares update xsched: unify root detection logic for cgroups xsched: replace hard-coded numeric values xsched: modify the logic for inc and dec the count value xsched: add null check for sched in xsched_xse_set_class xsched: rename vstream->id to vstream->sq_id xsched: move stream_lock into xsched_vsm_add_tail() to avoid sleeping in atomic context arch/arm64/configs/openeuler_defconfig | 6 +- arch/x86/configs/openeuler_defconfig | 6 +- drivers/xcu/xcu_group.c | 2 + include/linux/vstream.h | 2 +- include/linux/xsched.h | 76 ++++++++--------------- kernel/xsched/Kconfig | 14 ++++- kernel/xsched/cgroup.c | 79 ++++++++++-------------- kernel/xsched/core.c | 83 ++++++++++++++------------ kernel/xsched/vstream.c | 29 +++------ 9 files changed, 134 insertions(+), 163 deletions(-) -- 2.34.1

2 12

[PATCH OLK-6.6 0/3] fix cve-2025-40300
by Bowen You 26 Nov '25

26 Nov '25

fix cve 2025-40300 Pawan Gupta (3): x86/vmscape: Add conditional IBPB mitigation x86/vmscape: Enumerate VMSCAPE bug x86/vmscape: Enable the mitigation .../ABI/testing/sysfs-devices-system-cpu | 1 + .../admin-guide/kernel-parameters.txt | 11 +++ arch/x86/Kconfig | 9 ++ arch/x86/include/asm/cpufeatures.h | 2 + arch/x86/include/asm/entry-common.h | 7 ++ arch/x86/include/asm/nospec-branch.h | 2 + arch/x86/kernel/cpu/bugs.c | 85 +++++++++++++++++++ arch/x86/kernel/cpu/common.c | 58 +++++++++---- arch/x86/kvm/x86.c | 9 ++ drivers/base/cpu.c | 3 + 10 files changed, 169 insertions(+), 18 deletions(-) -- 2.34.1

2 4

[PATCH OLK-5.10 0/8] fix cves
by Wupeng Ma 26 Nov '25

26 Nov '25

fix the fellowing cves: - CVE-2025-38084 - CVE-2025-21693 - CVE-2021-47653 Chengming Zhou (1): mm/zswap: change per-cpu mutex and buffer to per-acomp_ctx Dmitry Nikiforov (1): media: davinci: vpif: Fix memory leak in probe error path James Houghton (1): hugetlb: unshare some PMDs when splitting VMAs Jann Horn (1): mm/hugetlb: unshare page tables during VMA split, not before Johan Hovold (1): media: davinci: vpif: fix use-after-free on driver unbind Yosry Ahmed (3): mm: zswap: properly synchronize freeing resources during CPU hotunplug mm: zswap: move allocations during CPU init outside the lock mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead() drivers/media/platform/davinci/vpif.c | 99 ++++++++++---- include/linux/cpuhotplug.h | 2 +- include/linux/hugetlb.h | 6 + mm/hugetlb.c | 92 +++++++++++++ mm/mmap.c | 8 ++ mm/zswap.c | 186 ++++++++++++++------------ 6 files changed, 280 insertions(+), 113 deletions(-) -- 2.43.0

2 9

[PATCH OLK-6.6 0/5] fix cves
by Wupeng Ma 26 Nov '25

26 Nov '25

fix the fellowing cves: - CVE-2025-38084 - CVE-2025-21693 - CVE-2021-47653 Chengming Zhou (1): mm/zswap: change per-cpu mutex and buffer to per-acomp_ctx Jann Horn (1): mm/hugetlb: unshare page tables during VMA split, not before Yosry Ahmed (3): mm: zswap: properly synchronize freeing resources during CPU hotunplug mm: zswap: move allocations during CPU init outside the lock mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead() include/linux/cpuhotplug.h | 2 +- include/linux/hugetlb.h | 3 + mm/hugetlb.c | 60 ++++++++---- mm/mmap.c | 6 ++ mm/zswap.c | 187 ++++++++++++++++++++----------------- 5 files changed, 154 insertions(+), 104 deletions(-) -- 2.43.0

2 6