- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/4] LoongArch: fix some 3C6000&LS7A related problems
by Hongchen Zhang 25 Oct '24

25 Oct '24

Haowei Zheng (1): acpi: mcfg quirk: Increased multi-chip support for the 3C6000 gaojuxin (1): LoongArch: Add workaround for 3C6000 about io wr/rd wusheng (1): pci/quirks: LS7A2000 enable msi zhangtianyang (1): Loongarch: Dynamic enable writecombine arch/loongarch/include/asm/io.h | 149 +++++++++++++++++++++++++++++++ arch/loongarch/include/asm/irq.h | 4 +- arch/loongarch/kernel/setup.c | 28 +++++- arch/loongarch/kernel/smp.c | 20 ++++- drivers/acpi/pci_mcfg.c | 13 +++ drivers/pci/quirks.c | 14 +++ include/drm/drm_cache.h | 2 +- 7 files changed, 224 insertions(+), 6 deletions(-) -- 2.33.0

2 5

[PATCH openEuler-22.03-LTS-SP1 0/5] CVE-2024-40965_openEuler-22.03-LTS-SP1
by dinglongwei 25 Oct '24

25 Oct '24

CVE-2024-40965_openEuler-22.03-LTS-SP1 Alexander Stein (1): i2c: lpi2c: Avoid calling clk_get_rate during transfer Carlos Song (1): i2c: imx-lpi2c: return -EINVAL when i2c peripheral clk doesn't work Peng Fan (1): i2c: imx-lpi2c: use bulk clk API Uwe Kleine-König (2): clk: Add a devm variant of clk_rate_exclusive_get() clk: Provide !COMMON_CLK dummy for devm_clk_rate_exclusive_get() drivers/clk/clk.c | 19 ++++++++++++++ drivers/i2c/busses/i2c-imx-lpi2c.c | 40 +++++++++++++++++++++--------- include/linux/clk.h | 17 +++++++++++++ 3 files changed, 64 insertions(+), 12 deletions(-) -- 2.17.1

2 6

[PATCH openEuler-22.03-LTS-SP1] gtp: fix a potential NULL pointer dereference
by Dong Chenchen 25 Oct '24

25 Oct '24

From: Cong Wang <cong.wang(a)bytedance.com> stable inclusion from stable-v5.10.225 commit 8bbb9e4e0e66a39282e582d0440724055404b38c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAR4H8 CVE: CVE-2024-46677 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit defd8b3c37b0f9cb3e0f60f47d3d78d459d57fda ] When sockfd_lookup() fails, gtp_encap_enable_socket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case. Fix it by returning an error pointer with the error code carried from sockfd_lookup(). (I found this bug during code inspection.) Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Cc: Andreas Schultz <aschultz(a)tpip.net> Cc: Harald Welte <laforge(a)gnumonks.org> Signed-off-by: Cong Wang <cong.wang(a)bytedance.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Link: https://patch.msgid.link/20240825191638.146748-1-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 993960f0fa3c..24cb7b97e4fc 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -801,7 +801,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, sock = sockfd_lookup(fd, &err); if (!sock) { pr_debug("gtp socket fd=%d not found\n", fd); - return NULL; + return ERR_PTR(err); } sk = sock->sk; -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/2] gtp: Fix CVE-2024-46677
by Dong Chenchen 25 Oct '24

25 Oct '24

fix CVE-2024-46677 Cong Wang (1): gtp: fix a potential NULL pointer dereference Eric Dumazet (1): gtp: make sure only SOCK_DGRAM UDP sockets are accepted drivers/net/gtp.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/1] CVE-2024-38667
by Yongqiang Liu 25 Oct '24

25 Oct '24

Sergey Matyukevich (1): riscv: prevent pt_regs corruption for secondary idle threads arch/riscv/kernel/cpu_ops.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.34.1

2 2

[PATCH OLK-5.10 0/1] CVE-2024-38667
by Yongqiang Liu 25 Oct '24

25 Oct '24

Sergey Matyukevich (1): riscv: prevent pt_regs corruption for secondary idle threads arch/riscv/kernel/cpu_ops.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/1] CVE-2024-36286
by Yongqiang Liu 25 Oct '24

25 Oct '24

Eric Dumazet (1): netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() net/netfilter/nfnetlink_queue.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.25.1

2 2

[PATCH OLK-6.6] device-dax: correct pgoff align in dax_set_mapping()
by Huang Xiaojia 25 Oct '24

25 Oct '24

From: "Kun(llfl)" <llfl(a)linux.alibaba.com> stable inclusion from stable-v6.6.57 commit b822007e8db341d6f175c645ed79866db501ad86 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYREL CVE: CVE-2024-50022 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 7fcbd9785d4c17ea533c42f20a9083a83f301fa6 upstream. pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem, but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G) Link: https://lkml.kernel.org/r/23c02a03e8d666fef11bbe13e85c69c8b4ca0624.17274216… Fixes: b9b5777f09be ("device-dax: use ALIGN() for determining pgoff") Signed-off-by: Kun(llfl) <llfl(a)linux.alibaba.com> Tested-by: JianXiong Zhao <zhaojianxiong.zjx(a)alibaba-inc.com> Reviewed-by: Joao Martins <joao.m.martins(a)oracle.com> Cc: Dan Williams <dan.j.williams(a)intel.com> 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: Huang Xiaojia <huangxiaojia2(a)huawei.com> --- drivers/dax/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dax/device.c b/drivers/dax/device.c index 93ebedc5ec8c..01e89b7ac637 100644 --- a/drivers/dax/device.c +++ b/drivers/dax/device.c @@ -86,7 +86,7 @@ static void dax_set_mapping(struct vm_fault *vmf, pfn_t pfn, nr_pages = 1; pgoff = linear_page_index(vmf->vma, - ALIGN(vmf->address, fault_size)); + ALIGN_DOWN(vmf->address, fault_size)); for (i = 0; i < nr_pages; i++) { struct page *page = pfn_to_page(pfn_t_to_pfn(pfn) + i); -- 2.34.1

2 1

[PATCH ] nilfs2: fix state management in error path of log writing function
by Chen Ridong 25 Oct '24

25 Oct '24

From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> mainline inclusion from mainline-v6.11-rc7 commit 6576dd6695f2afca3f4954029ac4a64f82ba60ab category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAVUFV CVE: CVE-2024-47669 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling. First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang. Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping. Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared. Link: https://lkml.kernel.org/r/20240814101119.4070-1-konishi.ryusuke@gmail.com Fixes: a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Tested-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Chen Ridong <chenridong(a)huawei.com> --- fs/nilfs2/segment.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index 633809581852..6c48d2b27707 100644 --- a/fs/nilfs2/segment.c +++ b/fs/nilfs2/segment.c @@ -1799,6 +1799,9 @@ static void nilfs_segctor_abort_construction(struct nilfs_sc_info *sci, nilfs_abort_logs(&logs, ret ? : err); list_splice_tail_init(&sci->sc_segbufs, &logs); + if (list_empty(&logs)) + return; /* if the first segment buffer preparation failed */ + nilfs_cancel_segusage(&logs, nilfs->ns_sufile); nilfs_free_incomplete_logs(&logs, nilfs); @@ -2040,7 +2043,7 @@ static int nilfs_segctor_do_construct(struct nilfs_sc_info *sci, int mode) err = nilfs_segctor_begin_construction(sci, nilfs); if (unlikely(err)) - goto out; + goto failed; /* Update time stamp */ sci->sc_seg_ctime = ktime_get_real_seconds(); @@ -2103,10 +2106,9 @@ static int nilfs_segctor_do_construct(struct nilfs_sc_info *sci, int mode) return err; failed_to_write: - if (sci->sc_stage.flags & NILFS_CF_IFILE_STARTED) - nilfs_redirty_inodes(&sci->sc_dirty_files); - failed: + if (mode == SC_LSEG_SR && nilfs_sc_cstage_get(sci) >= NILFS_ST_IFILE) + nilfs_redirty_inodes(&sci->sc_dirty_files); if (nilfs_doing_gc()) nilfs_redirty_inodes(&sci->sc_gc_inodes); nilfs_segctor_abort_construction(sci, nilfs, err); -- 2.34.1

1 0

[PATCH openEuler-22.03-LTS-SP1 0/1] CVE-2024-41015
by Yongqiang Liu 25 Oct '24

25 Oct '24

lei lu (1): ocfs2: add bounds checking to ocfs2_check_dir_entry() fs/ocfs2/dir.c | 46 +++++++++++++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 17 deletions(-) -- 2.25.1

2 2