- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL
by Li Lingfeng 04 Jan '26

04 Jan '26

From: Chuck Lever <chuck.lever(a)oracle.com> stable inclusion from stable-v5.10.220 commit 50827896c365e0f6c8b55ed56d444dafd87c92c5 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/7998 CVE: CVE-2023-53680 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 804d8e0a6e54427268790472781e03bc243f4ee3 ] OPDESC() simply indexes into nfsd4_ops[] by the op's operation number, without range checking that value. It assumes callers are careful to avoid calling it with an out-of-bounds opnum value. nfsd4_decode_compound() is not so careful, and can invoke OPDESC() with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end of nfsd4_ops[]. Reported-by: Jeff Layton <jlayton(a)kernel.org> Fixes: f4f9ef4a1b0a ("nfsd4: opdesc will be useful outside nfs4proc.c") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/nfsd/nfs4xdr.c [Commit 3a237b4af5b7 ("NFSD: Make nfsd4_ops::opnum a u32") change the way to get opnum.] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/nfs4xdr.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c index 31d56546021b..821c0ad5baa0 100644 --- a/fs/nfsd/nfs4xdr.c +++ b/fs/nfsd/nfs4xdr.c @@ -2244,17 +2244,19 @@ nfsd4_decode_compound(struct nfsd4_compoundargs *argp) for (i = 0; i < argp->opcnt; i++) { op = &argp->ops[i]; op->replay = NULL; + op->opdesc = NULL; READ_BUF(4); op->opnum = be32_to_cpup(p++); - if (nfsd4_opnum_in_range(argp, op)) + if (nfsd4_opnum_in_range(argp, op)) { + op->opdesc = OPDESC(op); op->status = nfsd4_dec_ops[op->opnum](argp, &op->u); - else { + } else { op->opnum = OP_ILLEGAL; op->status = nfserr_op_illegal; } - op->opdesc = OPDESC(op); + /* * We'll try to cache the result in the DRC if any one * op in the compound wants to be cached: -- 2.52.0

2 1

[PATCH OLK-6.6] net_sched: prio: fix a race in prio_tune()
by Zhang Changzhong 04 Jan '26

04 Jan '26

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v6.6.94 commit 46c15c9d0f65c9ba857d63f53264f4b17e8a715f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/12473 CVE: CVE-2025-38083 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d35acc1be3480505b5931f17e4ea9b7617fea4d3 ] Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: 7b8e0b6e6599 ("net: sched: prio: delay destroying child qdiscs on change") Reported-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Suggested-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20250611111515.1983366-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- net/sched/sch_prio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c index fdc5ef5..fdd9caa 100644 --- a/net/sched/sch_prio.c +++ b/net/sched/sch_prio.c @@ -211,7 +211,7 @@ static int prio_tune(struct Qdisc *sch, struct nlattr *opt, memcpy(q->prio2band, qopt->priomap, TC_PRIO_MAX+1); for (i = q->bands; i < oldbands; i++) - qdisc_tree_flush_backlog(q->queues[i]); + qdisc_purge_queue(q->queues[i]); for (i = oldbands; i < q->bands; i++) { q->queues[i] = queues[i]; -- 2.9.5

2 1

[PATCH OLK-6.6 0/2] CVE-2025-39925
by Zhang Changzhong 04 Jan '26

04 Jan '26

Tetsuo Handa (2): can: j1939: implement NETDEV_UNREGISTER notification handler can: j1939: add missing calls in NETDEV_UNREGISTER notification handler net/can/j1939/j1939-priv.h | 1 + net/can/j1939/main.c | 5 +++++ net/can/j1939/socket.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 55 insertions(+) -- 2.9.5

2 3

[PATCH OLK-6.6] Bluetooth: hci_core: Disable works on hci_unregister_dev
by Zhang Changzhong 04 Jan '26

04 Jan '26

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> mainline inclusion from mainline-v6.12-rc5 commit 989fa5171f005ecf63440057218d8aeb1795287d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/8399 CVE: CVE-2024-58241 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This make use of disable_work_* on hci_unregister_dev since the hci_dev is about to be freed new submissions are not disarable. Fixes: 0d151a103775 ("Bluetooth: hci_core: cancel all works upon hci_unregister_dev()") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Conflicts: net/bluetooth/hci_sync.c [commit 78db544b5d27 ("Bluetooth: hci_core: Remove le_restart_scan work") and f2d897753586 ("Bluetooth: hci_sync: Remove remaining dependencies of hci_request") not merged] Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- net/bluetooth/hci_core.c | 24 +++++++++++++++--------- net/bluetooth/hci_sync.c | 15 +++++++++++---- 2 files changed, 26 insertions(+), 13 deletions(-) diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index c5e3ae5..4b4e3579 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -1638,12 +1638,12 @@ void hci_adv_instances_clear(struct hci_dev *hdev) struct adv_info *adv_instance, *n; if (hdev->adv_instance_timeout) { - cancel_delayed_work(&hdev->adv_instance_expire); + disable_delayed_work(&hdev->adv_instance_expire); hdev->adv_instance_timeout = 0; } list_for_each_entry_safe(adv_instance, n, &hdev->adv_instances, list) { - cancel_delayed_work_sync(&adv_instance->rpa_expired_cb); + disable_delayed_work_sync(&adv_instance->rpa_expired_cb); list_del(&adv_instance->list); kfree(adv_instance); } @@ -2670,11 +2670,11 @@ void hci_unregister_dev(struct hci_dev *hdev) list_del(&hdev->list); write_unlock(&hci_dev_list_lock); - cancel_work_sync(&hdev->rx_work); - cancel_work_sync(&hdev->cmd_work); - cancel_work_sync(&hdev->tx_work); - cancel_work_sync(&hdev->power_on); - cancel_work_sync(&hdev->error_reset); + disable_work_sync(&hdev->rx_work); + disable_work_sync(&hdev->cmd_work); + disable_work_sync(&hdev->tx_work); + disable_work_sync(&hdev->power_on); + disable_work_sync(&hdev->error_reset); hci_cmd_sync_clear(hdev); @@ -2781,8 +2781,14 @@ static void hci_cancel_cmd_sync(struct hci_dev *hdev, int err) { bt_dev_dbg(hdev, "err 0x%2.2x", err); - cancel_delayed_work_sync(&hdev->cmd_timer); - cancel_delayed_work_sync(&hdev->ncmd_timer); + if (hci_dev_test_flag(hdev, HCI_UNREGISTER)) { + disable_delayed_work_sync(&hdev->cmd_timer); + disable_delayed_work_sync(&hdev->ncmd_timer); + } else { + cancel_delayed_work_sync(&hdev->cmd_timer); + cancel_delayed_work_sync(&hdev->ncmd_timer); + } + atomic_set(&hdev->cmd_cnt, 1); hci_cmd_sync_cancel_sync(hdev, err); diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index e086f29..9d31b78 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -5158,10 +5158,17 @@ int hci_dev_close_sync(struct hci_dev *hdev) bt_dev_dbg(hdev, ""); - cancel_delayed_work(&hdev->power_off); - cancel_delayed_work(&hdev->ncmd_timer); - cancel_delayed_work(&hdev->le_scan_disable); - cancel_delayed_work(&hdev->le_scan_restart); + if (hci_dev_test_flag(hdev, HCI_UNREGISTER)) { + disable_delayed_work(&hdev->power_off); + disable_delayed_work(&hdev->ncmd_timer); + disable_delayed_work(&hdev->le_scan_disable); + disable_delayed_work(&hdev->le_scan_restart); + } else { + cancel_delayed_work(&hdev->power_off); + cancel_delayed_work(&hdev->ncmd_timer); + cancel_delayed_work(&hdev->le_scan_disable); + cancel_delayed_work(&hdev->le_scan_restart); + } hci_request_cancel_all(hdev); -- 2.9.5

2 1

[PATCH OLK-6.6] iomap: fix dirty range tracking in iomap_folio_mkwrite_iter
by Long Li 04 Jan '26

04 Jan '26

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IDCSJV ----------------------------------------- When I test xfs with fsstress, got the following assert message: XFS (sda): ino 1a0b0a data fork has delalloc extent at [0x186:0x1] XFS: Assertion failed: 0, file: fs/xfs/xfs_icache.c, line: 1819 ------------[ cut here ]------------ kernel BUG at fs/xfs/xfs_message.c:102! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 3 PID: 940 Comm: kworker/3:1 Not tainted 6.6.0-g3697dae9bfac #192 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: xfs-inodegc/sda xfs_inodegc_worker RIP: 0010:assfail+0x54/0x60 RSP: 0018:ffffc90003113e08 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff8880651dd800 RCX: 000000007fffffff RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff82a12e0c RBP: ffffffffffffff20 R08: 00000000000025c2 R09: 0000000000000000 R10: 000000000000000a R11: 000000000000000a R12: 0000000000000000 R13: ffffffffffffff20 R14: ffff888077948000 R15: 0000000004208060 FS: 0000000000000000(0000) GS:ffff8880bcb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000561be0e1cf30 CR3: 0000000075fa4000 CR4: 00000000000006e0 Call Trace: <TASK> xfs_inodegc_set_reclaimable+0x1f1/0x220 xfs_inodegc_worker+0x10b/0x2e0 process_scheduled_works+0x1a5/0x5e0 worker_thread+0x1d1/0x4f0 ? apply_workqueue_attrs+0x70/0x70 kthread+0x149/0x1c0 ? kthread_exit+0x50/0x50 ret_from_fork+0x52/0x70 ? kthread_exit+0x50/0x50 ret_from_fork_asm+0x11/0x20 </TASK> Fix the incorrect dirty range tracking in iomap_folio_mkwrite_iter() which could lead to blocks being missed during writeback. Previously, iomap_set_range_dirty() was called with a wrong offset (0), which may cause some modified blocks not being marked as dirty and thus skip writeback. Calculate the correct offset within the folio from the iterator position to ensure all modified blocks are properly marked dirty and written back. Fixes: 0b4d2d8fba90 ("iomap: correct the dirty length in page mkwrite") Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/iomap/buffered-io.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 7a417bd8a9f3..33fbb3f8d45f 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -1562,10 +1562,12 @@ static loff_t iomap_folio_mkwrite_iter(struct iomap_iter *iter, return ret; block_commit_write(&folio->page, 0, length); } else { + size_t poff = offset_in_folio(folio, iter->pos); + WARN_ON_ONCE(!folio_test_uptodate(folio)); ifs_alloc(iter->inode, folio, 0); - iomap_set_range_dirty(folio, 0, length); + iomap_set_range_dirty(folio, poff, length); } return length; -- 2.39.2

2 1

[PATCH OLK-5.10] mm: mem_reliable: prevent excessive direct reclaim loops
by Wupeng Ma 04 Jan '26

04 Jan '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/5441 ------------------------------------------ In our testing, under memory pressure, it becomes difficult totrigger an OOM(out-of-memory) kill when regular memory allocation competes concurrently with driver GFP_ATOMIC allocations. This occurs because GFP_ATOMIC allocations can succeed from as low as 3/8 of the min watermark. In such a situation, even if direct reclaim can free a small number of pages, regular memory requests may still fail because the current watermark remains too high for them. In the following scenario: restart: __alloc_pages_direct_reclaim // reclaims a small number of pages should_reclaim_retry // watermark too high for user // resets no_progress_loops to zero and // goes to restart goto restart; In our production environment, we encountered a case where memory allocation performed __alloc_pages_direct_reclaim 257 times without either succeeding or triggering OOM, causing service freezes. To avoid meaningless continuous direct reclaim loops, skip watermark check for non mirrored zone if memory reliable enabled. Fixes: 6c59ddf2139d ("mm: Introduce memory reliable") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- mm/page_alloc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index d6b23b59ae42..72d5303f8000 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4630,6 +4630,9 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order, unsigned long min_wmark = min_wmark_pages(zone); bool wmark; + if (skip_none_movable_zone(gfp_mask, z)) + continue; + available = reclaimable = zone_reclaimable_pages(zone); available += zone_page_state_snapshot(zone, NR_FREE_PAGES); -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] mm: mem_reliable: prevent excessive direct reclaim loops
by Wupeng Ma 04 Jan '26

04 Jan '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/5441 ------------------------------------------ In our testing, under memory pressure, it becomes difficult totrigger an OOM(out-of-memory) kill when regular memory allocation competes concurrently with driver GFP_ATOMIC allocations. This occurs because GFP_ATOMIC allocations can succeed from as low as 3/8 of the min watermark. In such a situation, even if direct reclaim can free a small number of pages, regular memory requests may still fail because the current watermark remains too high for them. In the following scenario: restart: __alloc_pages_direct_reclaim // reclaims a small number of pages should_reclaim_retry // watermark too high for user // resets no_progress_loops to zero and // goes to restart goto restart; In our production environment, we encountered a case where memory allocation performed __alloc_pages_direct_reclaim 257 times without either succeeding or triggering OOM, causing service freezes. To avoid meaningless continuous direct reclaim loops, skip watermark check for non mirrored zone if memory reliable enabled. Fixes: 33d1f46ad98e ("mm: Introduce memory reliable") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- mm/page_alloc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 787bbabc29d0..c2577d3048d9 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4256,6 +4256,9 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order, unsigned long min_wmark = min_wmark_pages(zone); bool wmark; + if (skip_none_movable_zone(gfp_mask, z)) + continue; + available = reclaimable = zone_reclaimable_pages(zone); available += zone_page_state_snapshot(zone, NR_FREE_PAGES); -- 2.43.0

2 1

[PATCH OLK-6.6 0/3] bugfix for memory reliable
by Wupeng Ma 04 Jan '26

04 Jan '26

Fix three bugs for memory reliable. Wupeng Ma (3): mm: mem_reliable: fix task reliable counter during fork mm: mem_reliable: use percise count during limit check mm: mem_reliable: prevent excessive direct reclaim loops include/linux/mem_reliable.h | 10 +++++++--- mm/memory.c | 4 +++- mm/page_alloc.c | 3 +++ 3 files changed, 13 insertions(+), 4 deletions(-) -- 2.43.0

2 4

[PATCH openEuler-1.0-LTS] mm/mem_reliable: use percise count during limit check
by Wupeng Ma 04 Jan '26

04 Jan '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/5441 -------------------------------- If the fallback for memory reliable is enabled, direct reclaim will be used if the task's reliable memory limit is reached and pages need to be released. However, percpu_counter_read_positive() provides a fast but imprecise counter reading. During limit enforcement, this inaccuracy may cause the observed usage to appear significantly larger than the actual value. As a result, even repeated constrained reclaim attempts may fail to bring memory usage below the limit, eventually leading to OOM. To avoid this issue, use an accurate counter check when determining whether the reliable memory limit has been exceeded. Fixes: 875ffd41499e ("mm: Do limit checking after memory allocation for memory reliable") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- include/linux/mem_reliable.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/linux/mem_reliable.h b/include/linux/mem_reliable.h index c0eff851bbe7..d70146a59a3e 100644 --- a/include/linux/mem_reliable.h +++ b/include/linux/mem_reliable.h @@ -84,8 +84,9 @@ static inline bool reliable_mem_limit_check(unsigned long nr_page) { s64 num; - num = percpu_counter_read_positive(&pagecache_reliable_pages); - num += percpu_counter_read_positive(&anon_reliable_pages); + /* limit check need precise counter, use sum rather than read */ + num = percpu_counter_sum_positive(&pagecache_reliable_pages); + num += percpu_counter_sum_positive(&anon_reliable_pages); return num + nr_page <= task_reliable_limit / PAGE_SIZE; } -- 2.43.0

2 1

[openeuler:OLK-6.6 18/18] kernel/sched/fair.c:146:12: warning: 'hundred_thousand' defined but not used
by kernel test robot 01 Jan '26

01 Jan '26

Hi Zhang, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 5078a3a23a1e1825ec136485173ec98668cdd640 commit: a3c9f2da0a35df4e41751556be4308f57bdaf3d6 [18/18] sched: Introduce handle priority reversion mechanism config: loongarch-randconfig-r133-20260101 (https://download.01.org/0day-ci/archive/20260101/202601011044.V6fvcOo6-lkp@…) compiler: loongarch64-linux-gcc (GCC) 13.4.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260101/202601011044.V6fvcOo6-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202601011044.V6fvcOo6-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/sched/fair.c:146:12: warning: 'hundred_thousand' defined but not used [-Wunused-variable] 146 | static int hundred_thousand = 100000; | ^~~~~~~~~~~~~~~~ >> kernel/sched/fair.c:145:12: warning: 'one_thousand' defined but not used [-Wunused-variable] 145 | static int one_thousand = 1000; | ^~~~~~~~~~~~ vim +/hundred_thousand +146 kernel/sched/fair.c 139 140 static DEFINE_PER_CPU_SHARED_ALIGNED(struct list_head, qos_throttled_cfs_rq); 141 static DEFINE_PER_CPU_SHARED_ALIGNED(struct hrtimer, qos_overload_timer); 142 static DEFINE_PER_CPU(int, qos_cpu_overload); 143 unsigned int sysctl_overload_detect_period = 5000; /* in ms */ 144 unsigned int sysctl_offline_wait_interval = 100; /* in ms */ > 145 static int one_thousand = 1000; > 146 static int hundred_thousand = 100000; 147 static int unthrottle_qos_cfs_rqs(int cpu); 148 #endif 149 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0