- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 1823/1823] include/../drivers/pci/msi/msi.h:113:57: warning: declaration of 'struct msix_entry' will not be visible outside of this function
by kernel test robot 14 Jan '25

14 Jan '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 4fbc633527d173d6e350da6be39009c6a449a802 commit: ad540a13eb8292fc92651b3bf281088a502a85f9 [1823/1823] virtcca feature: fix msi iova map config: arm64-randconfig-004-20250114 (https://download.01.org/0day-ci/archive/20250114/202501140558.Dz2Pe9bS-lkp@…) compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project f5cd181ffbb7cb61d582fe130d46580d5969d47a) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250114/202501140558.Dz2Pe9bS-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/202501140558.Dz2Pe9bS-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from drivers/coda/coda_pci.c:5: In file included from include/linux/kvm_host.h:16: In file included from include/linux/mm.h:2243: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/coda/coda_pci.c:8: >> include/../drivers/pci/msi/msi.h:113:57: warning: declaration of 'struct msix_entry' will not be visible outside of this function [-Wvisibility] 113 | int __pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries, int minvec, | ^ 6 warnings generated. vim +113 include/../drivers/pci/msi/msi.h 897a0b6aa8c7ee Ahmed S. Darwish 2022-11-11 107 b12d0bec385b7a Ahmed S. Darwish 2022-11-11 108 /* MSI internal functions invoked from the public APIs */ b12d0bec385b7a Ahmed S. Darwish 2022-11-11 109 void pci_msi_shutdown(struct pci_dev *dev); 18e1926b8c8b7c Ahmed S. Darwish 2022-11-11 110 void pci_msix_shutdown(struct pci_dev *dev); b12d0bec385b7a Ahmed S. Darwish 2022-11-11 111 void pci_free_msi_irqs(struct pci_dev *dev); bbda3407982211 Ahmed S. Darwish 2022-11-11 112 int __pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec, struct irq_affinity *affd); be7496c1ef47e1 Ahmed S. Darwish 2022-11-11 @113 int __pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries, int minvec, be7496c1ef47e1 Ahmed S. Darwish 2022-11-11 114 int maxvec, struct irq_affinity *affd, int flags); 57127da98bc876 Ahmed S. Darwish 2022-11-11 115 void __pci_restore_msi_state(struct pci_dev *dev); 57127da98bc876 Ahmed S. Darwish 2022-11-11 116 void __pci_restore_msix_state(struct pci_dev *dev); b12d0bec385b7a Ahmed S. Darwish 2022-11-11 117 :::::: The code at line 113 was first introduced by commit :::::: be7496c1ef47e1ba8c4b389ee23178fcf066cc4e PCI/MSI: Move pci_enable_msix_range() to api.c :::::: TO: Ahmed S. Darwish <darwi(a)linutronix.de> :::::: CC: Thomas Gleixner <tglx(a)linutronix.de> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] [Backport] btrfs: check folio mapping after unlock in relocate_one_folio()
by Yongjian Sun 13 Jan '25

13 Jan '25

mainline inclusion from mainline-v6.12-rc3 commit 3e74859ee35edc33a022c3f3971df066ea0ca6b9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBG2PL CVE: CVE-2024-56758 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When we call btrfs_read_folio() to bring a folio uptodate, we unlock the folio. The result of that is that a different thread can modify the mapping (like remove it with invalidate) before we call folio_lock(). This results in an invalid page and we need to try again. In particular, if we are relocating concurrently with aborting a transaction, this can result in a crash like the following: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 76 PID: 1411631 Comm: kworker/u322:5 Workqueue: events_unbound btrfs_reclaim_bgs_work RIP: 0010:set_page_extent_mapped+0x20/0xb0 RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246 RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880 RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0 R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000 R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die+0x78/0xc0 ? page_fault_oops+0x2a8/0x3a0 ? __switch_to+0x133/0x530 ? wq_worker_running+0xa/0x40 ? exc_page_fault+0x63/0x130 ? asm_exc_page_fault+0x22/0x30 ? set_page_extent_mapped+0x20/0xb0 relocate_file_extent_cluster+0x1a7/0x940 relocate_data_extent+0xaf/0x120 relocate_block_group+0x20f/0x480 btrfs_relocate_block_group+0x152/0x320 btrfs_relocate_chunk+0x3d/0x120 btrfs_reclaim_bgs_work+0x2ae/0x4e0 process_scheduled_works+0x184/0x370 worker_thread+0xc6/0x3e0 ? blk_add_timer+0xb0/0xb0 kthread+0xae/0xe0 ? flush_tlb_kernel_range+0x90/0x90 ret_from_fork+0x2f/0x40 ? flush_tlb_kernel_range+0x90/0x90 ret_from_fork_asm+0x11/0x20 </TASK> This occurs because cleanup_one_transaction() calls destroy_delalloc_inodes() which calls invalidate_inode_pages2() which takes the folio_lock before setting mapping to NULL. We fail to check this, and subsequently call set_extent_mapping(), which assumes that mapping != NULL (in fact it asserts that in debug mode) Note that the "fixes" patch here is not the one that introduced the race (the very first iteration of this code from 2009) but a more recent change that made this particular crash happen in practice. Fixes: e7f1326cc24e ("btrfs: set page extent mapped after read_folio in relocate_one_page") CC: stable(a)vger.kernel.org # 6.1+ Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: Boris Burkov <boris(a)bur.io> Signed-off-by: David Sterba <dsterba(a)suse.com> Conflicts: fs/btrfs/relocation.c [The Evolution from Page to Folio] Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/btrfs/relocation.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index a67dd544a52d..48915256fd8b 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -2732,7 +2732,7 @@ static int relocate_file_extent_cluster(struct inode *inode, PAGE_SIZE); if (ret) goto out; - +again: page = find_lock_page(inode->i_mapping, index); if (!page) { page_cache_sync_readahead(inode->i_mapping, @@ -2769,6 +2769,11 @@ static int relocate_file_extent_cluster(struct inode *inode, ret = -EIO; goto out; } + if (page->mapping != inode->i_mapping) { + unlock_page(page); + put_page(page); + goto again; + } } page_start = page_offset(page); -- 2.39.2

2 1

[PATCH OLK-5.10] drm/i915/hdcp: Add encoder check in hdcp2_get_capability
by He Yujie 13 Jan '25

13 Jan '25

From: Suraj Kandpal <suraj.kandpal(a)intel.com> mainline inclusion from mainline-v6.12-rc1 commit d34f4f058edf1235c103ca9c921dc54820d14d40 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB5KQZ CVE: CVE-2024-53050 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Add encoder check in intel_hdcp2_get_capability to avoid null pointer error. Signed-off-by: Suraj Kandpal <suraj.kandpal(a)intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722064451.3610512-3-sura… Conflicts: drivers/gpu/drm/i915/display/intel_hdcp.c drivers/gpu/drm/i915/display/intel_dp_hdcp.c [ Context conflict: 130849f8ec14("drm/i915/hdcp: Use intel_connector as argument for hdcp_2_2_capable") a35239a89259("drm/i915/hdcp: Use correct aux for capability check scenario") 287c0de8b294("drm/i915/hdcp: Move to direct reads for HDCP") 55d9b2b8e440("drm/i915/hdcp: Refactor intel_dp_hdcp2_capable") 8e754d9e9e8a("drm/i915/hdcp: Rename hdcp capable functions") the above patches are not merge. ] Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/gpu/drm/i915/display/intel_hdcp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c index 17a8c2e73a82..020dff600883 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c @@ -86,7 +86,7 @@ bool intel_hdcp_capable(struct intel_connector *connector) /* Is HDCP2.2 capable on Platform and Sink */ bool intel_hdcp2_capable(struct intel_connector *connector) { - struct intel_digital_port *dig_port = intel_attached_dig_port(connector); + struct intel_digital_port *dig_port; struct drm_i915_private *dev_priv = to_i915(connector->base.dev); struct intel_hdcp *hdcp = &connector->hdcp; bool capable = false; @@ -103,6 +103,11 @@ bool intel_hdcp2_capable(struct intel_connector *connector) } mutex_unlock(&dev_priv->hdcp_comp_mutex); + if (!intel_attached_encoder(connector)) + return false; + + dig_port = intel_attached_dig_port(connector); + /* Sink's capability for HDCP2.2 */ hdcp->shim->hdcp_2_2_capable(dig_port, &capable); -- 2.34.1

2 1

[PATCH OLK-5.10] octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c
by He Yujie 13 Jan '25

13 Jan '25

From: Dipendra Khadka <kdipendra88(a)gmail.com> stable inclusion from stable-v5.10.231 commit 5ff9de1f2712cbca53da2e37d831eea7ffcb43b6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEGGI CVE: CVE-2024-56728 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e26f8eac6bb20b20fdb8f7dc695711ebce4c7c5c ] Add error pointer check after calling otx2_mbox_get_rsp(). Fixes: 75f36270990c ("octeontx2-pf: Support to enable/disable pause frames via ethtool") Fixes: d0cf9503e908 ("octeontx2-pf: ethtool fec mode support") Signed-off-by: Dipendra Khadka <kdipendra88(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c [ Context conflict: d0cf9503e908 ("octeontx2-pf: ethtool fec mode support") is not merged ] Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c index 196354c142fe..43642eab200a 100644 --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c @@ -264,6 +264,11 @@ static void otx2_get_pauseparam(struct net_device *netdev, if (!otx2_sync_mbox_msg(&pfvf->mbox)) { rsp = (struct cgx_pause_frm_cfg *) otx2_mbox_get_rsp(&pfvf->mbox.mbox, 0, &req->hdr); + if (IS_ERR(rsp)) { + mutex_unlock(&pfvf->mbox.lock); + return; + } + pause->rx_pause = rsp->rx_pause; pause->tx_pause = rsp->tx_pause; } -- 2.34.1

2 1

[PATCH OLK-5.10] nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
by He Yujie 13 Jan '25

13 Jan '25

From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> stable inclusion from stable-v5.10.231 commit b017697a517f8779ada4e8ce1c2c75dbf60a2636 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB5KQZ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit cd45e963e44b0f10d90b9e6c0e8b4f47f3c92471 upstream. Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself. Link: https://lkml.kernel.org/r/20241106160811.3316-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20241106160811.3316-2-konishi.ryusuke@gmail.com Fixes: 5305cb830834 ("block: add block_{touch|dirty}_buffer tracepoint") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: Ubisectech Sirius <bugreport(a)valiantsec.com> Closes: https://lkml.kernel.org/r/86bd3013-887e-4e38-960f-ca45c657f032.bugreport@va… Reported-by: syzbot+9982fb8d18eba905abe2(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9982fb8d18eba905abe2 Tested-by: syzbot+9982fb8d18eba905abe2(a)syzkaller.appspotmail.com Cc: Tejun Heo <tj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- fs/nilfs2/page.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/nilfs2/page.c b/fs/nilfs2/page.c index 80f1f371d729..d2d6d5c761e8 100644 --- a/fs/nilfs2/page.c +++ b/fs/nilfs2/page.c @@ -39,7 +39,6 @@ __nilfs_get_page_block(struct page *page, unsigned long block, pgoff_t index, first_block = (unsigned long)index << (PAGE_SHIFT - blkbits); bh = nilfs_page_get_nth_block(page, block - first_block); - touch_buffer(bh); wait_on_buffer(bh); return bh; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/2] Fix rt warning
by Zheng Zucheng 13 Jan '25

13 Jan '25

Zheng Zucheng (2): sched/rt: Fix rt_runtime leaks with cpu hotplug sched: Replace WARN_ON_ONCE to printk_deferred_once kernel/sched/rt.c | 14 ++++++++++---- kernel/sched/sched.h | 2 +- 2 files changed, 11 insertions(+), 5 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-25.03 0/1] etmem: fix use-after-free of mm in the scan release process
by chenrenhui 13 Jan '25

13 Jan '25

etmem: fix use-after-free of mm in the scan release process chenrenhui (1): etmem: fix use-after-free of mm in the scan release process fs/proc/etmem_proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.33.0

2 2

[PATCH OLK-6.6] LoongArch: Fix sleeping in atomic context for PREEMPT_RT
by Xiaomeng Zhang 13 Jan '25

13 Jan '25

From: Huacai Chen <chenhuacai(a)loongson.cn> stable inclusion from stable-v6.6.66 commit c5f89458a2ea0800866b9fc690d3fa8367dc8f8d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAP8 CVE: CVE-2024-56585 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 88fd2b70120d52c1010257d36776876941375490 ] Commit bab1c299f3945ffe79 ("LoongArch: Fix sleeping in atomic context in setup_tlb_handler()") changes the gfp flag from GFP_KERNEL to GFP_ATOMIC for alloc_pages_node(). However, for PREEMPT_RT kernels we can still get a "sleeping in atomic context" error: [ 0.372259] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 0.372266] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 [ 0.372268] preempt_count: 1, expected: 0 [ 0.372270] RCU nest depth: 1, expected: 1 [ 0.372272] 3 locks held by swapper/1/0: [ 0.372274] #0: 900000000c9f5e60 (&pcp->lock){+.+.}-{3:3}, at: get_page_from_freelist+0x524/0x1c60 [ 0.372294] #1: 90000000087013b8 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x50/0x140 [ 0.372305] #2: 900000047fffd388 (&zone->lock){+.+.}-{3:3}, at: __rmqueue_pcplist+0x30c/0xea0 [ 0.372314] irq event stamp: 0 [ 0.372316] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 0.372322] hardirqs last disabled at (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372329] softirqs last enabled at (0): [<9000000005947320>] copy_process+0x9c0/0x26e0 [ 0.372335] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 0.372341] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7+ #1891 [ 0.372346] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 [ 0.372349] Stack : 0000000000000089 9000000005a0db9c 90000000071519c8 9000000100388000 [ 0.372486] 900000010038b890 0000000000000000 900000010038b898 9000000007e53788 [ 0.372492] 900000000815bcc8 900000000815bcc0 900000010038b700 0000000000000001 [ 0.372498] 0000000000000001 4b031894b9d6b725 00000000055ec000 9000000100338fc0 [ 0.372503] 00000000000000c4 0000000000000001 000000000000002d 0000000000000003 [ 0.372509] 0000000000000030 0000000000000003 00000000055ec000 0000000000000003 [ 0.372515] 900000000806d000 9000000007e53788 00000000000000b0 0000000000000004 [ 0.372521] 0000000000000000 0000000000000000 900000000c9f5f10 0000000000000000 [ 0.372526] 90000000076f12d8 9000000007e53788 9000000005924778 0000000000000000 [ 0.372532] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.372537] ... [ 0.372540] Call Trace: [ 0.372542] [<9000000005924778>] show_stack+0x38/0x180 [ 0.372548] [<90000000071519c4>] dump_stack_lvl+0x94/0xe4 [ 0.372555] [<900000000599b880>] __might_resched+0x1a0/0x260 [ 0.372561] [<90000000071675cc>] rt_spin_lock+0x4c/0x140 [ 0.372565] [<9000000005cbb768>] __rmqueue_pcplist+0x308/0xea0 [ 0.372570] [<9000000005cbed84>] get_page_from_freelist+0x564/0x1c60 [ 0.372575] [<9000000005cc0d98>] __alloc_pages_noprof+0x218/0x1820 [ 0.372580] [<900000000593b36c>] tlb_init+0x1ac/0x298 [ 0.372585] [<9000000005924b74>] per_cpu_trap_init+0x114/0x140 [ 0.372589] [<9000000005921964>] cpu_probe+0x4e4/0xa60 [ 0.372592] [<9000000005934874>] start_secondary+0x34/0xc0 [ 0.372599] [<900000000715615c>] smpboot_entry+0x64/0x6c This is because in PREEMPT_RT kernels normal spinlocks are replaced by rt spinlocks and rt_spin_lock() will cause sleeping. Fix it by disabling NUMA optimization completely for PREEMPT_RT kernels. Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13(a)huawei.com> --- arch/loongarch/mm/tlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/loongarch/mm/tlb.c b/arch/loongarch/mm/tlb.c index 5fcda8adf90d..5503d4e4b096 100644 --- a/arch/loongarch/mm/tlb.c +++ b/arch/loongarch/mm/tlb.c @@ -289,7 +289,7 @@ static void setup_tlb_handler(int cpu) /* Avoid lockdep warning */ rcu_cpu_starting(cpu); -#ifdef CONFIG_NUMA +#if defined(CONFIG_NUMA) && !defined(CONFIG_PREEMPT_RT) vec_sz = sizeof(exception_handlers); if (pcpu_handlers[cpu]) -- 2.34.1

2 1

[PATCH OLK-6.6] bpf: put bpf_link's program when link is safe to be deallocated
by Tengda Wu 13 Jan '25

13 Jan '25

From: Andrii Nakryiko <andrii(a)kernel.org> stable inclusion from stable-v6.6.66 commit 5fe23c57abadfd46a7a66e81f3536e4757252a0b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBHAY1 CVE: CVE-2024-56786 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit f44ec8733a8469143fde1984b5e6931b2e2f6f3f ] In general, BPF link's underlying BPF program should be considered to be reachable through attach hook -> link -> prog chain, and, pessimistically, we have to assume that as long as link's memory is not safe to free, attach hook's code might hold a pointer to BPF program and use it. As such, it's not (generally) correct to put link's program early before waiting for RCU GPs to go through. More eager bpf_prog_put() that we currently do is mostly correct due to BPF program's release code doing similar RCU GP waiting, but as will be shown in the following patches, BPF program can be non-sleepable (and, thus, reliant on only "classic" RCU GP), while BPF link's attach hook can have sleepable semantics and needs to be protected by RCU Tasks Trace, and for such cases BPF link has to go through RCU Tasks Trace + "classic" RCU GPs before being deallocated. And so, if we put BPF program early, we might free BPF program before we free BPF link, leading to use-after-free situation. So, this patch defers bpf_prog_put() until we are ready to perform bpf_link's deallocation. At worst, this delays BPF program freeing by one extra RCU GP, but that seems completely acceptable. Alternatively, we'd need more elaborate ways to determine BPF hook, BPF link, and BPF program lifetimes, and how they relate to each other, which seems like an unnecessary complication. Note, for most BPF links we still will perform eager bpf_prog_put() and link dealloc, so for those BPF links there are no observable changes whatsoever. Only BPF links that use deferred dealloc might notice slightly delayed freeing of BPF programs. Also, to reduce code and logic duplication, extract program put + link dealloc logic into bpf_link_dealloc() helper. Link: https://lore.kernel.org/20241101181754.782341-1-andrii@kernel.org Tested-by: Jordan Rife <jrife(a)google.com> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/bpf/syscall.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index d5eb3a3edb31..46ef10fddd98 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -2877,12 +2877,24 @@ void bpf_link_inc(struct bpf_link *link) atomic64_inc(&link->refcnt); } +static void bpf_link_dealloc(struct bpf_link *link) +{ + /* now that we know that bpf_link itself can't be reached, put underlying BPF program */ + if (link->prog) + bpf_prog_put(link->prog); + + /* free bpf_link and its containing memory */ + if (link->ops->dealloc_deferred) + link->ops->dealloc_deferred(link); + else + link->ops->dealloc(link); +} + static void bpf_link_defer_dealloc_rcu_gp(struct rcu_head *rcu) { struct bpf_link *link = container_of(rcu, struct bpf_link, rcu); - /* free bpf_link and its containing memory */ - link->ops->dealloc_deferred(link); + bpf_link_dealloc(link); } static void bpf_link_defer_dealloc_mult_rcu_gp(struct rcu_head *rcu) @@ -2904,7 +2916,6 @@ static void bpf_link_free(struct bpf_link *link) sleepable = link->prog->aux->sleepable; /* detach BPF program, clean up used resources */ ops->release(link); - bpf_prog_put(link->prog); } if (ops->dealloc_deferred) { /* schedule BPF link deallocation; if underlying BPF program @@ -2915,8 +2926,9 @@ static void bpf_link_free(struct bpf_link *link) call_rcu_tasks_trace(&link->rcu, bpf_link_defer_dealloc_mult_rcu_gp); else call_rcu(&link->rcu, bpf_link_defer_dealloc_rcu_gp); - } else if (ops->dealloc) - ops->dealloc(link); + } else if (ops->dealloc) { + bpf_link_dealloc(link); + } } static void bpf_link_put_deferred(struct work_struct *work) -- 2.34.1

2 1

[PATCH OLK-6.6] net: stmmac: fix TSO DMA API usage causing oops
by GONG Ruiqi 13 Jan '25

13 Jan '25

From: "Russell King (Oracle)" <rmk+kernel(a)armlinux.org.uk> stable inclusion from stable-v6.6.68 commit db3667c9bbfbbf5de98e6c9542f7e03fb5243286 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBFBOF CVE: CVE-2024-56719 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4c49f38e20a57f8abaebdf95b369295b153d1f8e ] Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of tx_skbuff_dma[]'s members to be later in stmmac_tso_xmit(). The buf (dma cookie) and len stored in this structure are passed to dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that the dma cookie passed to dma_unmap_single() is the same as the value returned from dma_map_single(). However, by moving the assignment later, this is not the case when priv->dma_cap.addr64 > 32 as "des" is offset by proto_hdr_len. This causes problems such as: dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed and with DMA_API_DEBUG enabled: DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes] Fix this by maintaining "des" as the original DMA cookie, and use tso_des to pass the offset DMA cookie to stmmac_tso_allocator(). Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5t… Reported-by: Jon Hunter <jonathanh(a)nvidia.com> Reported-by: Thierry Reding <thierry.reding(a)gmail.com> Fixes: 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") Tested-by: Jon Hunter <jonathanh(a)nvidia.com> Signed-off-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Reviewed-by: Furong Xu <0x1207(a)gmail.com> Link: https://patch.msgid.link/E1tJXcx-006N4Z-PC@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: GONG Ruiqi <gongruiqi1(a)huawei.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index ee81e2215487..80acff8b69e9 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -4136,9 +4136,9 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev) int tmp_pay_len = 0, first_tx; struct stmmac_tx_queue *tx_q; bool has_vlan, set_ic; + dma_addr_t tso_des, des; u8 proto_hdr_len, hdr; u32 pay_len, mss; - dma_addr_t des; int i; tx_q = &priv->dma_conf.tx_queue[queue]; @@ -4223,14 +4223,15 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev) /* If needed take extra descriptors to fill the remaining payload */ tmp_pay_len = pay_len - TSO_MAX_BUFF_SIZE; + tso_des = des; } else { stmmac_set_desc_addr(priv, first, des); tmp_pay_len = pay_len; - des += proto_hdr_len; + tso_des = des + proto_hdr_len; pay_len = 0; } - stmmac_tso_allocator(priv, des, tmp_pay_len, (nfrags == 0), queue); + stmmac_tso_allocator(priv, tso_des, tmp_pay_len, (nfrags == 0), queue); /* In case two or more DMA transmit descriptors are allocated for this * non-paged SKB data, the DMA buffer address should be saved to -- 2.25.1

2 1