- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS 1/2] sctp: validate from_addr_param return
by Yang Yingliang 29 Jul '21

29 Jul '21

From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> stable inclusion from linux-4.19.198 commit c7a03ebace4f9cd40d9cd9dd5fb2af558025583c CVE: CVE-2021-3655 -------------------------------- [ Upstream commit 0c5dc070ff3d6246d22ddd931f23a6266249e3db ] Ilja reported that, simply putting it, nothing was validating that from_addr_param functions were operating on initialized memory. That is, the parameter itself was being validated by sctp_walk_params, but it doesn't check for types and their specific sizes and it could be a 0-length one, causing from_addr_param to potentially work over the next parameter or even uninitialized memory. The fix here is to, in all calls to from_addr_param, check if enough space is there for the wanted IP address type. Reported-by: Ilja Van Sprundel <ivansprundel(a)ioactive.com> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- include/net/sctp/structs.h | 2 +- net/sctp/bind_addr.c | 19 +++++++++++-------- net/sctp/input.c | 6 ++++-- net/sctp/ipv6.c | 7 ++++++- net/sctp/protocol.c | 7 ++++++- net/sctp/sm_make_chunk.c | 29 ++++++++++++++++------------- 6 files changed, 44 insertions(+), 26 deletions(-) diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h index 19f8d5881b08d..2882bc7a5b4b8 100644 --- a/include/net/sctp/structs.h +++ b/include/net/sctp/structs.h @@ -474,7 +474,7 @@ struct sctp_af { int saddr); void (*from_sk) (union sctp_addr *, struct sock *sk); - void (*from_addr_param) (union sctp_addr *, + bool (*from_addr_param) (union sctp_addr *, union sctp_addr_param *, __be16 port, int iif); int (*to_addr_param) (const union sctp_addr *, diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c index 38d01cfb313e5..f8a2832456728 100644 --- a/net/sctp/bind_addr.c +++ b/net/sctp/bind_addr.c @@ -285,22 +285,19 @@ int sctp_raw_to_bind_addrs(struct sctp_bind_addr *bp, __u8 *raw_addr_list, rawaddr = (union sctp_addr_param *)raw_addr_list; af = sctp_get_af_specific(param_type2af(param->type)); - if (unlikely(!af)) { + if (unlikely(!af) || + !af->from_addr_param(&addr, rawaddr, htons(port), 0)) { retval = -EINVAL; - sctp_bind_addr_clean(bp); - break; + goto out_err; } - af->from_addr_param(&addr, rawaddr, htons(port), 0); if (sctp_bind_addr_state(bp, &addr) != -1) goto next; retval = sctp_add_bind_addr(bp, &addr, sizeof(addr), SCTP_ADDR_SRC, gfp); - if (retval) { + if (retval) /* Can't finish building the list, clean up. */ - sctp_bind_addr_clean(bp); - break; - } + goto out_err; next: len = ntohs(param->length); @@ -309,6 +306,12 @@ int sctp_raw_to_bind_addrs(struct sctp_bind_addr *bp, __u8 *raw_addr_list, } return retval; + +out_err: + if (retval) + sctp_bind_addr_clean(bp); + + return retval; } /******************************************************************** diff --git a/net/sctp/input.c b/net/sctp/input.c index ee922867a5e02..81b4f091760eb 100644 --- a/net/sctp/input.c +++ b/net/sctp/input.c @@ -1088,7 +1088,8 @@ static struct sctp_association *__sctp_rcv_init_lookup(struct net *net, if (!af) continue; - af->from_addr_param(paddr, params.addr, sh->source, 0); + if (!af->from_addr_param(paddr, params.addr, sh->source, 0)) + continue; asoc = __sctp_lookup_association(net, laddr, paddr, transportp); if (asoc) @@ -1131,7 +1132,8 @@ static struct sctp_association *__sctp_rcv_asconf_lookup( if (unlikely(!af)) return NULL; - af->from_addr_param(&paddr, param, peer_port, 0); + if (af->from_addr_param(&paddr, param, peer_port, 0)) + return NULL; return __sctp_lookup_association(net, laddr, &paddr, transportp); } diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c index 4cc5739244935..fc82617b60765 100644 --- a/net/sctp/ipv6.c +++ b/net/sctp/ipv6.c @@ -542,15 +542,20 @@ static void sctp_v6_to_sk_daddr(union sctp_addr *addr, struct sock *sk) } /* Initialize a sctp_addr from an address parameter. */ -static void sctp_v6_from_addr_param(union sctp_addr *addr, +static bool sctp_v6_from_addr_param(union sctp_addr *addr, union sctp_addr_param *param, __be16 port, int iif) { + if (ntohs(param->v6.param_hdr.length) < sizeof(struct sctp_ipv6addr_param)) + return false; + addr->v6.sin6_family = AF_INET6; addr->v6.sin6_port = port; addr->v6.sin6_flowinfo = 0; /* BUG */ addr->v6.sin6_addr = param->v6.addr; addr->v6.sin6_scope_id = iif; + + return true; } /* Initialize an address parameter from a sctp_addr and return the length diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c index af054f38341b9..dd51256582556 100644 --- a/net/sctp/protocol.c +++ b/net/sctp/protocol.c @@ -268,14 +268,19 @@ static void sctp_v4_to_sk_daddr(union sctp_addr *addr, struct sock *sk) } /* Initialize a sctp_addr from an address parameter. */ -static void sctp_v4_from_addr_param(union sctp_addr *addr, +static bool sctp_v4_from_addr_param(union sctp_addr *addr, union sctp_addr_param *param, __be16 port, int iif) { + if (ntohs(param->v4.param_hdr.length) < sizeof(struct sctp_ipv4addr_param)) + return false; + addr->v4.sin_family = AF_INET; addr->v4.sin_port = port; addr->v4.sin_addr.s_addr = param->v4.addr.s_addr; memset(addr->v4.sin_zero, 0, sizeof(addr->v4.sin_zero)); + + return true; } /* Initialize an address parameter from a sctp_addr and return the length diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index dc51e14f568ee..a1ca070e36b0a 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -2352,11 +2352,13 @@ int sctp_process_init(struct sctp_association *asoc, struct sctp_chunk *chunk, /* Process the initialization parameters. */ sctp_walk_params(param, peer_init, init_hdr.params) { - if (!src_match && (param.p->type == SCTP_PARAM_IPV4_ADDRESS || - param.p->type == SCTP_PARAM_IPV6_ADDRESS)) { + if (!src_match && + (param.p->type == SCTP_PARAM_IPV4_ADDRESS || + param.p->type == SCTP_PARAM_IPV6_ADDRESS)) { af = sctp_get_af_specific(param_type2af(param.p->type)); - af->from_addr_param(&addr, param.addr, - chunk->sctp_hdr->source, 0); + if (!af->from_addr_param(&addr, param.addr, + chunk->sctp_hdr->source, 0)) + continue; if (sctp_cmp_addr_exact(sctp_source(chunk), &addr)) src_match = 1; } @@ -2537,7 +2539,8 @@ static int sctp_process_param(struct sctp_association *asoc, break; do_addr_param: af = sctp_get_af_specific(param_type2af(param.p->type)); - af->from_addr_param(&addr, param.addr, htons(asoc->peer.port), 0); + if (!af->from_addr_param(&addr, param.addr, htons(asoc->peer.port), 0)) + break; scope = sctp_scope(peer_addr); if (sctp_in_scope(net, &addr, scope)) if (!sctp_assoc_add_peer(asoc, &addr, gfp, SCTP_UNCONFIRMED)) @@ -2634,15 +2637,13 @@ static int sctp_process_param(struct sctp_association *asoc, addr_param = param.v + sizeof(struct sctp_addip_param); af = sctp_get_af_specific(param_type2af(addr_param->p.type)); - if (af == NULL) + if (!af) break; - af->from_addr_param(&addr, addr_param, - htons(asoc->peer.port), 0); + if (!af->from_addr_param(&addr, addr_param, + htons(asoc->peer.port), 0)) + break; - /* if the address is invalid, we can't process it. - * XXX: see spec for what to do. - */ if (!af->addr_valid(&addr, NULL, NULL)) break; @@ -3059,7 +3060,8 @@ static __be16 sctp_process_asconf_param(struct sctp_association *asoc, if (unlikely(!af)) return SCTP_ERROR_DNS_FAILED; - af->from_addr_param(&addr, addr_param, htons(asoc->peer.port), 0); + if (!af->from_addr_param(&addr, addr_param, htons(asoc->peer.port), 0)) + return SCTP_ERROR_DNS_FAILED; /* ADDIP 4.2.1 This parameter MUST NOT contain a broadcast * or multicast address. @@ -3336,7 +3338,8 @@ static void sctp_asconf_param_success(struct sctp_association *asoc, /* We have checked the packet before, so we do not check again. */ af = sctp_get_af_specific(param_type2af(addr_param->p.type)); - af->from_addr_param(&addr, addr_param, htons(bp->port), 0); + if (!af->from_addr_param(&addr, addr_param, htons(bp->port), 0)) + return; switch (asconf_param->param_hdr.type) { case SCTP_PARAM_ADD_IP: -- 2.25.1

1 1

[PATCH openEuler-1.0-LTS 01/16] Revert "jbd2: don't abort the journal when freeing buffers"
by Yang Yingliang 29 Jul '21

29 Jul '21

From: Zhang Yi <yi.zhang(a)huawei.com> hulk inclusion category: bugfix bugzilla: 50788 CVE: NA --------------------------- This reverts commit b8ac39c4a77a4ab351526d3b3afbe18c626d2ebd. Prepare to backport 235d68069cbd ("jbd2: don't abort the journal when freeing buffers") Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/jbd2/transaction.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c index 4055929a043cf..ffa6d3530f4bd 100644 --- a/fs/jbd2/transaction.c +++ b/fs/jbd2/transaction.c @@ -2085,6 +2085,7 @@ int jbd2_journal_try_to_free_buffers(journal_t *journal, { struct buffer_head *head; struct buffer_head *bh; + bool has_write_io_error = false; int ret = 0; J_ASSERT(PageLocked(page)); @@ -2109,10 +2110,26 @@ int jbd2_journal_try_to_free_buffers(journal_t *journal, jbd_unlock_bh_state(bh); if (buffer_jbd(bh)) goto busy; + + /* + * If we free a metadata buffer which has been failed to + * write out, the jbd2 checkpoint procedure will not detect + * this failure and may lead to filesystem inconsistency + * after cleanup journal tail. + */ + if (buffer_write_io_error(bh)) { + pr_err("JBD2: Error while async write back metadata bh %llu.", + (unsigned long long)bh->b_blocknr); + has_write_io_error = true; + } } while ((bh = bh->b_this_page) != head); ret = try_to_free_buffers(page); + busy: + if (has_write_io_error) + jbd2_journal_abort(journal, -EIO); + return ret; } -- 2.25.1

1 15

[PATCH kernel-4.19 01/14] Revert "jbd2: don't abort the journal when freeing buffers"
by Yang Yingliang 29 Jul '21

29 Jul '21

From: Zhang Yi <yi.zhang(a)huawei.com> hulk inclusion category: bugfix bugzilla: 50788 CVE: NA --------------------------- This reverts commit 30a8fc55ac1ba2cf3a8456788ce4ff1593853738. Prepare to backport 235d68069cbd ("jbd2: don't abort the journal when freeing buffers") Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Reviewed-by: Yang Erkun <yangerkun(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/jbd2/transaction.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c index 4055929a043cf..ffa6d3530f4bd 100644 --- a/fs/jbd2/transaction.c +++ b/fs/jbd2/transaction.c @@ -2085,6 +2085,7 @@ int jbd2_journal_try_to_free_buffers(journal_t *journal, { struct buffer_head *head; struct buffer_head *bh; + bool has_write_io_error = false; int ret = 0; J_ASSERT(PageLocked(page)); @@ -2109,10 +2110,26 @@ int jbd2_journal_try_to_free_buffers(journal_t *journal, jbd_unlock_bh_state(bh); if (buffer_jbd(bh)) goto busy; + + /* + * If we free a metadata buffer which has been failed to + * write out, the jbd2 checkpoint procedure will not detect + * this failure and may lead to filesystem inconsistency + * after cleanup journal tail. + */ + if (buffer_write_io_error(bh)) { + pr_err("JBD2: Error while async write back metadata bh %llu.", + (unsigned long long)bh->b_blocknr); + has_write_io_error = true; + } } while ((bh = bh->b_this_page) != head); ret = try_to_free_buffers(page); + busy: + if (has_write_io_error) + jbd2_journal_abort(journal, -EIO); + return ret; } -- 2.25.1

1 13

[PATCH kernel-4.19 1/2] mm/vmscan: fix infinite loop in drop_slab_node
by Yang Yingliang 29 Jul '21

29 Jul '21

From: Chunxin Zang <zangchunxin(a)bytedance.com> mainline inclusion from mainline-v5.10-rc1 commit 069c411de40a621c82efd2618663fee51d8c59b8 category: bugfix bugzilla: 175105 CVE: NA ------------------------------------------------- We have observed that drop_caches can take a considerable amount of time (<put data here>). Especially when there are many memcgs involved because they are adding an additional overhead. It is quite unfortunate that the operation cannot be interrupted by a signal currently. Add a check for fatal signals into the main loop so that userspace can control early bailout. There are two reasons: 1. We have too many memcgs, even though one object freed in one memcg, the sum of object is bigger than 10. 2. We spend a lot of time in traverse memcg once. So, the memcg who traversed at the first have been freed many objects. Traverse memcg next time, the freed count bigger than 10 again. We can get the following info through 'ps': root:~# ps -aux | grep drop root 357956 ... R Aug25 21119854:55 echo 3 > /proc/sys/vm/drop_caches root 1771385 ... R Aug16 21146421:17 echo 3 > /proc/sys/vm/drop_caches root 1986319 ... R 18:56 117:27 echo 3 > /proc/sys/vm/drop_caches root 2002148 ... R Aug24 5720:39 echo 3 > /proc/sys/vm/drop_caches root 2564666 ... R 18:59 113:58 echo 3 > /proc/sys/vm/drop_caches root 2639347 ... R Sep03 2383:39 echo 3 > /proc/sys/vm/drop_caches root 3904747 ... R 03:35 993:31 echo 3 > /proc/sys/vm/drop_caches root 4016780 ... R Aug21 7882:18 echo 3 > /proc/sys/vm/drop_caches Use bpftrace follow 'freed' value in drop_slab_node: root:~# bpftrace -e 'kprobe:drop_slab_node+70 {@ret=hist(reg("bp")); }' Attaching 1 probe... ^B^C @ret: [64, 128) 1 | | [128, 256) 28 | | [256, 512) 107 |@ | [512, 1K) 298 |@@@ | [1K, 2K) 613 |@@@@@@@ | [2K, 4K) 4435 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [4K, 8K) 442 |@@@@@ | [8K, 16K) 299 |@@@ | [16K, 32K) 100 |@ | [32K, 64K) 139 |@ | [64K, 128K) 56 | | [128K, 256K) 26 | | [256K, 512K) 2 | | In the while loop, we can check whether the TASK_KILLABLE signal is set, if so, we should break the loop. Signed-off-by: Chunxin Zang <zangchunxin(a)bytedance.com> Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Acked-by: Chris Down <chris(a)chrisdown.name> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Matthew Wilcox <willy(a)infradead.org> Link: https://lkml.kernel.org/r/20200909152047.27905-1-zangchunxin@bytedance.com Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Reviewed-by: tong tiangen <tongtiangen(a)huawei.com> Reviewed-by: tong tiangen <tongtiangen(a)huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- mm/vmscan.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/vmscan.c b/mm/vmscan.c index bedea8b4024a8..71bf44b27d958 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -739,6 +739,9 @@ void drop_slab_node(int nid) do { struct mem_cgroup *memcg = NULL; + if (fatal_signal_pending(current)) + return; + freed = 0; memcg = mem_cgroup_iter(NULL, NULL, NULL); do { -- 2.25.1

1 1

[PATCH openEuler-1.0-LTS 1/2] mm/vmscan: fix infinite loop in drop_slab_node
by Yang Yingliang 29 Jul '21

29 Jul '21

From: Chunxin Zang <zangchunxin(a)bytedance.com> mainline inclusion from mainline-v5.10-rc1 commit 069c411de40a621c82efd2618663fee51d8c59b8 category: bugfix bugzilla: 175105 CVE: NA ------------------------------------------------- We have observed that drop_caches can take a considerable amount of time (<put data here>). Especially when there are many memcgs involved because they are adding an additional overhead. It is quite unfortunate that the operation cannot be interrupted by a signal currently. Add a check for fatal signals into the main loop so that userspace can control early bailout. There are two reasons: 1. We have too many memcgs, even though one object freed in one memcg, the sum of object is bigger than 10. 2. We spend a lot of time in traverse memcg once. So, the memcg who traversed at the first have been freed many objects. Traverse memcg next time, the freed count bigger than 10 again. We can get the following info through 'ps': root:~# ps -aux | grep drop root 357956 ... R Aug25 21119854:55 echo 3 > /proc/sys/vm/drop_caches root 1771385 ... R Aug16 21146421:17 echo 3 > /proc/sys/vm/drop_caches root 1986319 ... R 18:56 117:27 echo 3 > /proc/sys/vm/drop_caches root 2002148 ... R Aug24 5720:39 echo 3 > /proc/sys/vm/drop_caches root 2564666 ... R 18:59 113:58 echo 3 > /proc/sys/vm/drop_caches root 2639347 ... R Sep03 2383:39 echo 3 > /proc/sys/vm/drop_caches root 3904747 ... R 03:35 993:31 echo 3 > /proc/sys/vm/drop_caches root 4016780 ... R Aug21 7882:18 echo 3 > /proc/sys/vm/drop_caches Use bpftrace follow 'freed' value in drop_slab_node: root:~# bpftrace -e 'kprobe:drop_slab_node+70 {@ret=hist(reg("bp")); }' Attaching 1 probe... ^B^C @ret: [64, 128) 1 | | [128, 256) 28 | | [256, 512) 107 |@ | [512, 1K) 298 |@@@ | [1K, 2K) 613 |@@@@@@@ | [2K, 4K) 4435 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [4K, 8K) 442 |@@@@@ | [8K, 16K) 299 |@@@ | [16K, 32K) 100 |@ | [32K, 64K) 139 |@ | [64K, 128K) 56 | | [128K, 256K) 26 | | [256K, 512K) 2 | | In the while loop, we can check whether the TASK_KILLABLE signal is set, if so, we should break the loop. Signed-off-by: Chunxin Zang <zangchunxin(a)bytedance.com> Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Acked-by: Chris Down <chris(a)chrisdown.name> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Matthew Wilcox <willy(a)infradead.org> Link: https://lkml.kernel.org/r/20200909152047.27905-1-zangchunxin@bytedance.com Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Reviewed-by: tong tiangen <tongtiangen(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- mm/vmscan.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/vmscan.c b/mm/vmscan.c index de03e899324e0..d04c8ed5c22e5 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -739,6 +739,9 @@ void drop_slab_node(int nid) do { struct mem_cgroup *memcg = NULL; + if (fatal_signal_pending(current)) + return; + freed = 0; memcg = mem_cgroup_iter(NULL, NULL, NULL); do { -- 2.25.1

1 1

[PATCH kernel-4.19 1/2] userfaultfd: fix BUG_ON() in userfaultfd_release()
by Yang Yingliang 29 Jul '21

29 Jul '21

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> hulk inclusion category: bugfix bugzilla: 175146 CVE: NA ------------------------------------ Syzkaller caught the following BUG_ON: ------------[ cut here ]------------ kernel BUG at fs/userfaultfd.c:909! Internal error: Oops - BUG: 0 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: Process syz-executor.2 (pid: 1994, stack limit = 0x0000000048da525b) CPU: 0 PID: 1994 Comm: syz-executor.2 Not tainted 4.19.90+ #6 Hardware name: linux,dummy-virt (DT) pstate: 80000005 (Nzcv daif -PAN -UAO) pc : userfaultfd_release+0x4f0/0x6a0 fs/userfaultfd.c:908 lr : userfaultfd_release+0x4f0/0x6a0 fs/userfaultfd.c:908 sp : ffff80017d247c80 x29: ffff80017d247c90 x28: ffff80019b25f720 x27: 2000000000100077 x26: ffff80017c28fe40 x25: ffff80019b25f770 x24: ffff80019b25f7e0 x23: ffff80019b25e378 x22: 1ffff0002fa48fa6 x21: ffff80017f103200 x20: dfff200000000000 x19: ffff80017c28fe40 x18: 0000000000000000 x17: ffffffff00000001 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 1ffff0002fa48fa6 x8 : ffff10002fa48fa6 x7 : ffff20000add39f0 x6 : 00000000f2000000 x5 : 0000000000000000 x4 : ffff10002fa48f76 x3 : ffff200008000000 x2 : ffff20000a61d000 x1 : ffff800160aa9000 x0 : 0000000000000000 Call trace: userfaultfd_release+0x4f0/0x6a0 fs/userfaultfd.c:908 __fput+0x20c/0x688 fs/file_table.c:278 ____fput+0x24/0x30 fs/file_table.c:309 task_work_run+0x13c/0x2f8 kernel/task_work.c:135 tracehook_notify_resume include/linux/tracehook.h:193 [inline] do_notify_resume+0x380/0x628 arch/arm64/kernel/signal.c:728 work_pending+0x8/0x10 Code: 97ecb0e4 d4210000 17ffffc7 97ecb0e1 (d4210000) ---[ end trace de790a3f637d9e60 ]--- In userfaultfd_release(), we check if 'vm_userfaultfd_ctx' and 'vm_flags&(VM_UFFD_MISSING|VM_UFFD_WP)' are not zero at the same time. If not, it is bug. But we lack checking for VM_USWAP flag. So add it to avoid the false BUG_ON(). This patch also fix several other issues. Fixes: c3e6287f88f5 ("userswap: support userswap via userfaultfd") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Reviewed-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/userfaultfd.c | 12 +++++++++--- mm/memory.c | 1 - 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 0d19adb40dc2e..978fc69c4dbb1 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -884,7 +884,7 @@ static int userfaultfd_release(struct inode *inode, struct file *file) struct vm_area_struct *vma, *prev; /* len == 0 means wake all */ struct userfaultfd_wake_range range = { .len = 0, }; - unsigned long new_flags; + unsigned long new_flags, userfault_flags; bool still_valid; WRITE_ONCE(ctx->released, true); @@ -904,14 +904,18 @@ static int userfaultfd_release(struct inode *inode, struct file *file) still_valid = mmget_still_valid(mm); prev = NULL; for (vma = mm->mmap; vma; vma = vma->vm_next) { + userfault_flags = VM_UFFD_MISSING | VM_UFFD_WP; +#ifdef CONFIG_USERSWAP + userfault_flags |= VM_USWAP; +#endif cond_resched(); BUG_ON(!!vma->vm_userfaultfd_ctx.ctx ^ - !!(vma->vm_flags & (VM_UFFD_MISSING | VM_UFFD_WP))); + !!(vma->vm_flags & userfault_flags)); if (vma->vm_userfaultfd_ctx.ctx != ctx) { prev = vma; continue; } - new_flags = vma->vm_flags & ~(VM_UFFD_MISSING | VM_UFFD_WP); + new_flags = vma->vm_flags & ~userfault_flags; if (still_valid) { prev = vma_merge(mm, prev, vma->vm_start, vma->vm_end, new_flags, vma->anon_vma, @@ -1333,6 +1337,8 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, */ if (uffdio_register.mode & UFFDIO_REGISTER_MODE_USWAP) { uffdio_register.mode &= ~UFFDIO_REGISTER_MODE_USWAP; + if (!uffdio_register.mode) + goto out; vm_flags |= VM_USWAP; end = uffdio_register.range.start + uffdio_register.range.len - 1; vma = find_vma(mm, uffdio_register.range.start); diff --git a/mm/memory.c b/mm/memory.c index 05987251c1c75..d9f4e7dd17a67 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2909,7 +2909,6 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) vmf->address, vma->vm_flags); goto skip_uswap; } - BUG_ON(!(vma->vm_flags & VM_UFFD_MISSING)); ret = handle_userfault(vmf, VM_UFFD_MISSING | VM_USWAP); return ret; } -- 2.25.1

1 1

[PATCH kernel-4.19 1/3] bcache: do not collect data insert info created by write_moving
by liruilin4＠huawei.com 29 Jul '21

29 Jul '21

From: Li Ruilin <liruilin4(a)huawei.com> euleros/rtos inclusion category: bugfix bugzilla: https://bugzilla.openeuler.org/show_bug.cgi?id=26 -------------------------------- commit 6947676c374("bcache: add a framework to perform prefetch") collects data insert info which includes device info got from bio. However, bio created by write_moving here has no device info, causing a null pointer dereference. [ 1497.991768] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [ 1497.991869] PGD 0 P4D 0 [ 1497.991912] Oops: 0000 [#1] SMP PTI [ 1497.991962] CPU: 2 PID: 733 Comm: kworker/2:3 Not tainted 4.19.90+ #33 [ 1497.992030] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 1497.992137] Workqueue: bcache_gc write_moving [bcache] [ 1497.992219] RIP: 0010:bch_data_insert+0x4c/0x140 [bcache] ... [ 1497.993367] Call Trace: [ 1497.993427] ? cached_dev_read_error+0x140/0x140 [bcache] [ 1497.993526] write_moving+0x19e/0x1b0 [bcache] [ 1497.993621] process_one_work+0x1fd/0x440 [ 1497.993742] worker_thread+0x34/0x410 [ 1497.993811] kthread+0x121/0x140 [ 1497.993873] ? process_one_work+0x440/0x440 [ 1497.993946] ? kthread_create_worker_on_cpu+0x70/0x70 [ 1497.994043] ret_from_fork+0x35/0x40 Signed-off-by: Li Ruilin <liruilin4(a)huawei.com> Reviewed-by: Song Chao <chao.song(a)huawei.com> Reviewed-by: Xu Wei <xuwei56(a)huawei.com> --- drivers/md/bcache/request.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c index 984f400d3908..d34fe2b69956 100644 --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -316,12 +316,14 @@ void bch_data_insert(struct closure *cl) trace_bcache_write(op->c, op->inode, op->bio, op->writeback, op->bypass); - msg.offset = op->bio->bi_iter.bi_sector; - msg.length = op->bio->bi_iter.bi_size; - msg.type = ACACHE_INFO_CACHE_INSERT; - msg.dev = bio_dev(op->bio); - msg.start_time = ktime_get_ns(); - save_circ_item(&msg); + if (op->bio->bi_disk) { + msg.offset = op->bio->bi_iter.bi_sector; + msg.length = op->bio->bi_iter.bi_size; + msg.type = ACACHE_INFO_CACHE_INSERT; + msg.dev = bio_dev(op->bio); + msg.start_time = ktime_get_ns(); + save_circ_item(&msg); + } bch_keylist_init(&op->insert_keys); bio_get(op->bio); -- 2.22.GIT

1 2

[PATCH kernel-4.19 1/2] Revert "kretprobe: check re-registration of the same kretprobe earlier"
by Yang Yingliang 28 Jul '21

28 Jul '21

From: Wang ShaoBo <bobo.shaobowang(a)huawei.com> hulk inclusion category: bugfix bugzilla: 31369 CVE: NA ----------------------------------------------- This reverts commit dd99d9a22a13b9a33dd829048cdf8fe4dc50556b. Following patches mainline has fixed this issue: 0188b87899ff ("kretprobe: Avoid re-registration of the same kretprobe earlier") 33b1d1466885 ("kprobes: Warn if the kprobe is reregistered") Signed-off-by: Wang ShaoBo <bobo.shaobowang(a)huawei.com> Reviewed-by: Cheng Jian <cj.chengjian(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/kprobes.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 60e7f181a97d3..91985ae1fe0b3 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1979,14 +1979,6 @@ int register_kretprobe(struct kretprobe *rp) } } - /* - * Return error if it's being re-registered, - * also give a warning message to the developer. - */ - ret = check_kprobe_rereg(&rp->kp); - if (WARN_ON(ret)) - return ret; - rp->kp.pre_handler = pre_handler_kretprobe; rp->kp.post_handler = NULL; rp->kp.fault_handler = NULL; -- 2.25.1

1 1

High quliaty JYMED Foley Catheter Strap and foam belt products factory Shanghai
by allan01＠jyylsh.cn 28 Jul '21

28 Jul '21

Only they who fulfill their duties in everyday matters will fulfill them on great occasions.hello Sir , Shanghai JianYing Medical company is the main medical bandages, Catheter holder leg strap fetal belt, CPAP headgear strap and pad manufacturer in China since 2006, our major customers are those have very good reputation and renown companies in the field。 We believe that you can rely on us as we provide you quite satisfy factory service and products with best quality in the world. Our products are medical bandages, fetal belt,CPAP headgear strap . We are very happy if you do not hesitate to send us any of your inquiries and we will always give satisfy factory services. Looking forward to hearing from you at your convenience. Thanks & Best regards, Janey Shanghai QiuMing Textile Co.,Ltd. Shanghai JianYing Medical Technology Co.,Ltd. Area B 4th Floor Building 11, Lane 258, Yinlong road Jiading district, Shanghai China 201806 Mob: +86 177 49730956 WhatsApp: +86 177 49730956 Web:www.cpapjy.com Web: http://www.elasticmedicalbelt.com/news.html If you are not interested in our products and services, you can unsubscribed our email and you will no longer receive similar email notifications.

1 0

[PATCH openEuler-21.09 0/7] Support for kernel seamless upgrade
by Zheng Zengkai 27 Jul '21

27 Jul '21

We introduced several features to support kernel seamless upgrade: 1 pin mem function for checkpoint and restore: 2 pid reserve function for checkpoint and restore 3 cpu park to accelerate cpus' down and up 4 quick kexec to accelerate relocating kernel images 5 legacy pmem support for arm64 ----------------------------------- Jingxian He (2): mm: add pin memory method for checkpoint add restore pid: add pid reserve method for checkpoint and recover Sang Yan (4): kexec: Add quick kexec support for kernel arm64: Reserve memory for quick kexec arm64: smp: Add support for cpu park config: enable kernel hotupgrade features by default ZhuLing (1): arm64: Add memmap parameter and register pmem arch/Kconfig | 10 + arch/arm64/Kconfig | 33 + arch/arm64/configs/openeuler_defconfig | 8 + arch/arm64/include/asm/kexec.h | 6 + arch/arm64/include/asm/smp.h | 15 + arch/arm64/kernel/Makefile | 2 + arch/arm64/kernel/cpu-park.S | 58 ++ arch/arm64/kernel/machine_kexec.c | 2 +- arch/arm64/kernel/pmem.c | 35 + arch/arm64/kernel/process.c | 4 + arch/arm64/kernel/setup.c | 26 + arch/arm64/kernel/smp.c | 231 +++++ arch/arm64/mm/init.c | 258 ++++++ drivers/char/Kconfig | 7 + drivers/char/Makefile | 1 + drivers/char/pin_memory.c | 209 +++++ drivers/nvdimm/Kconfig | 5 + drivers/nvdimm/Makefile | 2 +- fs/proc/task_mmu.c | 138 +++ include/linux/crash_core.h | 5 + include/linux/ioport.h | 1 + include/linux/kexec.h | 24 +- include/linux/pin_mem.h | 99 ++ include/uapi/linux/kexec.h | 1 + kernel/crash_core.c | 11 + kernel/kexec.c | 10 + kernel/kexec_core.c | 42 +- kernel/pid.c | 10 + mm/Kconfig | 18 + mm/Makefile | 1 + mm/huge_memory.c | 63 ++ mm/memory.c | 65 ++ mm/pin_mem.c | 1142 ++++++++++++++++++++++++ 33 files changed, 2527 insertions(+), 15 deletions(-) create mode 100644 arch/arm64/kernel/cpu-park.S create mode 100644 arch/arm64/kernel/pmem.c create mode 100644 drivers/char/pin_memory.c create mode 100644 include/linux/pin_mem.h create mode 100644 mm/pin_mem.c -- 2.20.1

1 7