mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 55 participants
  • 18782 discussions
[PATCH OLK-5.10 RESEND 0/2] block: warn once for each partition in bio_check_ro()
by Li Nan 20 Nov '23

20 Nov '23
From: Yu Kuai <yukuai3(a)huawei.com> Yu Kuai (2): block: warn once for each partition in bio_check_ro() block: fix kabi broken in struct hd_part block/blk-core.c | 5 +++++ include/linux/genhd.h | 1 + 2 files changed, 6 insertions(+) -- 2.39.2
1 0
0 0
[PATCH OLK-5.10] fs: Fix syntax issues in comments and print statements.
by Li Lingfeng 20 Nov '23

20 Nov '23
hulk inclusion category: cleanup bugzilla: https://gitee.com/openeuler/kernel/issues/I8HWD1 -------------------------------- There are syntax errors in the comments and print statements of the code section that detects opening write opened block devices exclusively, which need to be fixed. Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/block_dev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index a0e4d3ec300e..6389551aa29e 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -1669,11 +1669,11 @@ static int __blkdev_get(struct block_device *bdev, fmode_t mode, void *holder, #ifdef CONFIG_BLK_DEV_DUMPINFO /* * Open an write opened block device exclusively, the - * writing process may probability corrupt the device, + * writing process may probably corrupt the device, * such as a mounted file system, give a hint here. */ if (is_conflict_excl_open(bdev, claiming, mode)) - blkdev_dump_conflict_opener(bdev, "VFS: Open an write opened " + blkdev_dump_conflict_opener(bdev, "VFS: Open a write opened " "block device exclusively"); #endif bd_finish_claiming(bdev, claiming, holder); -- 2.31.1
2 1
0 0
[PATCH openEuler-1.0-LTS] mm/migrate.c: fix potential indeterminate pte entry in migrate_vma_insert_page()
by Tong Tiangen 20 Nov '23

20 Nov '23
From: Miaohe Lin <linmiaohe(a)huawei.com> mainline inclusion from mainline-v5.13-rc1 commit 34f5e9b9d1990d286199084efa752530ee3d8297 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8HVSL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If the zone device page does not belong to un-addressable device memory, the variable entry will be uninitialized and lead to indeterminate pte entry ultimately. Fix this unexpected case and warn about it. Link: https://lkml.kernel.org/r/20210325131524.48181-4-linmiaohe@huawei.com Fixes: df6ad69838fc ("mm/device-public-memory: device memory cache coherent with CPU") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Alistair Popple <apopple(a)nvidia.com> Cc: Jerome Glisse <jglisse(a)redhat.com> Cc: Rafael Aquini <aquini(a)redhat.com> Cc: Yang Shi <shy828301(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> conflict: mm/migrate.c Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- mm/migrate.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/mm/migrate.c b/mm/migrate.c index dc6416ccef44..56a2033d443c 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -2688,6 +2688,13 @@ static void migrate_vma_insert_page(struct migrate_vma *migrate, if (vma->vm_flags & VM_WRITE) entry = pte_mkwrite(pte_mkdirty(entry)); entry = pte_mkdevmap(entry); + } else { + /* + * For now we not support migrating to MEMORY_DEVICE_FS_DAX + * and MEMORY_DEVICE_PCI_P2PDMA device memory. + */ + pr_warn_once("Unsupported ZONE_DEVICE page type.\n"); + goto abort; } } else { entry = mk_pte(page, vma->vm_page_prot); -- 2.25.1
2 1
0 0
[PATCH OLK-5.10 0/2] block: warn once for each partition in bio_check_ro()
by Li Nan 20 Nov '23

20 Nov '23
From: Yu Kuai <yukuai3(a)huawei.com> Yu Kuai (2): block: warn once for each partition in bio_check_ro() block: fix kabi broken in struct hd_part block/blk-core.c | 5 +++++ include/linux/genhd.h | 1 + 2 files changed, 6 insertions(+) -- 2.39.2
2 3
0 0
[PATCH OLK-5.10] net/tls: do not free tls_rec on async operation in bpf_exec_tx_verdict()
by Liu Jian 18 Nov '23

18 Nov '23
stable inclusion from stable-v5.10.195 commit a5096cc6e7836711541b7cd2d6da48d36fe420e9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8H5DK CVE: CVE-2023-6176 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit cfaa80c91f6f99b9342b6557f0f0e1143e434066 ] I got the below warning when do fuzzing test: BUG: KASAN: null-ptr-deref in scatterwalk_copychunks+0x320/0x470 Read of size 4 at addr 0000000000000008 by task kworker/u8:1/9 CPU: 0 PID: 9 Comm: kworker/u8:1 Tainted: G OE Hardware name: linux,dummy-virt (DT) Workqueue: pencrypt_parallel padata_parallel_worker Call trace: dump_backtrace+0x0/0x420 show_stack+0x34/0x44 dump_stack+0x1d0/0x248 __kasan_report+0x138/0x140 kasan_report+0x44/0x6c __asan_load4+0x94/0xd0 scatterwalk_copychunks+0x320/0x470 skcipher_next_slow+0x14c/0x290 skcipher_walk_next+0x2fc/0x480 skcipher_walk_first+0x9c/0x110 skcipher_walk_aead_common+0x380/0x440 skcipher_walk_aead_encrypt+0x54/0x70 ccm_encrypt+0x13c/0x4d0 crypto_aead_encrypt+0x7c/0xfc pcrypt_aead_enc+0x28/0x84 padata_parallel_worker+0xd0/0x2dc process_one_work+0x49c/0xbdc worker_thread+0x124/0x880 kthread+0x210/0x260 ret_from_fork+0x10/0x18 This is because the value of rec_seq of tls_crypto_info configured by the user program is too large, for example, 0xffffffffffffff. In addition, TLS is asynchronously accelerated. When tls_do_encryption() returns -EINPROGRESS and sk->sk_err is set to EBADMSG due to rec_seq overflow, skmsg is released before the asynchronous encryption process ends. As a result, the UAF problem occurs during the asynchronous processing of the encryption module. If the operation is asynchronous and the encryption module returns EINPROGRESS, do not free the record information. Fixes: 635d93981786 ("net/tls: free record only on encryption error") Signed-off-by: Liu Jian <liujian56(a)huawei.com> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Link: https://lore.kernel.org/r/20230909081434.2324940-1-liujian56@huawei.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/tls/tls_sw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 96c95ea728ac..84e1f2af1a83 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -815,7 +815,7 @@ static int bpf_exec_tx_verdict(struct sk_msg *msg, struct sock *sk, psock = sk_psock_get(sk); if (!psock || !policy) { err = tls_push_record(sk, flags, record_type); - if (err && sk->sk_err == EBADMSG) { + if (err && err != -EINPROGRESS && sk->sk_err == EBADMSG) { *copied -= sk_msg_free(sk, msg); tls_free_open_rec(sk); err = -sk->sk_err; @@ -844,7 +844,7 @@ static int bpf_exec_tx_verdict(struct sk_msg *msg, struct sock *sk, switch (psock->eval) { case __SK_PASS: err = tls_push_record(sk, flags, record_type); - if (err && sk->sk_err == EBADMSG) { + if (err && err != -EINPROGRESS && sk->sk_err == EBADMSG) { *copied -= sk_msg_free(sk, msg); tls_free_open_rec(sk); err = -sk->sk_err; -- 2.34.1
2 1
0 0
[PATCH openEuler-22.03-LTS-SP2] mm/hugetlb: fix parameter passed to allocate bootmem memory
by Wupeng Ma 18 Nov '23

18 Nov '23
From: Jason Zeng <jason.zeng(a)intel.com> Intel inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7HUWC CVE: NA ----------------------------------------------- Intel-SIG: hugetlb: fix parameter passed to allocate bootmem memory __alloc_bootmem_huge_page_inner() should use 'min_addr" as the 3rd parameter to invoke memblock_alloc_try_nid_raw() and memblock_alloc_try_nid_raw_flags. Fixes: 74bfdf157f1f ("mm/hugetlb: Hugetlb use non-mirrored memory if memory reliable is enabled") Signed-off-by: Jason Zeng <jason.zeng(a)intel.com> [Wupeng: cherry-pick from a78d9e8141261369833de3cd2aa4e7e7880bddaf] Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- mm/hugetlb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 7aca3351b9b9..8cf3d5bb4881 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2713,10 +2713,10 @@ static void *__init __alloc_bootmem_huge_page_inner(phys_addr_t size, int nid) { if (!mem_reliable_is_enabled()) - return memblock_alloc_try_nid_raw(size, align, max_addr, + return memblock_alloc_try_nid_raw(size, align, min_addr, max_addr, nid); - return memblock_alloc_try_nid_raw_flags(size, align, max_addr, max_addr, + return memblock_alloc_try_nid_raw_flags(size, align, min_addr, max_addr, nid, MEMBLOCK_NOMIRROR); } -- 2.25.1
2 1
0 0
[PATCH OLK-6.6 0/3] Add initial openeuler_defconfig for arm64 and x86
by Zheng Zengkai 17 Nov '23

17 Nov '23
If new options are introduced, but openeuler_defconfig is not explicitly configured, the actual compiled version may be configured according to the default settings, which may be different from the author's expectation. Therefore, some commands/scripts are added to help developers to check and update the defconfig. It is also convenient for continuous integration tools to check the consistency of defconfig. Based on OLK-5.10 openeuler_defconfig, use the commands mentioned above to generate the initial openeuler_defconfig for OLK-6.6 kernel build. Xie XiuQi (1): kconfig: Add script to check & update openeuler_defconfig Zheng Zengkai (2): config: add initial openeuler_defconfig for arm64 config: add initial openeuler_defconfig for x86 arch/arm64/configs/openeuler_defconfig | 7942 ++++++++++++++++++++ arch/x86/configs/openeuler_defconfig | 9158 ++++++++++++++++++++++++ scripts/kconfig/Makefile | 22 + scripts/kconfig/makeconfig.sh | 24 + 4 files changed, 17146 insertions(+) create mode 100644 arch/arm64/configs/openeuler_defconfig create mode 100644 arch/x86/configs/openeuler_defconfig create mode 100644 scripts/kconfig/makeconfig.sh -- 2.20.1
1 3
0 0
[PATCH OLK-6.6 0/3] Add initial openeuler_defconfig for arm64 and x86
by Zheng Zengkai 17 Nov '23

17 Nov '23
If new options are introduced, but openeuler_defconfig is not explicitly configured, the actual compiled version may be configured according to the default settings, which may be different from the author's expectation. Therefore, some commands/scripts are added to help developers to check and update the defconfig. It is also convenient for continuous integration tools to check the consistency of defconfig. Based on OLK-5.10 openeuler_defconfig, use the commands mentioned above to generate the initial openeuler_defconfig for OLK-6.6 kernel build. Xie XiuQi (1): kconfig: Add script to check & update openeuler_defconfig Zheng Zengkai (2): config: add initial openeuler_defconfig for arm64 config: add initial openeuler_defconfig for x86 arch/arm64/configs/openeuler_defconfig | 7942 ++++++++++++++++++++ arch/x86/configs/openeuler_defconfig | 9158 ++++++++++++++++++++++++ scripts/kconfig/Makefile | 22 + scripts/kconfig/makeconfig.sh | 24 + 4 files changed, 17146 insertions(+) create mode 100644 arch/arm64/configs/openeuler_defconfig create mode 100644 arch/x86/configs/openeuler_defconfig create mode 100644 scripts/kconfig/makeconfig.sh -- 2.20.1
1 3
0 0
[PATCH OLK-6.6 0/3] Add initial openeuler_defconfig for arm64 and x86
by Zheng Zengkai 17 Nov '23

17 Nov '23
If new options are introduced, but openeuler_defconfig is not explicitly configured, the actual compiled version may be configured according to the default settings, which may be different from the author's expectation. Therefore, some commands/scripts are added to help developers to check and update the defconfig. It is also convenient for continuous integration tools to check the consistency of defconfig. Based on OLK-5.10 openeuler_defconfig, use the commands mentioned above to generate the initial openeuler_defconfig for OLK-6.6 kernel build. Xie XiuQi (1): kconfig: Add script to check & update openeuler_defconfig Zheng Zengkai (2): config: add initial openeuler_defconfig for arm64 config: add initial openeuler_defconfig for x86 arch/arm64/configs/openeuler_defconfig | 7942 ++++++++++++++++++++ arch/x86/configs/openeuler_defconfig | 9158 ++++++++++++++++++++++++ scripts/kconfig/Makefile | 22 + scripts/kconfig/makeconfig.sh | 24 + 4 files changed, 17146 insertions(+) create mode 100644 arch/arm64/configs/openeuler_defconfig create mode 100644 arch/x86/configs/openeuler_defconfig create mode 100644 scripts/kconfig/makeconfig.sh -- 2.20.1
1 3
0 0
[PATCH openEuler-1.0-LTS v3] netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one
by Zhengchao Shao 17 Nov '23

17 Nov '23
From: Florian Westphal <fw(a)strlen.de> mainline inclusion from mainline-v6.5-rc1 commit ff0a3a7d52ff7282dbd183e7fc29a1fe386b0c30 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I8EZSO CVE: CVE-2023-39197 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Eric Dumazet says: nf_conntrack_dccp_packet() has an unique: dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh); And nothing more is 'pulled' from the packet, depending on the content. dh->dccph_doff, and/or dh->dccph_x ...) So dccp_ack_seq() is happily reading stuff past the _dh buffer. BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0 Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371 [..] Fix this by increasing the stack buffer to also include room for the extra sequence numbers and all the known dccp packet type headers, then pull again after the initial validation of the basic header. While at it, mark packets invalid that lack 48bit sequence bit but where RFC says the type MUST use them. Compile tested only. v2: first skb_header_pointer() now needs to adjust the size to only pull the generic header. (Eric) Heads-up: I intend to remove dccp conntrack support later this year. Fixes: 2bc780499aa3 ("[NETFILTER]: nf_conntrack: add DCCP protocol support") Reported-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Florian Westphal <fw(a)strlen.de> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Conflicts: net/netfilter/nf_conntrack_proto_dccp.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/netfilter/nf_conntrack_proto_dccp.c | 52 +++++++++++++++++++++++-- 1 file changed, 49 insertions(+), 3 deletions(-) diff --git a/net/netfilter/nf_conntrack_proto_dccp.c b/net/netfilter/nf_conntrack_proto_dccp.c index 3ba1f4d9934f..fe17c2ddb6c8 100644 --- a/net/netfilter/nf_conntrack_proto_dccp.c +++ b/net/netfilter/nf_conntrack_proto_dccp.c @@ -433,17 +433,47 @@ static u64 dccp_ack_seq(const struct dccp_hdr *dh) ntohl(dhack->dccph_ack_nr_low); } +struct nf_conntrack_dccp_buf { + struct dccp_hdr dh; /* generic header part */ + struct dccp_hdr_ext ext; /* optional depending dh->dccph_x */ + union { /* depends on header type */ + struct dccp_hdr_ack_bits ack; + struct dccp_hdr_request req; + struct dccp_hdr_response response; + struct dccp_hdr_reset rst; + } u; +}; + +static struct dccp_hdr * +dccp_header_pointer(const struct sk_buff *skb, int offset, const struct dccp_hdr *dh, + struct nf_conntrack_dccp_buf *buf) +{ + unsigned int hdrlen = __dccp_hdr_len(dh); + + if (hdrlen > sizeof(*buf)) + return NULL; + + return skb_header_pointer(skb, offset, hdrlen, buf); +} + static int dccp_packet(struct nf_conn *ct, const struct sk_buff *skb, unsigned int dataoff, enum ip_conntrack_info ctinfo) { enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo); - struct dccp_hdr _dh, *dh; + struct nf_conntrack_dccp_buf _dh; u_int8_t type, old_state, new_state; enum ct_dccp_roles role; unsigned int *timeouts; + struct dccp_hdr *dh; - dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh); + dh = skb_header_pointer(skb, dataoff, sizeof(*dh), &_dh.dh); BUG_ON(dh == NULL); + + /* pull again, including possible 48 bit sequences and subtype header */ + dh = dccp_header_pointer(skb, dataoff, dh, &_dh); + if (!dh) + return NF_DROP; + type = dh->dccph_type; if (type == DCCP_PKT_RESET && @@ -526,10 +556,20 @@ static int dccp_error(struct net *net, struct nf_conn *tmpl, struct sk_buff *skb, unsigned int dataoff, u_int8_t pf, unsigned int hooknum) { + static const unsigned long require_seq48 = 1 << DCCP_PKT_REQUEST | + 1 << DCCP_PKT_RESPONSE | + 1 << DCCP_PKT_CLOSEREQ | + 1 << DCCP_PKT_CLOSE | + 1 << DCCP_PKT_RESET | + 1 << DCCP_PKT_SYNC | + 1 << DCCP_PKT_SYNCACK; struct dccp_hdr _dh, *dh; unsigned int dccp_len = skb->len - dataoff; unsigned int cscov; const char *msg; + u8 type; + + BUILD_BUG_ON(DCCP_PKT_INVALID >= BITS_PER_LONG); dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh); if (dh == NULL) { @@ -559,11 +599,17 @@ static int dccp_error(struct net *net, struct nf_conn *tmpl, goto out_invalid; } - if (dh->dccph_type >= DCCP_PKT_INVALID) { + type = dh->dccph_type; + if (type >= DCCP_PKT_INVALID) { msg = "nf_ct_dccp: reserved packet type "; goto out_invalid; } + if (test_bit(type, &require_seq48) && !dh->dccph_x) { + msg = "nf_ct_dccp: type lacks 48bit sequence numbers"; + goto out_invalid; + } + return NF_ACCEPT; out_invalid: -- 2.34.1
2 1
0 0
  • ← Newer
  • 1
  • ...
  • 1459
  • 1460
  • 1461
  • 1462
  • 1463
  • 1464
  • 1465
  • ...
  • 1879
  • Older →

HyperKitty Powered by HyperKitty