July 2023 - Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS 0/2] Fix CDM node problems
by Zhang Zekun 24 Jul '23

24 Jul '23

Fix problem introduced by feature CDM node, which might alloc memory from other no cdm nodes. Zhou Guanghui (2): mm: fix ignore cpuset enforcement mm: fix alloc CDM node memory for MPOL_BIND mm/page_alloc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.17.1

2 3

答复: [RFC 1/1] Optimizing the rand function on arm64 platforms
by tiantao (H) 24 Jul '23

24 Jul '23

Thanks for the reply. Using FEAT_RNG can be a very big performance boost, any suggestions for applying the FEAT_RNG feature to glibc? -----邮件原件----- 发件人: Xi Ruoyao <xry111(a)xry111.site> 发送时间: 2023年7月24日 11:50 收件人: tiantao (H) <tiantao6(a)hisilicon.com>; libc-alpha(a)sourceware.org 抄送: kernel(a)openeuler.org 主题: Re: [RFC 1/1] Optimizing the rand function on arm64 platforms On Mon, 2023-07-24 at 10:32 +0800, Tian Tao via Libc-alpha wrote: > Armv8.5 adds the FEAT_RNG feature so that true random numbers can be > obtained from the cpu. This optimization is therefore proposed for the > arm64 platform. NAK. Glibc documentation explicitly says: You can obtain repeatable sequences of numbers on a particular machine type by specifying the same initial seed value for the random number generator. This rand() implementation obviously does not satisfy this requirement. > > Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> > --- > stdlib/rand.c | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > > diff --git a/stdlib/rand.c b/stdlib/rand.c index > c250c065e4..f199dbd65f 100644 > --- a/stdlib/rand.c > +++ b/stdlib/rand.c > @@ -19,10 +19,42 @@ > > #undef rand > > +#ifdef __aarch64__ > +// A global variable to indicate whether rndr instruction is > supported > +static int rndr_supported = 0; > +// A function prototype to check rndr support static void > +check_rndr_support (void) __attribute__ ((constructor)); #endif > > /* Return a random integer between 0 and RAND_MAX. */ > int > rand (void) > { > + // Use armv8.5 rndr instruction if supported #ifdef __aarch64__ > + if (rndr_supported) { > + unsigned int r; > + asm volatile("mrs %0, s3_3_c2_c4_0" : "=r" (r)); > + // Discard the least random bit > + r >>=1; > + return (int) r; > + } > +#endif > return (int) __random (); > } > + > +#ifdef __aarch64__ > +// A function to check rndr support and set the global variable > accordingly > +static void > +check_rndr_support (void) > +{ > + unsigned long isar0; > + // Read the ID_AA64ISAR0_EL1 register to check the rndr feature > + asm volatile("mrs %0, id_aa64isar0_el1" : "=r" (isar0)); > + // Check the bits [63:60] for the rndr feature > + if ((isar0 >> 60) & 0xf) { > + // Set the global variable to indicate rndr support > + rndr_supported = 1; > + } > +} > +#endif -- Xi Ruoyao <xry111(a)xry111.site> School of Aerospace Science and Technology, Xidian University

1 0

Re: EAS适配大数据环境验证
by Ruan Jinjie 24 Jul '23

24 Jul '23

关键线程demo 大数据测试 On 2023/7/20 10:51, Ruan Jinjie wrote: > bpftrace测调度延迟脚本 > > On 2023/7/18 12:06, Ruan Jinjie wrote: >> >> >> On 2023/7/17 10:47, Ruan Jinjie wrote: >>> >>> >>> On 2023/7/15 18:18, Ruan Jinjie wrote: >>>> >>>> >>>> On 2023/7/15 10:36, Ruan Jinjie wrote: >>>>> >>>>> >>>>> On 2023/7/14 13:18, Ruan Jinjie wrote: >>>>>> >>>>>> >>>>>> On 2023/7/13 13:03, Ruan Jinjie wrote: >>>>>>> 潮汐适配SP2 >>>>>>> >>>>>>> On 2023/7/13 10:58, Ruan Jinjie wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2023/7/12 17:23, Ruan Jinjie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2023/7/5 17:24, Ruan Jinjie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2023/7/5 17:19, Ruan Jinjie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2023/7/4 20:34, Ruan Jinjie wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2023/7/4 13:04, Ruan Jinjie wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2023/6/3 10:52, Ruan Jinjie wrote:

1 0

[RFC 1/1] Optimizing the rand function on arm64 platforms
by Tian Tao 24 Jul '23

24 Jul '23

Armv8.5 adds the FEAT_RNG feature so that true random numbers can be obtained from the cpu. This optimization is therefore proposed for the arm64 platform. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- stdlib/rand.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/stdlib/rand.c b/stdlib/rand.c index c250c065e4..f199dbd65f 100644 --- a/stdlib/rand.c +++ b/stdlib/rand.c @@ -19,10 +19,42 @@ #undef rand +#ifdef __aarch64__ +// A global variable to indicate whether rndr instruction is supported +static int rndr_supported = 0; +// A function prototype to check rndr support +static void check_rndr_support (void) __attribute__ ((constructor)); +#endif /* Return a random integer between 0 and RAND_MAX. */ int rand (void) { + // Use armv8.5 rndr instruction if supported +#ifdef __aarch64__ + if (rndr_supported) { + unsigned int r; + asm volatile("mrs %0, s3_3_c2_c4_0" : "=r" (r)); + // Discard the least random bit + r >>=1; + return (int) r; + } +#endif return (int) __random (); } + +#ifdef __aarch64__ +// A function to check rndr support and set the global variable accordingly +static void +check_rndr_support (void) +{ + unsigned long isar0; + // Read the ID_AA64ISAR0_EL1 register to check the rndr feature + asm volatile("mrs %0, id_aa64isar0_el1" : "=r" (isar0)); + // Check the bits [63:60] for the rndr feature + if ((isar0 >> 60) & 0xf) { + // Set the global variable to indicate rndr support + rndr_supported = 1; + } +} +#endif -- 2.33.0

1 0

【会议通知】 openEuler-23.09开发讨论
by Meeting Book 21 Jul '23

21 Jul '23

会议主题 Subject openEuler-23.09开发讨论会议时间 Time 2023-07-24 10:30-12:00 (UTC+08:00)Beijing 会议地点 Location Welink视频会议 Welink Video Meeting 加入会议(External)<https://meeting.huaweicloud.com/welink/#/j/97708050/7CrJkkOXwkz174GgyAwFZLc…> 会议ID Meeting ID 97708050 Guest密码 Voice access code 890236 召集人 Convener 郑增凯提示 Tips 请点击会议链接加入会议,首次使用请在入会界面根据提示下载并安装客户端后输入ID入会。 Click the meeting link to join the meeting. For the first time, download and install the client as prompted and enter the ID to join the meeting

1 0

[PATCH openEuler-23.09 0/8] arm64: Add framework to turn an IPI as NMI
by Ruan Jinjie 21 Jul '23

21 Jul '23

arm64: Add framework to turn an IPI as NMI Sumit Garg (7): arm64: Add framework to turn IPI as NMI irqchip/gic-v3: Enable support for SGIs to act as NMIs arm64: smp: Assign and setup an IPI as NMI nmi: backtrace: Allow runtime arch specific override arm64: ipi_nmi: Add support for NMI backtrace kgdb: Expose default CPUs roundup fallback mechanism arm64: kgdb: Roundup cpus using IPI as NMI Xiongfeng Wang (1): arm64: ipi_nmi: fix compile error when CONFIG_KGDB is disabled arch/arm/include/asm/irq.h | 2 +- arch/arm/kernel/smp.c | 3 +- arch/arm64/include/asm/irq.h | 6 +++ arch/arm64/include/asm/nmi.h | 17 +++++++ arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/ipi_nmi.c | 85 ++++++++++++++++++++++++++++++++ arch/arm64/kernel/kgdb.c | 18 +++++++ arch/arm64/kernel/smp.c | 8 +++ arch/mips/include/asm/irq.h | 2 +- arch/mips/kernel/process.c | 3 +- arch/powerpc/include/asm/nmi.h | 2 +- arch/powerpc/kernel/stacktrace.c | 3 +- arch/sparc/include/asm/irq_64.h | 2 +- arch/sparc/kernel/process_64.c | 4 +- arch/x86/include/asm/irq.h | 2 +- arch/x86/kernel/apic/hw_nmi.c | 3 +- drivers/irqchip/irq-gic-v3.c | 29 ++++++++--- include/linux/kgdb.h | 12 +++++ include/linux/nmi.h | 12 ++--- kernel/debug/debug_core.c | 8 ++- 20 files changed, 195 insertions(+), 28 deletions(-) create mode 100644 arch/arm64/include/asm/nmi.h create mode 100644 arch/arm64/kernel/ipi_nmi.c -- 2.34.1

2 9

[PATCH OLK-5.10] ipv6: Fix an uninit variable access bug in __ip6_make_skb()
by Wang Yufen 21 Jul '23

21 Jul '23

From: Ziyang Xuan <william.xuanziyang(a)huawei.com> stable inclusion from stable-v5.10.178 commit 605b056d63302ae84eb136e88d4df49124bd5e0d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I71Z4N Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ea30388baebcce37fd594d425a65037ca35e59e8 ] Syzbot reported a bug as following: ===================================================== BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 ip6_finish_skb include/net/ipv6.h:1122 [inline] ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987 rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579 rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 alloc_skb include/linux/skbuff.h:1270 [inline] __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684 ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854 rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd It is because icmp6hdr does not in skb linear region under the scenario of SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly will trigger the uninit variable access bug. Use a local variable icmp6_type to carry the correct value in different scenarios. Fixes: 14878f75abd5 ("[IPV6]: Add ICMPMsgStats MIB (RFC 4293) [rev 2]") Reported-by: syzbot+8257f4dcef79de670baf(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=3d605ec1d0a7f2a269a1a6936ac7f2b85975ee… Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Wang Yufen <wangyufen(a)huawei.com> --- net/ipv6/ip6_output.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index f30cc72..8be38a1 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1920,8 +1920,13 @@ struct sk_buff *__ip6_make_skb(struct sock *sk, IP6_UPD_PO_STATS(net, rt->rt6i_idev, IPSTATS_MIB_OUT, skb->len); if (proto == IPPROTO_ICMPV6) { struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb)); + u8 icmp6_type; - ICMP6MSGOUT_INC_STATS(net, idev, icmp6_hdr(skb)->icmp6_type); + if (sk->sk_socket->type == SOCK_RAW && !inet_sk(sk)->hdrincl) + icmp6_type = fl6->fl6_icmp_type; + else + icmp6_type = icmp6_hdr(skb)->icmp6_type; + ICMP6MSGOUT_INC_STATS(net, idev, icmp6_type); ICMP6_INC_STATS(net, idev, ICMP6_MIB_OUTMSGS); } -- 1.8.3.1

2 1

[PATCH openEuler-22.03-LTS-SP2] block: don't set GD_NEED_PART_SCAN if scan partition failed
by Li Lingfeng 21 Jul '23

21 Jul '23

From: Yu Kuai <yukuai3(a)huawei.com> mainline inclusion from mainline-v6.3-rc6~9^2 commit 3723091ea1884d599cc8b8bf719d6f42e8d4d8b1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F7J3 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Currently if disk_scan_partitions() failed, GD_NEED_PART_SCAN will still set, and partition scan will be proceed again when blkdev_get_by_dev() is called. However, this will cause a problem that re-assemble partitioned raid device will creat partition for underlying disk. Test procedure: mdadm -CR /dev/md0 -l 1 -n 2 /dev/sda /dev/sdb -e 1.0 sgdisk -n 0:0:+100MiB /dev/md0 blockdev --rereadpt /dev/sda blockdev --rereadpt /dev/sdb mdadm -S /dev/md0 mdadm -A /dev/md0 /dev/sda /dev/sdb Test result: underlying disk partition and raid partition can be observed at the same time Note that this can still happen in come corner cases that GD_NEED_PART_SCAN can be set for underlying disk while re-assemble raid device. Fixes: e5cfefa97bcc ("block: fix scan partition for exclusively open device again") Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: block/genhd.c Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- block/genhd.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/block/genhd.c b/block/genhd.c index 3c34dd011585..83f407e1563a 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -770,6 +770,13 @@ int disk_scan_partitions(struct gendisk *disk, fmode_t mode) else blkdev_put(bdev, mode & ~FMODE_EXCL); + /* + * If blkdev_get_by_dev() failed early, GD_NEED_PART_SCAN is still set, + * and this will cause that re-assemble partitioned raid device will + * creat partition for underlying disk. + */ + clear_bit(GD_NEED_PART_SCAN, &disk->state); + if (!(mode & FMODE_EXCL)) { bd_abort_claiming(claim, claim, disk_scan_partitions); bdput(claim); -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] block: don't set GD_NEED_PART_SCAN if scan partition failed
by Li Lingfeng 21 Jul '23

21 Jul '23

From: Yu Kuai <yukuai3(a)huawei.com> mainline inclusion from mainline-v6.3-rc6~9^2 commit 3723091ea1884d599cc8b8bf719d6f42e8d4d8b1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F7J3 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Currently if disk_scan_partitions() failed, GD_NEED_PART_SCAN will still set, and partition scan will be proceed again when blkdev_get_by_dev() is called. However, this will cause a problem that re-assemble partitioned raid device will creat partition for underlying disk. Test procedure: mdadm -CR /dev/md0 -l 1 -n 2 /dev/sda /dev/sdb -e 1.0 sgdisk -n 0:0:+100MiB /dev/md0 blockdev --rereadpt /dev/sda blockdev --rereadpt /dev/sdb mdadm -S /dev/md0 mdadm -A /dev/md0 /dev/sda /dev/sdb Test result: underlying disk partition and raid partition can be observed at the same time Note that this can still happen in come corner cases that GD_NEED_PART_SCAN can be set for underlying disk while re-assemble raid device. Fixes: e5cfefa97bcc ("block: fix scan partition for exclusively open device again") Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: block/genhd.c Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- block/genhd.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/block/genhd.c b/block/genhd.c index 3c34dd011585..83f407e1563a 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -770,6 +770,13 @@ int disk_scan_partitions(struct gendisk *disk, fmode_t mode) else blkdev_put(bdev, mode & ~FMODE_EXCL); + /* + * If blkdev_get_by_dev() failed early, GD_NEED_PART_SCAN is still set, + * and this will cause that re-assemble partitioned raid device will + * creat partition for underlying disk. + */ + clear_bit(GD_NEED_PART_SCAN, &disk->state); + if (!(mode & FMODE_EXCL)) { bd_abort_claiming(claim, claim, disk_scan_partitions); bdput(claim); -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS] block: don't set GD_NEED_PART_SCAN if scan partition failed
by Li Lingfeng 21 Jul '23

21 Jul '23

From: Yu Kuai <yukuai3(a)huawei.com> mainline inclusion from mainline-v6.3-rc6 commit 3723091ea1884d599cc8b8bf719d6f42e8d4d8b1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F7J3 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Currently if disk_scan_partitions() failed, GD_NEED_PART_SCAN will still set, and partition scan will be proceed again when blkdev_get_by_dev() is called. However, this will cause a problem that re-assemble partitioned raid device will creat partition for underlying disk. Test procedure: mdadm -CR /dev/md0 -l 1 -n 2 /dev/sda /dev/sdb -e 1.0 sgdisk -n 0:0:+100MiB /dev/md0 blockdev --rereadpt /dev/sda blockdev --rereadpt /dev/sdb mdadm -S /dev/md0 mdadm -A /dev/md0 /dev/sda /dev/sdb Test result: underlying disk partition and raid partition can be observed at the same time Note that this can still happen in come corner cases that GD_NEED_PART_SCAN can be set for underlying disk while re-assemble raid device. Fixes: e5cfefa97bcc ("block: fix scan partition for exclusively open device again") Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: block/genhd.c Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- block/genhd.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/block/genhd.c b/block/genhd.c index 3c34dd011585..83f407e1563a 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -770,6 +770,13 @@ int disk_scan_partitions(struct gendisk *disk, fmode_t mode) else blkdev_put(bdev, mode & ~FMODE_EXCL); + /* + * If blkdev_get_by_dev() failed early, GD_NEED_PART_SCAN is still set, + * and this will cause that re-assemble partitioned raid device will + * creat partition for underlying disk. + */ + clear_bit(GD_NEED_PART_SCAN, &disk->state); + if (!(mode & FMODE_EXCL)) { bd_abort_claiming(claim, claim, disk_scan_partitions); bdput(claim); -- 2.31.1

2 1

[PATCH openEuler-23.09 0/8] arm64: Add framework to turn an IPI as NMI
by Ruan Jinjie 20 Jul '23

20 Jul '23

arm64: Add framework to turn an IPI as NMI Sumit Garg (7): arm64: Add framework to turn IPI as NMI irqchip/gic-v3: Enable support for SGIs to act as NMIs arm64: smp: Assign and setup an IPI as NMI nmi: backtrace: Allow runtime arch specific override arm64: ipi_nmi: Add support for NMI backtrace kgdb: Expose default CPUs roundup fallback mechanism arm64: kgdb: Roundup cpus using IPI as NMI Xiongfeng Wang (1): arm64: ipi_nmi: fix compile error when CONFIG_KGDB is disabled arch/arm/include/asm/irq.h | 2 +- arch/arm/kernel/smp.c | 3 +- arch/arm64/include/asm/irq.h | 6 +++ arch/arm64/include/asm/nmi.h | 17 +++++++ arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/ipi_nmi.c | 85 ++++++++++++++++++++++++++++++++ arch/arm64/kernel/kgdb.c | 18 +++++++ arch/arm64/kernel/smp.c | 8 +++ arch/mips/include/asm/irq.h | 2 +- arch/mips/kernel/process.c | 3 +- arch/powerpc/include/asm/nmi.h | 2 +- arch/powerpc/kernel/stacktrace.c | 3 +- arch/sparc/include/asm/irq_64.h | 2 +- arch/sparc/kernel/process_64.c | 4 +- arch/x86/include/asm/irq.h | 2 +- arch/x86/kernel/apic/hw_nmi.c | 3 +- drivers/irqchip/irq-gic-v3.c | 29 ++++++++--- include/linux/kgdb.h | 12 +++++ include/linux/nmi.h | 12 ++--- kernel/debug/debug_core.c | 8 ++- 20 files changed, 195 insertions(+), 28 deletions(-) create mode 100644 arch/arm64/include/asm/nmi.h create mode 100644 arch/arm64/kernel/ipi_nmi.c -- 2.34.1

2 9

[PATCH V2 openEuler-22.03-LTS 0/2] Fix alloc CDM node memory
by Zhang Zekun 20 Jul '23

20 Jul '23

Fix problem introduced by feature CDM node, which might alloc memory from other no cdm nodes. v2: -fix commit message warning Zhou Guanghui (2): mm: fix ignore cpuset enforcement mm: fix alloc CDM node memory for MPOL_BIND mm/page_alloc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.17.1

1 2

[PATCH 0/3] openEuler kernel checkpatch test
by Jialin Zhang 20 Jul '23

20 Jul '23

This PR is only for openEuler kernel checkpatch test Inki Dae (1): drm/exynos: vidi: fix a wrong error return Min Li (2): drm/radeon: fix race condition UAF in radeon_gem_set_domain_ioctl drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 -- drivers/gpu/drm/radeon/radeon_gem.c | 4 +--- 3 files changed, 2 insertions(+), 6 deletions(-) -- 2.25.1

1 3

[PATCH openEuler-1.0-LTS] media: dvb-core: Fix use-after-free due on race condition at dvb_net
by Cai Xinchen 20 Jul '23

20 Jul '23

From: Hyunwoo Kim <imv4bel(a)gmail.com> stable inclusion from stable-v4.19.285 commit 7bb9c6e05efcecb15b0354d574efbc36ca321d75 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I635JD CVE: CVE-2022-45886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4172385b0c9ac366dcab78eda48c26814b87ed1a ] A race condition may occur between the .disconnect function, which is called when the device is disconnected, and the dvb_device_open() function, which is called when the device node is open()ed. This results in several types of UAFs. The root cause of this is that you use the dvb_device_open() function, which does not implement a conditional statement that checks 'dvbnet->exit'. So, add 'remove_mutex` to protect 'dvbnet->exit' and use locked_dvb_net_open() function to check 'dvbnet->exit'. [mchehab: fix a checkpatch warning] Link: https://lore.kernel.org/linux-media/20221117045925.14297-3-imv4bel@gmail.com Signed-off-by: Hyunwoo Kim <imv4bel(a)gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- drivers/media/dvb-core/dvb_net.c | 38 +++++++++++++++++++++++++++++--- include/media/dvb_net.h | 4 ++++ 2 files changed, 39 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c index 10f78109bb3f..d8bdca2bf566 100644 --- a/drivers/media/dvb-core/dvb_net.c +++ b/drivers/media/dvb-core/dvb_net.c @@ -1562,15 +1562,43 @@ static long dvb_net_ioctl(struct file *file, return dvb_usercopy(file, cmd, arg, dvb_net_do_ioctl); } +static int locked_dvb_net_open(struct inode *inode, struct file *file) +{ + struct dvb_device *dvbdev = file->private_data; + struct dvb_net *dvbnet = dvbdev->priv; + int ret; + + if (mutex_lock_interruptible(&dvbnet->remove_mutex)) + return -ERESTARTSYS; + + if (dvbnet->exit) { + mutex_unlock(&dvbnet->remove_mutex); + return -ENODEV; + } + + ret = dvb_generic_open(inode, file); + + mutex_unlock(&dvbnet->remove_mutex); + + return ret; +} + static int dvb_net_close(struct inode *inode, struct file *file) { struct dvb_device *dvbdev = file->private_data; struct dvb_net *dvbnet = dvbdev->priv; + mutex_lock(&dvbnet->remove_mutex); + dvb_generic_release(inode, file); - if(dvbdev->users == 1 && dvbnet->exit == 1) + if (dvbdev->users == 1 && dvbnet->exit == 1) { + mutex_unlock(&dvbnet->remove_mutex); wake_up(&dvbdev->wait_queue); + } else { + mutex_unlock(&dvbnet->remove_mutex); + } + return 0; } @@ -1578,7 +1606,7 @@ static int dvb_net_close(struct inode *inode, struct file *file) static const struct file_operations dvb_net_fops = { .owner = THIS_MODULE, .unlocked_ioctl = dvb_net_ioctl, - .open = dvb_generic_open, + .open = locked_dvb_net_open, .release = dvb_net_close, .llseek = noop_llseek, }; @@ -1597,10 +1625,13 @@ void dvb_net_release (struct dvb_net *dvbnet) { int i; + mutex_lock(&dvbnet->remove_mutex); dvbnet->exit = 1; + mutex_unlock(&dvbnet->remove_mutex); + if (dvbnet->dvbdev->users < 1) wait_event(dvbnet->dvbdev->wait_queue, - dvbnet->dvbdev->users==1); + dvbnet->dvbdev->users == 1); dvb_unregister_device(dvbnet->dvbdev); @@ -1619,6 +1650,7 @@ int dvb_net_init (struct dvb_adapter *adap, struct dvb_net *dvbnet, int i; mutex_init(&dvbnet->ioctl_mutex); + mutex_init(&dvbnet->remove_mutex); dvbnet->demux = dmx; for (i=0; i<DVB_NET_DEVICES_MAX; i++) diff --git a/include/media/dvb_net.h b/include/media/dvb_net.h index 5e31d37f25fa..cc01dffcc9f3 100644 --- a/include/media/dvb_net.h +++ b/include/media/dvb_net.h @@ -41,6 +41,9 @@ * @exit: flag to indicate when the device is being removed. * @demux: pointer to &struct dmx_demux. * @ioctl_mutex: protect access to this struct. + * @remove_mutex: mutex that avoids a race condition between a callback + * called when the hardware is disconnected and the + * file_operations of dvb_net. * * Currently, the core supports up to %DVB_NET_DEVICES_MAX (10) network * devices. @@ -53,6 +56,7 @@ struct dvb_net { unsigned int exit:1; struct dmx_demux *demux; struct mutex ioctl_mutex; + struct mutex remove_mutex; }; /** -- 2.17.1

2 1

[openEuler-22.03-LTS 1/2] mm: fix ignore cpuset enforcement
by Zhang Zekun 20 Jul '23

20 Jul '23

From: Zhou Guanghui <zhouguanghui1(a)huawei.com> ascend inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I612UG CVE: NA ----------------------------------------------------- Since the current condition ignores the cpuset enforcement by adding __GFP_THISNODEi to the gfp_mask, this will result in allocations that specify __GFP_THISNODE and non-cdm nodes not subject to cpuset restrictions. For example, procA pid 1000: node 0 cpus: 0 1 2 3 node 0 free: 57199MB node 1 cpus: 4 5 6 7 node 1 free: 55930MB cpuset/test/cpuset.mems 1 cpuset/test/tasks 1000 cpuset/test/cpuset.cpus 0-3 No cdm node exists. When procA malloc 100MB memory, the result is: node 0 cpus: 0 1 2 3 node 0 free: 57099MB node 1 cpus: 4 5 6 7 node 1 free: 55930MB This is not what we expected, and in fact 100 MB of memory should be allocated from node1. The reason for this problem is that THP specifies __GFP_THISNODE to attempt to allocate from the local node. Therefore, the cpuset enforcement should be ignored only when explicitly allocating memory from the cdm node using __GFP_ THISNODE. Signed-off-by: Zhou Guanghui <zhouguanghui1(a)huawei.com> --- mm/page_alloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index df3723c0a819..d090465de32b 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4946,7 +4946,8 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, unsigned int order, ac->migratetype = gfp_migratetype(gfp_mask); #ifdef CONFIG_COHERENT_DEVICE - if (cpusets_enabled() && !(*alloc_gfp & __GFP_THISNODE)) { + if (cpusets_enabled() && + (!(*alloc_gfp & __GFP_THISNODE) || !is_cdm_node(preferred_nid))) { #else if (cpusets_enabled()) { #endif -- 2.17.1

1 1

[PATCH OLK-5.10 0/2] ksmbd: fix two ksmbd cve issue
by Long Li 20 Jul '23

20 Jul '23

Chih-Yen Chang (1): ksmbd: fix global-out-of-bounds in smb2_find_context_vals Namjae Jeon (1): ksmbd: validate command payload size fs/ksmbd/oplock.c | 5 +++-- fs/ksmbd/oplock.h | 2 +- fs/ksmbd/smb2misc.c | 23 ++++++++++++----------- fs/ksmbd/smb2pdu.c | 14 +++++++------- 4 files changed, 23 insertions(+), 21 deletions(-) -- 2.31.1

2 3

[openEuler-22.03-LTS 1/2] mm: fix ignore cpuset enforcement
by Zhang Zekun 20 Jul '23

20 Jul '23

From: Zhou Guanghui <zhouguanghui1(a)huawei.com> ascend inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I612UG CVE: NA ----------------------------------------------------- Since the current condition ignores the cpuset enforcement by adding __GFP_THISNODEi to the gfp_mask, this will result in allocations that specify __GFP_THISNODE and non-cdm nodes not subject to cpuset restrictions. For example, procA pid 1000: node 0 cpus: 0 1 2 3 node 0 free: 57199MB node 1 cpus: 4 5 6 7 node 1 free: 55930MB cpuset/test/cpuset.mems 1 cpuset/test/tasks 1000 cpuset/test/cpuset.cpus 0-3 No cdm node exists. When procA malloc 100MB memory, the result is: node 0 cpus: 0 1 2 3 node 0 free: 57099MB node 1 cpus: 4 5 6 7 node 1 free: 55930MB This is not what we expected, and in fact 100 MB of memory should be allocated from node1. The reason for this problem is that THP specifies __GFP_THISNODE to attempt to allocate from the local node. Therefore, the cpuset enforcement should be ignored only when explicitly allocating memory from the cdm node using __GFP_ THISNODE. Signed-off-by: Zhou Guanghui <zhouguanghui1(a)huawei.com> --- mm/page_alloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index df3723c0a819..d090465de32b 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4946,7 +4946,8 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, unsigned int order, ac->migratetype = gfp_migratetype(gfp_mask); #ifdef CONFIG_COHERENT_DEVICE - if (cpusets_enabled() && !(*alloc_gfp & __GFP_THISNODE)) { + if (cpusets_enabled() && + (!(*alloc_gfp & __GFP_THISNODE) || !is_cdm_node(preferred_nid))) { #else if (cpusets_enabled()) { #endif -- 2.17.1

1 1

[PATCH openEuler-22.03-LTS-SP2] dm stats: check for and propagate alloc_percpu failure
by Li Lingfeng 20 Jul '23

20 Jul '23

From: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> mainline inclusion from mainline-v6.3-rc4 commit d3aa3e060c4a80827eb801fc448debc9daa7c46b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7I2L8 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Check alloc_precpu()'s return value and return an error from dm_stats_init() if it fails. Update alloc_dev() to fail if dm_stats_init() does. Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup() even if dm-stats isn't being actively used. Fixes: fd2ed4d25270 ("dm: add statistics support") Cc: stable(a)vger.kernel.org Signed-off-by: Jiasheng Jiang <jiasheng(a)iscas.ac.cn> Signed-off-by: Mike Snitzer <snitzer(a)kernel.org> Conflicts: drivers/md/dm-stats.c drivers/md/dm.c Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/md/dm-stats.c | 7 ++++++- drivers/md/dm-stats.h | 2 +- drivers/md/dm.c | 4 +++- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/md/dm-stats.c b/drivers/md/dm-stats.c index 55443a6598fa..4029281ca383 100644 --- a/drivers/md/dm-stats.c +++ b/drivers/md/dm-stats.c @@ -188,7 +188,7 @@ static int dm_stat_in_flight(struct dm_stat_shared *shared) atomic_read(&shared->in_flight[WRITE]); } -void dm_stats_init(struct dm_stats *stats) +int dm_stats_init(struct dm_stats *stats) { int cpu; struct dm_stats_last_position *last; @@ -196,11 +196,16 @@ void dm_stats_init(struct dm_stats *stats) mutex_init(&stats->mutex); INIT_LIST_HEAD(&stats->list); stats->last = alloc_percpu(struct dm_stats_last_position); + if (!stats->last) + return -ENOMEM; + for_each_possible_cpu(cpu) { last = per_cpu_ptr(stats->last, cpu); last->last_sector = (sector_t)ULLONG_MAX; last->last_rw = UINT_MAX; } + + return 0; } void dm_stats_cleanup(struct dm_stats *stats) diff --git a/drivers/md/dm-stats.h b/drivers/md/dm-stats.h index 2ddfae678f32..dcac11fce03b 100644 --- a/drivers/md/dm-stats.h +++ b/drivers/md/dm-stats.h @@ -22,7 +22,7 @@ struct dm_stats_aux { unsigned long long duration_ns; }; -void dm_stats_init(struct dm_stats *st); +int dm_stats_init(struct dm_stats *st); void dm_stats_cleanup(struct dm_stats *st); struct mapped_device; diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 1cb2a84f2403..0c9ce43f3b53 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1904,7 +1904,9 @@ static struct mapped_device *alloc_dev(int minor) if (!md->bdev) goto bad; - dm_stats_init(&md->stats); + r = dm_stats_init(&md->stats); + if (r < 0) + goto bad; /* Populate the mapping, nobody knows we exist yet */ spin_lock(&_minor_lock); -- 2.31.1

2 1

[PATCH OLK-5.10 0/3] CVE-2023-3567 fix patches
by Lu Jialin 20 Jul '23

20 Jul '23

First is the patch to fix CVE-2023-3567. The latter two patches are the bugfix patches for the first patch. George Kennedy (2): vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF vc_screen: modify vcs_size() handling in vcs_read() Thomas Weißschuh (1): vc_screen: don't clobber return value in vcs_read drivers/tty/vt/vc_screen.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.17.1

2 4

[PATCH OLK-5.10] ksmbd: fix out-of-bound read in deassemble_neg_contexts()
by Li Lingfeng 20 Jul '23

20 Jul '23

From: Namjae Jeon <linkinjeon(a)kernel.org> mainline inclusion from mainline-v6.4-rc6 commit f1a411873c85b642f13b01f21b534c2bab81fc1b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7LU2Q CVE: CVE-2023-38427 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/f… -------------------------------- The check in the beginning is `clen + sizeof(struct smb2_neg_context) <= len_of_ctxts`, but in the end of loop, `len_of_ctxts` will subtract `((clen + 7) & ~0x7) + sizeof(struct smb2_neg_context)`, which causes integer underflow when clen does the 8 alignment. We should use `(clen + 7) & ~0x7` in the check to avoid underflow from happening. Then there are some variables that need to be declared unsigned instead of signed. [ 11.671070] BUG: KASAN: slab-out-of-bounds in smb2_handle_negotiate+0x799/0x1610 [ 11.671533] Read of size 2 at addr ffff888005e86cf2 by task kworker/0:0/7 ... [ 11.673383] Call Trace: [ 11.673541] <TASK> [ 11.673679] dump_stack_lvl+0x33/0x50 [ 11.673913] print_report+0xcc/0x620 [ 11.674671] kasan_report+0xae/0xe0 [ 11.675171] kasan_check_range+0x35/0x1b0 [ 11.675412] smb2_handle_negotiate+0x799/0x1610 [ 11.676217] ksmbd_smb_negotiate_common+0x526/0x770 [ 11.676795] handle_ksmbd_work+0x274/0x810 ... Cc: stable(a)vger.kernel.org Signed-off-by: Chih-Yen Chang <cc85nod(a)gmail.com> Tested-by: Chih-Yen Chang <cc85nod(a)gmail.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflict: fs/smb/server/smb2pdu.c Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/ksmbd/smb2pdu.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index 18e176fcddf0..9add135cb5da 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -978,13 +978,13 @@ static void decode_sign_cap_ctxt(struct ksmbd_conn *conn, static __le32 deassemble_neg_contexts(struct ksmbd_conn *conn, struct smb2_negotiate_req *req, - int len_of_smb) + unsigned int len_of_smb) { /* +4 is to account for the RFC1001 len field */ struct smb2_neg_context *pctx = (struct smb2_neg_context *)req; int i = 0, len_of_ctxts; - int offset = le32_to_cpu(req->NegotiateContextOffset); - int neg_ctxt_cnt = le16_to_cpu(req->NegotiateContextCount); + unsigned int offset = le32_to_cpu(req->NegotiateContextOffset); + unsigned int neg_ctxt_cnt = le16_to_cpu(req->NegotiateContextCount); __le32 status = STATUS_INVALID_PARAMETER; ksmbd_debug(SMB, "decoding %d negotiate contexts\n", neg_ctxt_cnt); @@ -1002,7 +1002,7 @@ static __le32 deassemble_neg_contexts(struct ksmbd_conn *conn, if (len_of_ctxts == 0) break; - if (len_of_ctxts < sizeof(struct smb2_neg_context)) + if (len_of_ctxts < (int)sizeof(struct smb2_neg_context)) break; pctx = (struct smb2_neg_context *)((char *)pctx + offset); @@ -1053,9 +1053,8 @@ static __le32 deassemble_neg_contexts(struct ksmbd_conn *conn, } /* offsets must be 8 byte aligned */ - clen = (clen + 7) & ~0x7; - offset = clen + sizeof(struct smb2_neg_context); - len_of_ctxts -= clen + sizeof(struct smb2_neg_context); + offset = (clen + sizeof(struct smb2_neg_context + 7) & ~0x7; + len_of_ctxts -= offset; } return status; } -- 2.31.1

2 1

[PATCH OLK-5.10] ksmbd: fix wrong UserName check in session_user
by Li Lingfeng 20 Jul '23

20 Jul '23

From: Chih-Yen Chang <cc85nod(a)gmail.com> mainline inclusion from mainline-v6.4-rc3 commit f0a96d1aafd8964e1f9955c830a3e5cb3c60a90f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7LU3D CVE: CVE-2023-38428 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/f… -------------------------------- The offset of UserName is related to the address of security buffer. To ensure the validaty of UserName, we need to compare name_off + name_len with secbuf_len instead of auth_msg_len. [ 27.096243] ================================================================== [ 27.096890] BUG: KASAN: slab-out-of-bounds in smb_strndup_from_utf16+0x188/0x350 [ 27.097609] Read of size 2 at addr ffff888005e3b542 by task kworker/0:0/7 ... [ 27.099950] Call Trace: [ 27.100194] <TASK> [ 27.100397] dump_stack_lvl+0x33/0x50 [ 27.100752] print_report+0xcc/0x620 [ 27.102305] kasan_report+0xae/0xe0 [ 27.103072] kasan_check_range+0x35/0x1b0 [ 27.103757] smb_strndup_from_utf16+0x188/0x350 [ 27.105474] smb2_sess_setup+0xaf8/0x19c0 [ 27.107935] handle_ksmbd_work+0x274/0x810 [ 27.108315] process_one_work+0x419/0x760 [ 27.108689] worker_thread+0x2a2/0x6f0 [ 27.109385] kthread+0x160/0x190 [ 27.110129] ret_from_fork+0x1f/0x30 [ 27.110454] </TASK> Cc: stable(a)vger.kernel.org Signed-off-by: Chih-Yen Chang <cc85nod(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/ksmbd/smb2pdu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index 18e176fcddf0..c99b8a25f046 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -1383,7 +1383,7 @@ static struct ksmbd_user *session_user(struct ksmbd_conn *conn, struct authenticate_message *authblob; struct ksmbd_user *user; char *name; - unsigned int auth_msg_len, name_off, name_len, secbuf_len; + unsigned int name_off, name_len, secbuf_len; secbuf_len = le16_to_cpu(req->SecurityBufferLength); if (secbuf_len < sizeof(struct authenticate_message)) { @@ -1393,9 +1393,8 @@ static struct ksmbd_user *session_user(struct ksmbd_conn *conn, authblob = user_authblob(conn, req); name_off = le32_to_cpu(authblob->UserName.BufferOffset); name_len = le16_to_cpu(authblob->UserName.Length); - auth_msg_len = le16_to_cpu(req->SecurityBufferOffset) + secbuf_len; - if (auth_msg_len < (u64)name_off + name_len) + if (secbuf_len < (u64)name_off + name_len) return NULL; name = smb_strndup_from_utf16((const char *)authblob + name_off, -- 2.31.1

2 1

[PATCH OLK-5.10] ipv6/addrconf: fix a potential refcount underflow for idev
by Ziyang Xuan 19 Jul '23

19 Jul '23

mainline inclusion from mainline-v6.5-rc2 commit 06a0716949c22e2aefb648526580671197151acc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7M991 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Now in addrconf_mod_rs_timer(), reference idev depends on whether rs_timer is not pending. Then modify rs_timer timeout. There is a time gap in [1], during which if the pending rs_timer becomes not pending. It will miss to hold idev, but the rs_timer is activated. Thus rs_timer callback function addrconf_rs_timer() will be executed and put idev later without holding idev. A refcount underflow issue for idev can be caused by this. if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <--------------[1] mod_timer(&idev->rs_timer, jiffies + when); To fix the issue, hold idev if mod_timer() return 0. Fixes: b7b1bfce0bb6 ("ipv6: split duplicate address detection and router solicitation timer") Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/ipv6/addrconf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 31a0b28e4167..a2bdefcd2b30 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -314,9 +314,8 @@ static void addrconf_del_dad_work(struct inet6_ifaddr *ifp) static void addrconf_mod_rs_timer(struct inet6_dev *idev, unsigned long when) { - if (!timer_pending(&idev->rs_timer)) + if (!mod_timer(&idev->rs_timer, jiffies + when)) in6_dev_hold(idev); - mod_timer(&idev->rs_timer, jiffies + when); } static void addrconf_mod_dad_work(struct inet6_ifaddr *ifp, -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] ipv6/addrconf: fix a potential refcount underflow for idev
by Ziyang Xuan 19 Jul '23

19 Jul '23

mainline inclusion from mainline-v6.5-rc2 commit 06a0716949c22e2aefb648526580671197151acc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7M991 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Now in addrconf_mod_rs_timer(), reference idev depends on whether rs_timer is not pending. Then modify rs_timer timeout. There is a time gap in [1], during which if the pending rs_timer becomes not pending. It will miss to hold idev, but the rs_timer is activated. Thus rs_timer callback function addrconf_rs_timer() will be executed and put idev later without holding idev. A refcount underflow issue for idev can be caused by this. if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <--------------[1] mod_timer(&idev->rs_timer, jiffies + when); To fix the issue, hold idev if mod_timer() return 0. Fixes: b7b1bfce0bb6 ("ipv6: split duplicate address detection and router solicitation timer") Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/ipv6/addrconf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 9d8b791f63ef..b4f4e751e3a7 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -316,9 +316,8 @@ static void addrconf_del_dad_work(struct inet6_ifaddr *ifp) static void addrconf_mod_rs_timer(struct inet6_dev *idev, unsigned long when) { - if (!timer_pending(&idev->rs_timer)) + if (!mod_timer(&idev->rs_timer, jiffies + when)) in6_dev_hold(idev); - mod_timer(&idev->rs_timer, jiffies + when); } static void addrconf_mod_dad_work(struct inet6_ifaddr *ifp, -- 2.25.1

2 1

[PATCH OLK-5.10 0/4] fix three CVEs by backport mainline patchs
by ZhaoLong Wang 19 Jul '23

19 Jul '23

mainline patch f5c779b7ddbda("ksmbd: fix racy issue from session setup and logoff") It fixes three CVEs: CVE-2023-32250 CVE-2023-32252 CVE-2023-32257 In order to successfully apply the patch, we chose to incorporate the related pre-installed bugfix patch. Colin Ian King (1): ksmbd: Fix spelling mistake "excceed" -> "exceeded" Dawei Li (1): ksmbd: Implements sess->ksmbd_chann_list as xarray Namjae Jeon (2): ksmbd: limit pdu length size according to connection status ksmbd: fix racy issue from session setup and logoff fs/ksmbd/connection.c | 27 +++++++--- fs/ksmbd/connection.h | 39 ++++++++------ fs/ksmbd/mgmt/user_session.c | 62 +++++++++------------ fs/ksmbd/mgmt/user_session.h | 4 +- fs/ksmbd/server.c | 3 +- fs/ksmbd/smb2pdu.c | 101 +++++++++++++++++------------------ fs/ksmbd/smb2pdu.h | 5 +- fs/ksmbd/transport_tcp.c | 2 +- 8 files changed, 123 insertions(+), 120 deletions(-) -- 2.34.3

2 5

[PATCH openEuler-1.0-LTS] netfilter: nf_tables: prevent OOB access in nft_byteorder_eval
by Ziyang Xuan 19 Jul '23

19 Jul '23

From: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com> mainline inclusion from mainline-v6.5-rc2 commit caf3ef7468f7534771b5c44cd8dbd6f7f87c2cbd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ISR1 CVE: CVE-2023-35001 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- When evaluating byteorder expressions with size 2, a union with 32-bit and 16-bit members is used. Since the 16-bit members are aligned to 32-bit, the array accesses will be out-of-bounds. It may lead to a stack-out-of-bounds access like the one below: [ 23.095215] ================================================================== [ 23.095625] BUG: KASAN: stack-out-of-bounds in nft_byteorder_eval+0x13c/0x320 [ 23.096020] Read of size 2 at addr ffffc90000007948 by task ping/115 [ 23.096358] [ 23.096456] CPU: 0 PID: 115 Comm: ping Not tainted 6.4.0+ #413 [ 23.096770] Call Trace: [ 23.096910] <IRQ> [ 23.097030] dump_stack_lvl+0x60/0xc0 [ 23.097218] print_report+0xcf/0x630 [ 23.097388] ? nft_byteorder_eval+0x13c/0x320 [ 23.097577] ? kasan_addr_to_slab+0xd/0xc0 [ 23.097760] ? nft_byteorder_eval+0x13c/0x320 [ 23.097949] kasan_report+0xc9/0x110 [ 23.098106] ? nft_byteorder_eval+0x13c/0x320 [ 23.098298] __asan_load2+0x83/0xd0 [ 23.098453] nft_byteorder_eval+0x13c/0x320 [ 23.098659] nft_do_chain+0x1c8/0xc50 [ 23.098852] ? __pfx_nft_do_chain+0x10/0x10 [ 23.099078] ? __kasan_check_read+0x11/0x20 [ 23.099295] ? __pfx___lock_acquire+0x10/0x10 [ 23.099535] ? __pfx___lock_acquire+0x10/0x10 [ 23.099745] ? __kasan_check_read+0x11/0x20 [ 23.099929] nft_do_chain_ipv4+0xfe/0x140 [ 23.100105] ? __pfx_nft_do_chain_ipv4+0x10/0x10 [ 23.100327] ? lock_release+0x204/0x400 [ 23.100515] ? nf_hook.constprop.0+0x340/0x550 [ 23.100779] nf_hook_slow+0x6c/0x100 [ 23.100977] ? __pfx_nft_do_chain_ipv4+0x10/0x10 [ 23.101223] nf_hook.constprop.0+0x334/0x550 [ 23.101443] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 23.101677] ? __pfx_nf_hook.constprop.0+0x10/0x10 [ 23.101882] ? __pfx_ip_rcv_finish+0x10/0x10 [ 23.102071] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 23.102291] ? rcu_read_lock_held+0x4b/0x70 [ 23.102481] ip_local_deliver+0xbb/0x110 [ 23.102665] ? __pfx_ip_rcv+0x10/0x10 [ 23.102839] ip_rcv+0x199/0x2a0 [ 23.102980] ? __pfx_ip_rcv+0x10/0x10 [ 23.103140] __netif_receive_skb_one_core+0x13e/0x150 [ 23.103362] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 23.103647] ? mark_held_locks+0x48/0xa0 [ 23.103819] ? process_backlog+0x36c/0x380 [ 23.103999] __netif_receive_skb+0x23/0xc0 [ 23.104179] process_backlog+0x91/0x380 [ 23.104350] __napi_poll.constprop.0+0x66/0x360 [ 23.104589] ? net_rx_action+0x1cb/0x610 [ 23.104811] net_rx_action+0x33e/0x610 [ 23.105024] ? _raw_spin_unlock+0x23/0x50 [ 23.105257] ? __pfx_net_rx_action+0x10/0x10 [ 23.105485] ? mark_held_locks+0x48/0xa0 [ 23.105741] __do_softirq+0xfa/0x5ab [ 23.105956] ? __dev_queue_xmit+0x765/0x1c00 [ 23.106193] do_softirq.part.0+0x49/0xc0 [ 23.106423] </IRQ> [ 23.106547] <TASK> [ 23.106670] __local_bh_enable_ip+0xf5/0x120 [ 23.106903] __dev_queue_xmit+0x789/0x1c00 [ 23.107131] ? __pfx___dev_queue_xmit+0x10/0x10 [ 23.107381] ? find_held_lock+0x8e/0xb0 [ 23.107585] ? lock_release+0x204/0x400 [ 23.107798] ? neigh_resolve_output+0x185/0x350 [ 23.108049] ? mark_held_locks+0x48/0xa0 [ 23.108265] ? neigh_resolve_output+0x185/0x350 [ 23.108514] neigh_resolve_output+0x246/0x350 [ 23.108753] ? neigh_resolve_output+0x246/0x350 [ 23.109003] ip_finish_output2+0x3c3/0x10b0 [ 23.109250] ? __pfx_ip_finish_output2+0x10/0x10 [ 23.109510] ? __pfx_nf_hook+0x10/0x10 [ 23.109732] __ip_finish_output+0x217/0x390 [ 23.109978] ip_finish_output+0x2f/0x130 [ 23.110207] ip_output+0xc9/0x170 [ 23.110404] ip_push_pending_frames+0x1a0/0x240 [ 23.110652] raw_sendmsg+0x102e/0x19e0 [ 23.110871] ? __pfx_raw_sendmsg+0x10/0x10 [ 23.111093] ? lock_release+0x204/0x400 [ 23.111304] ? __mod_lruvec_page_state+0x148/0x330 [ 23.111567] ? find_held_lock+0x8e/0xb0 [ 23.111777] ? find_held_lock+0x8e/0xb0 [ 23.111993] ? __rcu_read_unlock+0x7c/0x2f0 [ 23.112225] ? aa_sk_perm+0x18a/0x550 [ 23.112431] ? filemap_map_pages+0x4f1/0x900 [ 23.112665] ? __pfx_aa_sk_perm+0x10/0x10 [ 23.112880] ? find_held_lock+0x8e/0xb0 [ 23.113098] inet_sendmsg+0xa0/0xb0 [ 23.113297] ? inet_sendmsg+0xa0/0xb0 [ 23.113500] ? __pfx_inet_sendmsg+0x10/0x10 [ 23.113727] sock_sendmsg+0xf4/0x100 [ 23.113924] ? move_addr_to_kernel.part.0+0x4f/0xa0 [ 23.114190] __sys_sendto+0x1d4/0x290 [ 23.114391] ? __pfx___sys_sendto+0x10/0x10 [ 23.114621] ? __pfx_mark_lock.part.0+0x10/0x10 [ 23.114869] ? lock_release+0x204/0x400 [ 23.115076] ? find_held_lock+0x8e/0xb0 [ 23.115287] ? rcu_is_watching+0x23/0x60 [ 23.115503] ? __rseq_handle_notify_resume+0x6e2/0x860 [ 23.115778] ? __kasan_check_write+0x14/0x30 [ 23.116008] ? blkcg_maybe_throttle_current+0x8d/0x770 [ 23.116285] ? mark_held_locks+0x28/0xa0 [ 23.116503] ? do_syscall_64+0x37/0x90 [ 23.116713] __x64_sys_sendto+0x7f/0xb0 [ 23.116924] do_syscall_64+0x59/0x90 [ 23.117123] ? irqentry_exit_to_user_mode+0x25/0x30 [ 23.117387] ? irqentry_exit+0x77/0xb0 [ 23.117593] ? exc_page_fault+0x92/0x140 [ 23.117806] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 23.118081] RIP: 0033:0x7f744aee2bba [ 23.118282] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 23.119237] RSP: 002b:00007ffd04a7c9f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 23.119644] RAX: ffffffffffffffda RBX: 00007ffd04a7e0a0 RCX: 00007f744aee2bba [ 23.120023] RDX: 0000000000000040 RSI: 000056488e9e6300 RDI: 0000000000000003 [ 23.120413] RBP: 000056488e9e6300 R08: 00007ffd04a80320 R09: 0000000000000010 [ 23.120809] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040 [ 23.121219] R13: 00007ffd04a7dc38 R14: 00007ffd04a7ca00 R15: 00007ffd04a7e0a0 [ 23.121617] </TASK> [ 23.121749] [ 23.121845] The buggy address belongs to the virtual mapping at [ 23.121845] [ffffc90000000000, ffffc90000009000) created by: [ 23.121845] irq_init_percpu_irqstack+0x1cf/0x270 [ 23.122707] [ 23.122803] The buggy address belongs to the physical page: [ 23.123104] page:0000000072ac19f0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24a09 [ 23.123609] flags: 0xfffffc0001000(reserved|node=0|zone=1|lastcpupid=0x1fffff) [ 23.123998] page_type: 0xffffffff() [ 23.124194] raw: 000fffffc0001000 ffffea0000928248 ffffea0000928248 0000000000000000 [ 23.124610] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 23.125023] page dumped because: kasan: bad access detected [ 23.125326] [ 23.125421] Memory state around the buggy address: [ 23.125682] ffffc90000007800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 23.126072] ffffc90000007880: 00 00 00 00 00 f1 f1 f1 f1 f1 f1 00 00 f2 f2 00 [ 23.126455] >ffffc90000007900: 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00 [ 23.126840] ^ [ 23.127138] ffffc90000007980: 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 [ 23.127522] ffffc90000007a00: f3 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 [ 23.127906] ================================================================== [ 23.128324] Disabling lock debugging due to kernel taint Using simple s16 pointers for the 16-bit accesses fixes the problem. For the 32-bit accesses, src and dst can be used directly. Fixes: 96518518cc41 ("netfilter: add nftables") Cc: stable(a)vger.kernel.org Reported-by: Tanguy DUBROCA (@SidewayRE) from @Synacktiv working with ZDI Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com> Reviewed-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/netfilter/nft_byteorder.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/net/netfilter/nft_byteorder.c b/net/netfilter/nft_byteorder.c index 13d4e421a6b3..46a8f894717c 100644 --- a/net/netfilter/nft_byteorder.c +++ b/net/netfilter/nft_byteorder.c @@ -33,11 +33,11 @@ static void nft_byteorder_eval(const struct nft_expr *expr, const struct nft_byteorder *priv = nft_expr_priv(expr); u32 *src = &regs->data[priv->sreg]; u32 *dst = &regs->data[priv->dreg]; - union { u32 u32; u16 u16; } *s, *d; + u16 *s16, *d16; unsigned int i; - s = (void *)src; - d = (void *)dst; + s16 = (void *)src; + d16 = (void *)dst; switch (priv->size) { case 8: { @@ -63,11 +63,11 @@ static void nft_byteorder_eval(const struct nft_expr *expr, switch (priv->op) { case NFT_BYTEORDER_NTOH: for (i = 0; i < priv->len / 4; i++) - d[i].u32 = ntohl((__force __be32)s[i].u32); + dst[i] = ntohl((__force __be32)src[i]); break; case NFT_BYTEORDER_HTON: for (i = 0; i < priv->len / 4; i++) - d[i].u32 = (__force __u32)htonl(s[i].u32); + dst[i] = (__force __u32)htonl(src[i]); break; } break; @@ -75,11 +75,11 @@ static void nft_byteorder_eval(const struct nft_expr *expr, switch (priv->op) { case NFT_BYTEORDER_NTOH: for (i = 0; i < priv->len / 2; i++) - d[i].u16 = ntohs((__force __be16)s[i].u16); + d16[i] = ntohs((__force __be16)s16[i]); break; case NFT_BYTEORDER_HTON: for (i = 0; i < priv->len / 2; i++) - d[i].u16 = (__force __u16)htons(s[i].u16); + d16[i] = (__force __u16)htons(s16[i]); break; } break; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS 0/2] Fix null-ptr-deref while calling getpeername
by Zhong Jinghua 18 Jul '23

18 Jul '23

Fix null-ptr-deref while calling getpeername Mike Christie (1): scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername() Zhong Jinghua (1): scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param() drivers/scsi/iscsi_tcp.c | 72 ++++++++++++++++++++++++++++------------ drivers/scsi/iscsi_tcp.h | 2 ++ 2 files changed, 53 insertions(+), 21 deletions(-) -- 2.31.1

2 4

[PATCH openEuler-23.09] arm64/vmalloc: use module region only for module_alloc() if CONFIG_RANDOMIZE_BASE is set
by Liu Shixin 18 Jul '23

18 Jul '23

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7LXK8 -------------------------------- After I add a 10GB pmem device, I got the following error message when insert module: insmod: vmalloc error: size 16384, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 If CONFIG_RANDOMIZE_BASE is set, the module region can be located in the vmalloc region entirely. Although module_alloc() can fall back to a 2GB window if ARM64_MODULE_PLTS is set, the module region is still easily exhausted because the module region is located at bottom of vmalloc region and the vmalloc region is allocated from bottom to top. Skip module region if not calling from module_alloc(). Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> [cherry-pick from devel-6.1] Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- arch/arm64/include/asm/vmalloc.h | 26 ++++++++++++++++++++++++++ include/linux/vmalloc.h | 9 +++++++++ mm/vmalloc.c | 4 ++++ 3 files changed, 39 insertions(+) diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h index 38fafffe699f..4feff546b11b 100644 --- a/arch/arm64/include/asm/vmalloc.h +++ b/arch/arm64/include/asm/vmalloc.h @@ -31,4 +31,30 @@ static inline pgprot_t arch_vmap_pgprot_tagged(pgprot_t prot) return pgprot_tagged(prot); } +#ifdef CONFIG_RANDOMIZE_BASE +extern u64 module_alloc_base; +#define arch_vmap_skip_module_region arch_vmap_skip_module_region +static inline void arch_vmap_skip_module_region(unsigned long *addr, + unsigned long vstart, + unsigned long size, + unsigned long align) +{ + u64 module_alloc_end = module_alloc_base + MODULES_VSIZE; + + if (vstart == module_alloc_base) + return; + + if (IS_ENABLED(CONFIG_KASAN_GENERIC) || + IS_ENABLED(CONFIG_KASAN_SW_TAGS)) + /* don't exceed the static module region - see module_alloc() */ + module_alloc_end = MODULES_END; + + if ((module_alloc_base >= *addr + size) || + (module_alloc_end <= *addr)) + return; + + *addr = ALIGN(module_alloc_end, align); +} +#endif + #endif /* _ASM_ARM64_VMALLOC_H */ diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index c720be70c8dd..a7b6c2183d55 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -124,6 +124,15 @@ static inline pgprot_t arch_vmap_pgprot_tagged(pgprot_t prot) } #endif +#ifndef arch_vmap_skip_module_region +static inline void arch_vmap_skip_module_region(unsigned long *addr, + unsigned long vstart, + unsigned long size, + unsigned long align) +{ +} +#endif + /* * Highlevel APIs for driver use */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 1d13d71687d7..afab3c7295b4 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1230,6 +1230,8 @@ is_within_this_va(struct vmap_area *va, unsigned long size, else nva_start_addr = ALIGN(vstart, align); + arch_vmap_skip_module_region(&nva_start_addr, vstart, size, align); + /* Can be overflowed due to big size or alignment. */ if (nva_start_addr + size < nva_start_addr || nva_start_addr < vstart) @@ -1517,6 +1519,8 @@ __alloc_vmap_area(struct rb_root *root, struct list_head *head, else nva_start_addr = ALIGN(vstart, align); + arch_vmap_skip_module_region(&nva_start_addr, vstart, size, align); + /* Check the "vend" restriction. */ if (nva_start_addr + size > vend) return vend; -- 2.25.1

2 1

[PATCH openEuler-23.09 0/1] Fix module region exhausted
by Liu Shixin 18 Jul '23

18 Jul '23

Liu Shixin (1): arm64/vmalloc: use module region only for module_alloc() if CONFIG_RANDOMIZE_BASE is set arch/arm64/include/asm/vmalloc.h | 26 ++++++++++++++++++++++++++ include/linux/vmalloc.h | 9 +++++++++ mm/vmalloc.c | 4 ++++ 3 files changed, 39 insertions(+) -- 2.25.1

2 2

[PATCH OLK-5.10 1/6] workqueue: Rename "delayed" (delayed by active management) to "inactive"
by Zeng Heng 18 Jul '23

18 Jul '23

From: Lai Jiangshan <laijs(a)linux.alibaba.com> mainline inclusion from mainline-v5.15-rc1 commit f97a4a1a3f8769e3452885967955e21c88f3f263 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7LRJF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- There are two kinds of "delayed" work items in workqueue subsystem. One is for timer-delayed work items which are visible to workqueue users. The other kind is for work items delayed by active management which can not be directly visible to workqueue users. We mixed the word "delayed" for both kinds and caused somewhat ambiguity. This patch renames the later one (delayed by active management) to "inactive", because it is used for workqueue active management and most of its related symbols are named with "active" or "activate". All "delayed" and "DELAYED" are carefully checked and renamed one by one to avoid accidentally changing the name of the other kind for timer-delayed. No functional change intended. Signed-off-by: Lai Jiangshan <laijs(a)linux.alibaba.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- include/linux/workqueue.h | 4 +-- kernel/workqueue.c | 58 +++++++++++++++++++-------------------- 2 files changed, 31 insertions(+), 31 deletions(-) diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h index 4ecfecb1202f..8067a36c9fa7 100644 --- a/include/linux/workqueue.h +++ b/include/linux/workqueue.h @@ -30,7 +30,7 @@ void delayed_work_timer_fn(struct timer_list *t); enum { WORK_STRUCT_PENDING_BIT = 0, /* work item is pending execution */ - WORK_STRUCT_DELAYED_BIT = 1, /* work item is delayed */ + WORK_STRUCT_INACTIVE_BIT= 1, /* work item is inactive */ WORK_STRUCT_PWQ_BIT = 2, /* data points to pwq */ WORK_STRUCT_LINKED_BIT = 3, /* next work is linked to this one */ #ifdef CONFIG_DEBUG_OBJECTS_WORK @@ -43,7 +43,7 @@ enum { WORK_STRUCT_COLOR_BITS = 4, WORK_STRUCT_PENDING = 1 << WORK_STRUCT_PENDING_BIT, - WORK_STRUCT_DELAYED = 1 << WORK_STRUCT_DELAYED_BIT, + WORK_STRUCT_INACTIVE = 1 << WORK_STRUCT_INACTIVE_BIT, WORK_STRUCT_PWQ = 1 << WORK_STRUCT_PWQ_BIT, WORK_STRUCT_LINKED = 1 << WORK_STRUCT_LINKED_BIT, #ifdef CONFIG_DEBUG_OBJECTS_WORK diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 9db32d9739f5..670bd33d8980 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -208,7 +208,7 @@ struct pool_workqueue { /* L: nr of in_flight works */ int nr_active; /* L: nr of active works */ int max_active; /* L: max active works */ - struct list_head delayed_works; /* L: delayed works */ + struct list_head inactive_works; /* L: inactive works */ struct list_head pwqs_node; /* WR: node on wq->pwqs */ struct list_head mayday_node; /* MD: node on wq->maydays */ @@ -1146,7 +1146,7 @@ static void put_pwq_unlocked(struct pool_workqueue *pwq) } } -static void pwq_activate_delayed_work(struct work_struct *work) +static void pwq_activate_inactive_work(struct work_struct *work) { struct pool_workqueue *pwq = get_work_pwq(work); @@ -1154,16 +1154,16 @@ static void pwq_activate_delayed_work(struct work_struct *work) if (list_empty(&pwq->pool->worklist)) pwq->pool->watchdog_ts = jiffies; move_linked_works(work, &pwq->pool->worklist, NULL); - __clear_bit(WORK_STRUCT_DELAYED_BIT, work_data_bits(work)); + __clear_bit(WORK_STRUCT_INACTIVE_BIT, work_data_bits(work)); pwq->nr_active++; } -static void pwq_activate_first_delayed(struct pool_workqueue *pwq) +static void pwq_activate_first_inactive(struct pool_workqueue *pwq) { - struct work_struct *work = list_first_entry(&pwq->delayed_works, + struct work_struct *work = list_first_entry(&pwq->inactive_works, struct work_struct, entry); - pwq_activate_delayed_work(work); + pwq_activate_inactive_work(work); } /** @@ -1186,10 +1186,10 @@ static void pwq_dec_nr_in_flight(struct pool_workqueue *pwq, int color) pwq->nr_in_flight[color]--; pwq->nr_active--; - if (!list_empty(&pwq->delayed_works)) { - /* one down, submit a delayed one */ + if (!list_empty(&pwq->inactive_works)) { + /* one down, submit an inactive one */ if (pwq->nr_active < pwq->max_active) - pwq_activate_first_delayed(pwq); + pwq_activate_first_inactive(pwq); } /* is flush in progress and are we at the flushing tip? */ @@ -1291,14 +1291,14 @@ static int try_to_grab_pending(struct work_struct *work, bool is_dwork, debug_work_deactivate(work); /* - * A delayed work item cannot be grabbed directly because + * An inactive work item cannot be grabbed directly because * it might have linked NO_COLOR work items which, if left - * on the delayed_list, will confuse pwq->nr_active + * on the inactive_works list, will confuse pwq->nr_active * management later on and cause stall. Make sure the work * item is activated before grabbing. */ - if (*work_data_bits(work) & WORK_STRUCT_DELAYED) - pwq_activate_delayed_work(work); + if (*work_data_bits(work) & WORK_STRUCT_INACTIVE) + pwq_activate_inactive_work(work); list_del_init(&work->entry); pwq_dec_nr_in_flight(pwq, get_work_color(work)); @@ -1497,8 +1497,8 @@ static void __queue_work(int cpu, struct workqueue_struct *wq, if (list_empty(worklist)) pwq->pool->watchdog_ts = jiffies; } else { - work_flags |= WORK_STRUCT_DELAYED; - worklist = &pwq->delayed_works; + work_flags |= WORK_STRUCT_INACTIVE; + worklist = &pwq->inactive_works; } debug_work_activate(work); @@ -2535,7 +2535,7 @@ static int rescuer_thread(void *__rescuer) /* * The above execution of rescued work items could * have created more to rescue through - * pwq_activate_first_delayed() or chained + * pwq_activate_first_inactive() or chained * queueing. Let's put @pwq back on mayday list so * that such back-to-back work items, which may be * being used to relieve memory pressure, don't @@ -2961,7 +2961,7 @@ void drain_workqueue(struct workqueue_struct *wq) bool drained; raw_spin_lock_irq(&pwq->pool->lock); - drained = !pwq->nr_active && list_empty(&pwq->delayed_works); + drained = !pwq->nr_active && list_empty(&pwq->inactive_works); raw_spin_unlock_irq(&pwq->pool->lock); if (drained) @@ -3717,7 +3717,7 @@ static void pwq_unbound_release_workfn(struct work_struct *work) * @pwq: target pool_workqueue * * If @pwq isn't freezing, set @pwq->max_active to the associated - * workqueue's saved_max_active and activate delayed work items + * workqueue's saved_max_active and activate inactive work items * accordingly. If @pwq is freezing, clear @pwq->max_active to zero. */ static void pwq_adjust_max_active(struct pool_workqueue *pwq) @@ -3746,9 +3746,9 @@ static void pwq_adjust_max_active(struct pool_workqueue *pwq) pwq->max_active = wq->saved_max_active; - while (!list_empty(&pwq->delayed_works) && + while (!list_empty(&pwq->inactive_works) && pwq->nr_active < pwq->max_active) { - pwq_activate_first_delayed(pwq); + pwq_activate_first_inactive(pwq); kick = true; } @@ -3779,7 +3779,7 @@ static void init_pwq(struct pool_workqueue *pwq, struct workqueue_struct *wq, pwq->wq = wq; pwq->flush_color = -1; pwq->refcnt = 1; - INIT_LIST_HEAD(&pwq->delayed_works); + INIT_LIST_HEAD(&pwq->inactive_works); INIT_LIST_HEAD(&pwq->pwqs_node); INIT_LIST_HEAD(&pwq->mayday_node); INIT_WORK(&pwq->unbound_release_work, pwq_unbound_release_workfn); @@ -4372,7 +4372,7 @@ static bool pwq_busy(struct pool_workqueue *pwq) if ((pwq != pwq->wq->dfl_pwq) && (pwq->refcnt > 1)) return true; - if (pwq->nr_active || !list_empty(&pwq->delayed_works)) + if (pwq->nr_active || !list_empty(&pwq->inactive_works)) return true; return false; @@ -4568,7 +4568,7 @@ bool workqueue_congested(int cpu, struct workqueue_struct *wq) else pwq = unbound_pwq_by_node(wq, cpu_to_node(cpu)); - ret = !list_empty(&pwq->delayed_works); + ret = !list_empty(&pwq->inactive_works); preempt_enable(); rcu_read_unlock(); @@ -4764,11 +4764,11 @@ static void show_pwq(struct pool_workqueue *pwq) pr_cont("\n"); } - if (!list_empty(&pwq->delayed_works)) { + if (!list_empty(&pwq->inactive_works)) { bool comma = false; - pr_info(" delayed:"); - list_for_each_entry(work, &pwq->delayed_works, entry) { + pr_info(" inactive:"); + list_for_each_entry(work, &pwq->inactive_works, entry) { pr_cont_work(comma, work); comma = !(*work_data_bits(work) & WORK_STRUCT_LINKED); } @@ -4798,7 +4798,7 @@ void show_workqueue_state(void) bool idle = true; for_each_pwq(pwq, wq) { - if (pwq->nr_active || !list_empty(&pwq->delayed_works)) { + if (pwq->nr_active || !list_empty(&pwq->inactive_works)) { idle = false; break; } @@ -4810,7 +4810,7 @@ void show_workqueue_state(void) for_each_pwq(pwq, wq) { raw_spin_lock_irqsave(&pwq->pool->lock, flags); - if (pwq->nr_active || !list_empty(&pwq->delayed_works)) { + if (pwq->nr_active || !list_empty(&pwq->inactive_works)) { /* * Defer printing to avoid deadlocks in console * drivers that queue work while holding locks @@ -5206,7 +5206,7 @@ EXPORT_SYMBOL_GPL(work_on_cpu_safe); * freeze_workqueues_begin - begin freezing workqueues * * Start freezing workqueues. After this function returns, all freezable - * workqueues will queue new works to their delayed_works list instead of + * workqueues will queue new works to their inactive_works list instead of * pool->worklist. * * CONTEXT: -- 2.25.1

2 6

[PATCH OLK-5.10 1/4] netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE
by Jialin Zhang 18 Jul '23

18 Jul '23

From: Pablo Neira Ayuso <pablo(a)netfilter.org> mainline inclusion from mainline-v6.4-rc7 commit 1240eb93f0616b21c675416516ff3d74798fdc97 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N CVE: CVE-2023-3117 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In case of error when adding a new rule that refers to an anonymous set, deactivate expressions via NFT_TRANS_PREPARE state, not NFT_TRANS_RELEASE. Thus, the lookup expression marks anonymous sets as inactive in the next generation to ensure it is not reachable in this transaction anymore and decrement the set refcount as introduced by c1592a89942e ("netfilter: nf_tables: deactivate anonymous set from preparation phase"). The abort step takes care of undoing the anonymous set. This is also consistent with rule deletion, where NFT_TRANS_PREPARE is used. Note that this error path is exercised in the preparation step of the commit protocol. This patch replaces nf_tables_rule_release() by the deactivate and destroy calls, this time with NFT_TRANS_PREPARE. Due to this incorrect error handling, it is possible to access a dangling pointer to the anonymous set that remains in the transaction list. [1009.379054] BUG: KASAN: use-after-free in nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379106] Read of size 8 at addr ffff88816c4c8020 by task nft-rule-add/137110 [1009.379116] CPU: 7 PID: 137110 Comm: nft-rule-add Not tainted 6.4.0-rc4+ #256 [1009.379128] Call Trace: [1009.379132] <TASK> [1009.379135] dump_stack_lvl+0x33/0x50 [1009.379146] ? nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379191] print_address_description.constprop.0+0x27/0x300 [1009.379201] kasan_report+0x107/0x120 [1009.379210] ? nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379255] nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379302] nft_lookup_init+0xa5/0x270 [nf_tables] [1009.379350] nf_tables_newrule+0x698/0xe50 [nf_tables] [1009.379397] ? nf_tables_rule_release+0xe0/0xe0 [nf_tables] [1009.379441] ? kasan_unpoison+0x23/0x50 [1009.379450] nfnetlink_rcv_batch+0x97c/0xd90 [nfnetlink] [1009.379470] ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink] [1009.379485] ? __alloc_skb+0xb8/0x1e0 [1009.379493] ? __alloc_skb+0xb8/0x1e0 [1009.379502] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0 [1009.379509] ? unwind_get_return_address+0x2a/0x40 [1009.379517] ? write_profile+0xc0/0xc0 [1009.379524] ? avc_lookup+0x8f/0xc0 [1009.379532] ? __rcu_read_unlock+0x43/0x60 Fixes: 958bee14d071 ("netfilter: nf_tables: use new transaction infrastructure to handle sets") Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> conflict: net/netfilter/nf_tables_api.c Signed-off-by: Lu Wei <luwei32(a)huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- net/netfilter/nf_tables_api.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index 62049daf1351..f3c4e75dc0aa 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -3366,7 +3366,8 @@ static int nf_tables_newrule(struct net *net, struct sock *nlsk, return 0; err2: - nf_tables_rule_release(&ctx, rule); + nft_rule_expr_deactivate(&ctx, rule, NFT_TRANS_PREPARE); + nf_tables_rule_destroy(&ctx, rule); err1: for (i = 0; i < n; i++) { if (info[i].ops) { -- 2.25.1

2 4

[PATCH OLK-5.10] media: dvb-core: Fix use-after-free due on race condition at dvb_net
by Cai Xinchen 18 Jul '23

18 Jul '23

From: Hyunwoo Kim <imv4bel(a)gmail.com> mainline inclusion from mainline-v6.4-rc3 commit 4172385b0c9ac366dcab78eda48c26814b87ed1a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I635JD CVE: CVE-2022-45886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… ---------------------------------------- A race condition may occur between the .disconnect function, which is called when the device is disconnected, and the dvb_device_open() function, which is called when the device node is open()ed. This results in several types of UAFs. The root cause of this is that you use the dvb_device_open() function, which does not implement a conditional statement that checks 'dvbnet->exit'. So, add 'remove_mutex` to protect 'dvbnet->exit' and use locked_dvb_net_open() function to check 'dvbnet->exit'. [mchehab: fix a checkpatch warning] Link: https://lore.kernel.org/linux-media/20221117045925.14297-3-imv4bel@gmail.com Signed-off-by: Hyunwoo Kim <imv4bel(a)gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- drivers/media/dvb-core/dvb_net.c | 38 +++++++++++++++++++++++++++++--- include/media/dvb_net.h | 4 ++++ 2 files changed, 39 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c index 10f78109bb3f..d8bdca2bf566 100644 --- a/drivers/media/dvb-core/dvb_net.c +++ b/drivers/media/dvb-core/dvb_net.c @@ -1562,15 +1562,43 @@ static long dvb_net_ioctl(struct file *file, return dvb_usercopy(file, cmd, arg, dvb_net_do_ioctl); } +static int locked_dvb_net_open(struct inode *inode, struct file *file) +{ + struct dvb_device *dvbdev = file->private_data; + struct dvb_net *dvbnet = dvbdev->priv; + int ret; + + if (mutex_lock_interruptible(&dvbnet->remove_mutex)) + return -ERESTARTSYS; + + if (dvbnet->exit) { + mutex_unlock(&dvbnet->remove_mutex); + return -ENODEV; + } + + ret = dvb_generic_open(inode, file); + + mutex_unlock(&dvbnet->remove_mutex); + + return ret; +} + static int dvb_net_close(struct inode *inode, struct file *file) { struct dvb_device *dvbdev = file->private_data; struct dvb_net *dvbnet = dvbdev->priv; + mutex_lock(&dvbnet->remove_mutex); + dvb_generic_release(inode, file); - if(dvbdev->users == 1 && dvbnet->exit == 1) + if (dvbdev->users == 1 && dvbnet->exit == 1) { + mutex_unlock(&dvbnet->remove_mutex); wake_up(&dvbdev->wait_queue); + } else { + mutex_unlock(&dvbnet->remove_mutex); + } + return 0; } @@ -1578,7 +1606,7 @@ static int dvb_net_close(struct inode *inode, struct file *file) static const struct file_operations dvb_net_fops = { .owner = THIS_MODULE, .unlocked_ioctl = dvb_net_ioctl, - .open = dvb_generic_open, + .open = locked_dvb_net_open, .release = dvb_net_close, .llseek = noop_llseek, }; @@ -1597,10 +1625,13 @@ void dvb_net_release (struct dvb_net *dvbnet) { int i; + mutex_lock(&dvbnet->remove_mutex); dvbnet->exit = 1; + mutex_unlock(&dvbnet->remove_mutex); + if (dvbnet->dvbdev->users < 1) wait_event(dvbnet->dvbdev->wait_queue, - dvbnet->dvbdev->users==1); + dvbnet->dvbdev->users == 1); dvb_unregister_device(dvbnet->dvbdev); @@ -1619,6 +1650,7 @@ int dvb_net_init (struct dvb_adapter *adap, struct dvb_net *dvbnet, int i; mutex_init(&dvbnet->ioctl_mutex); + mutex_init(&dvbnet->remove_mutex); dvbnet->demux = dmx; for (i=0; i<DVB_NET_DEVICES_MAX; i++) diff --git a/include/media/dvb_net.h b/include/media/dvb_net.h index 5e31d37f25fa..cc01dffcc9f3 100644 --- a/include/media/dvb_net.h +++ b/include/media/dvb_net.h @@ -41,6 +41,9 @@ * @exit: flag to indicate when the device is being removed. * @demux: pointer to &struct dmx_demux. * @ioctl_mutex: protect access to this struct. + * @remove_mutex: mutex that avoids a race condition between a callback + * called when the hardware is disconnected and the + * file_operations of dvb_net. * * Currently, the core supports up to %DVB_NET_DEVICES_MAX (10) network * devices. @@ -53,6 +56,7 @@ struct dvb_net { unsigned int exit:1; struct dmx_demux *demux; struct mutex ioctl_mutex; + struct mutex remove_mutex; }; /** -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS 0/2] Tracing fixes
by Zheng Yejian 18 Jul '23

18 Jul '23

Tracing fixes: - Fix a deadloop in reading trace_pipe that was caused by a mismatch between ring_buffer_empty() returning false which then asked to read the data, but the read code uses rb_num_of_entries() that returned zero, and causing an infinite "retry". - Fix a warning caused by not using all pages allocated to store ftrace functions, where this can happen if the linker inserts a bunch of "NULL" entries, causing the accounting of how many pages needed to be off. Zheng Yejian (2): ring-buffer: Fix deadloop issue on reading trace_pipe ftrace: Fix possible warning on checking all pages used in ftrace_process_locs() kernel/trace/ftrace.c | 41 +++++++++++++++++++++++++++----------- kernel/trace/ring_buffer.c | 24 +++++++++++++--------- 2 files changed, 44 insertions(+), 21 deletions(-) -- 2.25.1

2 3

[PATCH OLK-5.10] media: dvb-core: Fix use-after-free due on race condition at dvb_net
by Cai Xinchen 18 Jul '23

18 Jul '23

From: Hyunwoo Kim <imv4bel(a)gmail.com> mainline inclusion from mainline-v6.4-rc3 commit 4172385b0c9ac366dcab78eda48c26814b87ed1a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I635JD CVE: CVE-2022-45886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… ---------------------------------------- A race condition may occur between the .disconnect function, which is called when the device is disconnected, and the dvb_device_open() function, which is called when the device node is open()ed. This results in several types of UAFs. The root cause of this is that you use the dvb_device_open() function, which does not implement a conditional statement that checks 'dvbnet->exit'. So, add 'remove_mutex` to protect 'dvbnet->exit' and use locked_dvb_net_open() function to check 'dvbnet->exit'. [mchehab: fix a checkpatch warning] Link: https://lore.kernel.org/linux-media/20221117045925.14297-3-imv4bel@gmail.com Signed-off-by: Hyunwoo Kim <imv4bel(a)gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- drivers/media/dvb-core/dvb_net.c | 38 +++++++++++++++++++++++++++++--- include/media/dvb_net.h | 4 ++++ 2 files changed, 39 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb-core/dvb_net.c b/drivers/media/dvb-core/dvb_net.c index 10f78109bb3f..d8bdca2bf566 100644 --- a/drivers/media/dvb-core/dvb_net.c +++ b/drivers/media/dvb-core/dvb_net.c @@ -1562,15 +1562,43 @@ static long dvb_net_ioctl(struct file *file, return dvb_usercopy(file, cmd, arg, dvb_net_do_ioctl); } +static int locked_dvb_net_open(struct inode *inode, struct file *file) +{ + struct dvb_device *dvbdev = file->private_data; + struct dvb_net *dvbnet = dvbdev->priv; + int ret; + + if (mutex_lock_interruptible(&dvbnet->remove_mutex)) + return -ERESTARTSYS; + + if (dvbnet->exit) { + mutex_unlock(&dvbnet->remove_mutex); + return -ENODEV; + } + + ret = dvb_generic_open(inode, file); + + mutex_unlock(&dvbnet->remove_mutex); + + return ret; +} + static int dvb_net_close(struct inode *inode, struct file *file) { struct dvb_device *dvbdev = file->private_data; struct dvb_net *dvbnet = dvbdev->priv; + mutex_lock(&dvbnet->remove_mutex); + dvb_generic_release(inode, file); - if(dvbdev->users == 1 && dvbnet->exit == 1) + if (dvbdev->users == 1 && dvbnet->exit == 1) { + mutex_unlock(&dvbnet->remove_mutex); wake_up(&dvbdev->wait_queue); + } else { + mutex_unlock(&dvbnet->remove_mutex); + } + return 0; } @@ -1578,7 +1606,7 @@ static int dvb_net_close(struct inode *inode, struct file *file) static const struct file_operations dvb_net_fops = { .owner = THIS_MODULE, .unlocked_ioctl = dvb_net_ioctl, - .open = dvb_generic_open, + .open = locked_dvb_net_open, .release = dvb_net_close, .llseek = noop_llseek, }; @@ -1597,10 +1625,13 @@ void dvb_net_release (struct dvb_net *dvbnet) { int i; + mutex_lock(&dvbnet->remove_mutex); dvbnet->exit = 1; + mutex_unlock(&dvbnet->remove_mutex); + if (dvbnet->dvbdev->users < 1) wait_event(dvbnet->dvbdev->wait_queue, - dvbnet->dvbdev->users==1); + dvbnet->dvbdev->users == 1); dvb_unregister_device(dvbnet->dvbdev); @@ -1619,6 +1650,7 @@ int dvb_net_init (struct dvb_adapter *adap, struct dvb_net *dvbnet, int i; mutex_init(&dvbnet->ioctl_mutex); + mutex_init(&dvbnet->remove_mutex); dvbnet->demux = dmx; for (i=0; i<DVB_NET_DEVICES_MAX; i++) diff --git a/include/media/dvb_net.h b/include/media/dvb_net.h index 5e31d37f25fa..cc01dffcc9f3 100644 --- a/include/media/dvb_net.h +++ b/include/media/dvb_net.h @@ -41,6 +41,9 @@ * @exit: flag to indicate when the device is being removed. * @demux: pointer to &struct dmx_demux. * @ioctl_mutex: protect access to this struct. + * @remove_mutex: mutex that avoids a race condition between a callback + * called when the hardware is disconnected and the + * file_operations of dvb_net. * * Currently, the core supports up to %DVB_NET_DEVICES_MAX (10) network * devices. @@ -53,6 +56,7 @@ struct dvb_net { unsigned int exit:1; struct dmx_demux *demux; struct mutex ioctl_mutex; + struct mutex remove_mutex; }; /** -- 2.17.1

2 1

[PATCH openEuler-23.09] arm64/vmalloc: use module region only for module_alloc() if CONFIG_RANDOMIZE_BASE is set
by Liu Shixin 18 Jul '23

18 Jul '23

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6DAD6 -------------------------------- After I add a 10GB pmem device, I got the following error message when insert module: insmod: vmalloc error: size 16384, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 If CONFIG_RANDOMIZE_BASE is set, the module region can be located in the vmalloc region entirely. Although module_alloc() can fall back to a 2GB window if ARM64_MODULE_PLTS is set, the module region is still easily exhausted because the module region is located at bottom of vmalloc region and the vmalloc region is allocated from bottom to top. Skip module region if not calling from module_alloc(). Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> [cherry-pick from devel-6.1] Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- arch/arm64/include/asm/vmalloc.h | 26 ++++++++++++++++++++++++++ include/linux/vmalloc.h | 9 +++++++++ mm/vmalloc.c | 4 ++++ 3 files changed, 39 insertions(+) diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h index 38fafffe699f..4feff546b11b 100644 --- a/arch/arm64/include/asm/vmalloc.h +++ b/arch/arm64/include/asm/vmalloc.h @@ -31,4 +31,30 @@ static inline pgprot_t arch_vmap_pgprot_tagged(pgprot_t prot) return pgprot_tagged(prot); } +#ifdef CONFIG_RANDOMIZE_BASE +extern u64 module_alloc_base; +#define arch_vmap_skip_module_region arch_vmap_skip_module_region +static inline void arch_vmap_skip_module_region(unsigned long *addr, + unsigned long vstart, + unsigned long size, + unsigned long align) +{ + u64 module_alloc_end = module_alloc_base + MODULES_VSIZE; + + if (vstart == module_alloc_base) + return; + + if (IS_ENABLED(CONFIG_KASAN_GENERIC) || + IS_ENABLED(CONFIG_KASAN_SW_TAGS)) + /* don't exceed the static module region - see module_alloc() */ + module_alloc_end = MODULES_END; + + if ((module_alloc_base >= *addr + size) || + (module_alloc_end <= *addr)) + return; + + *addr = ALIGN(module_alloc_end, align); +} +#endif + #endif /* _ASM_ARM64_VMALLOC_H */ diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index c720be70c8dd..a7b6c2183d55 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -124,6 +124,15 @@ static inline pgprot_t arch_vmap_pgprot_tagged(pgprot_t prot) } #endif +#ifndef arch_vmap_skip_module_region +static inline void arch_vmap_skip_module_region(unsigned long *addr, + unsigned long vstart, + unsigned long size, + unsigned long align) +{ +} +#endif + /* * Highlevel APIs for driver use */ diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 1d13d71687d7..afab3c7295b4 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1230,6 +1230,8 @@ is_within_this_va(struct vmap_area *va, unsigned long size, else nva_start_addr = ALIGN(vstart, align); + arch_vmap_skip_module_region(&nva_start_addr, vstart, size, align); + /* Can be overflowed due to big size or alignment. */ if (nva_start_addr + size < nva_start_addr || nva_start_addr < vstart) @@ -1517,6 +1519,8 @@ __alloc_vmap_area(struct rb_root *root, struct list_head *head, else nva_start_addr = ALIGN(vstart, align); + arch_vmap_skip_module_region(&nva_start_addr, vstart, size, align); + /* Check the "vend" restriction. */ if (nva_start_addr + size > vend) return vend; -- 2.25.1

2 1

[PATCH OLK-5.10 0/4] Tracing fixes
by Zheng Yejian 18 Jul '23

18 Jul '23

Tracing fixes: - Fix a deadloop in reading trace_pipe that was caused by a mismatch between ring_buffer_empty() returning false which then asked to read the data, but the read code uses rb_num_of_entries() that returned zero, and causing an infinite "retry". - Fix a warning caused by not using all pages allocated to store ftrace functions, where this can happen if the linker inserts a bunch of "NULL" entries, causing the accounting of how many pages needed to be off. - Fix memory leak in freeing iter->temp in tracing_release_pipe(). Linus Torvalds (1): ftrace: Store the order of pages allocated in ftrace_page Zheng Yejian (3): ring-buffer: Fix deadloop issue on reading trace_pipe tracing: Fix memory leak of iter->temp when reading trace_pipe ftrace: Fix possible warning on checking all pages used in ftrace_process_locs() kernel/trace/ftrace.c | 72 +++++++++++++++++++++++--------------- kernel/trace/ring_buffer.c | 24 ++++++++----- kernel/trace/trace.c | 1 + 3 files changed, 60 insertions(+), 37 deletions(-) -- 2.25.1

2 5

[PATCH openEuler-1.0-LTS] KVM: fix overflow of zero page refcount with ksm running
by Lei Chen 18 Jul '23

18 Jul '23

From: Zhuang Yanying <ann.zhuangyanying(a)huawei.com> mainline inclusion from mainline-v5.10 commit 7df003c85218b5f5b10a7f6418208f31e813f38f category: bugfix -------------------------------- We are testing Virtual Machine with KSM on v5.4-rc2 kernel, and found the zero_page refcount overflow. The cause of refcount overflow is increased in try_async_pf (get_user_page) without being decreased in mmu_set_spte() while handling ept violation. In kvm_release_pfn_clean(), only unreserved page will call put_page. However, zero page is reserved. So, as well as creating and destroy vm, the refcount of zero page will continue to increase until it overflows. step1: echo 10000 > /sys/kernel/pages_to_scan/pages_to_scan echo 1 > /sys/kernel/pages_to_scan/run echo 1 > /sys/kernel/pages_to_scan/use_zero_pages step2: just create several normal qemu kvm vms. And destroy it after 10s. Repeat this action all the time. After a long period of time, all domains hang because of the refcount of zero page overflow. Qemu print error log as follow: â€¦ error: kvm run failed Bad address EAX=00006cdc EBX=00000008 ECX=80202001 EDX=078bfbfd ESI=ffffffff EDI=00000000 EBP=00000008 ESP=00006cc4 EIP=000efd75 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 000f7070 00000037 IDT= 000f70ae 00000000 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=00 01 00 00 00 e9 e8 00 00 00 c7 05 4c 55 0f 00 01 00 00 00 <8b> 35 00 00 01 00 8b 3d 04 00 01 00 b8 d8 d3 00 00 c1 e0 08 0c ea a3 00 00 01 00 c7 05 04 â€¦ Meanwhile, a kernel warning is departed. [40914.836375] WARNING: CPU: 3 PID: 82067 at ./include/linux/mm.h:987 try_get_page+0x1f/0x30 [40914.836412] CPU: 3 PID: 82067 Comm: CPU 0/KVM Kdump: loaded Tainted: G OE 5.2.0-rc2 #5 [40914.836415] RIP: 0010:try_get_page+0x1f/0x30 [40914.836417] Code: 40 00 c3 0f 1f 84 00 00 00 00 00 48 8b 47 08 a8 01 75 11 8b 47 34 85 c0 7e 10 f0 ff 47 34 b8 01 00 00 00 c3 48 8d 78 ff eb e9 <0f> 0b 31 c0 c3 66 90 66 2e 0f 1f 84 00 0 0 00 00 00 48 8b 47 08 a8 [40914.836418] RSP: 0018:ffffb4144e523988 EFLAGS: 00010286 [40914.836419] RAX: 0000000080000000 RBX: 0000000000000326 RCX: 0000000000000000 [40914.836420] RDX: 0000000000000000 RSI: 00004ffdeba10000 RDI: ffffdf07093f6440 [40914.836421] RBP: ffffdf07093f6440 R08: 800000424fd91225 R09: 0000000000000000 [40914.836421] R10: ffff9eb41bfeebb8 R11: 0000000000000000 R12: ffffdf06bbd1e8a8 [40914.836422] R13: 0000000000000080 R14: 800000424fd91225 R15: ffffdf07093f6440 [40914.836423] FS: 00007fb60ffff700(0000) GS:ffff9eb4802c0000(0000) knlGS:0000000000000000 [40914.836425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40914.836426] CR2: 0000000000000000 CR3: 0000002f220e6002 CR4: 00000000003626e0 [40914.836427] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [40914.836427] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [40914.836428] Call Trace: [40914.836433] follow_page_pte+0x302/0x47b [40914.836437] __get_user_pages+0xf1/0x7d0 [40914.836441] ? irq_work_queue+0x9/0x70 [40914.836443] get_user_pages_unlocked+0x13f/0x1e0 [40914.836469] __gfn_to_pfn_memslot+0x10e/0x400 [kvm] [40914.836486] try_async_pf+0x87/0x240 [kvm] [40914.836503] tdp_page_fault+0x139/0x270 [kvm] [40914.836523] kvm_mmu_page_fault+0x76/0x5e0 [kvm] [40914.836588] vcpu_enter_guest+0xb45/0x1570 [kvm] [40914.836632] kvm_arch_vcpu_ioctl_run+0x35d/0x580 [kvm] [40914.836645] kvm_vcpu_ioctl+0x26e/0x5d0 [kvm] [40914.836650] do_vfs_ioctl+0xa9/0x620 [40914.836653] ksys_ioctl+0x60/0x90 [40914.836654] __x64_sys_ioctl+0x16/0x20 [40914.836658] do_syscall_64+0x5b/0x180 [40914.836664] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [40914.836666] RIP: 0033:0x7fb61cb6bfc7 Signed-off-by: LinFeng <linfeng23(a)huawei.com> Signed-off-by: Zhuang Yanying <ann.zhuangyanying(a)huawei.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Lei Chen <lei.chen(a)smartx.com> --- virt/kvm/kvm_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 96fb21ac7224..e4e3dc429ec4 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -170,6 +170,7 @@ bool kvm_is_reserved_pfn(kvm_pfn_t pfn) */ if (pfn_valid(pfn)) return PageReserved(pfn_to_page(pfn)) && + !is_zero_pfn(pfn) && !kvm_is_zone_device_pfn(pfn); return true; -- 2.34.1

2 1

[PATCH OLK-5.10] Fix the default return value of dm_pool_dec_data_range()
by Li Lingfeng 18 Jul '23

18 Jul '23

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7LJO8 CVE: NA -------------------------------- Commit 26d0b2da7317 ("dm thin metadata: check fail_io before using data_sm") change the defalut return value of dm_pool_dec_data_range(), so fix it. Fixes: 26d0b2da7317 ("dm thin metadata: check fail_io before using data_sm") Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/md/dm-thin-metadata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-thin-metadata.c b/drivers/md/dm-thin-metadata.c index 69401bfac76e..551ae1cd3c43 100644 --- a/drivers/md/dm-thin-metadata.c +++ b/drivers/md/dm-thin-metadata.c @@ -1806,7 +1806,7 @@ int dm_pool_inc_data_range(struct dm_pool_metadata *pmd, dm_block_t b, dm_block_ int dm_pool_dec_data_range(struct dm_pool_metadata *pmd, dm_block_t b, dm_block_t e) { - int r = -EINVAL; + int r = 0; pmd_write_lock(pmd); if (!pmd->fail_io) { -- 2.31.1

2 1

[PATCH OLK-5.10] netfilter: nf_tables: prevent OOB access in nft_byteorder_eval
by Ziyang Xuan 18 Jul '23

18 Jul '23

From: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com> mainline inclusion from mainline-v6.5-rc2 commit caf3ef7468f7534771b5c44cd8dbd6f7f87c2cbd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ISR1 CVE: CVE-2023-35001 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- When evaluating byteorder expressions with size 2, a union with 32-bit and 16-bit members is used. Since the 16-bit members are aligned to 32-bit, the array accesses will be out-of-bounds. It may lead to a stack-out-of-bounds access like the one below: [ 23.095215] ================================================================== [ 23.095625] BUG: KASAN: stack-out-of-bounds in nft_byteorder_eval+0x13c/0x320 [ 23.096020] Read of size 2 at addr ffffc90000007948 by task ping/115 [ 23.096358] [ 23.096456] CPU: 0 PID: 115 Comm: ping Not tainted 6.4.0+ #413 [ 23.096770] Call Trace: [ 23.096910] <IRQ> [ 23.097030] dump_stack_lvl+0x60/0xc0 [ 23.097218] print_report+0xcf/0x630 [ 23.097388] ? nft_byteorder_eval+0x13c/0x320 [ 23.097577] ? kasan_addr_to_slab+0xd/0xc0 [ 23.097760] ? nft_byteorder_eval+0x13c/0x320 [ 23.097949] kasan_report+0xc9/0x110 [ 23.098106] ? nft_byteorder_eval+0x13c/0x320 [ 23.098298] __asan_load2+0x83/0xd0 [ 23.098453] nft_byteorder_eval+0x13c/0x320 [ 23.098659] nft_do_chain+0x1c8/0xc50 [ 23.098852] ? __pfx_nft_do_chain+0x10/0x10 [ 23.099078] ? __kasan_check_read+0x11/0x20 [ 23.099295] ? __pfx___lock_acquire+0x10/0x10 [ 23.099535] ? __pfx___lock_acquire+0x10/0x10 [ 23.099745] ? __kasan_check_read+0x11/0x20 [ 23.099929] nft_do_chain_ipv4+0xfe/0x140 [ 23.100105] ? __pfx_nft_do_chain_ipv4+0x10/0x10 [ 23.100327] ? lock_release+0x204/0x400 [ 23.100515] ? nf_hook.constprop.0+0x340/0x550 [ 23.100779] nf_hook_slow+0x6c/0x100 [ 23.100977] ? __pfx_nft_do_chain_ipv4+0x10/0x10 [ 23.101223] nf_hook.constprop.0+0x334/0x550 [ 23.101443] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 23.101677] ? __pfx_nf_hook.constprop.0+0x10/0x10 [ 23.101882] ? __pfx_ip_rcv_finish+0x10/0x10 [ 23.102071] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 23.102291] ? rcu_read_lock_held+0x4b/0x70 [ 23.102481] ip_local_deliver+0xbb/0x110 [ 23.102665] ? __pfx_ip_rcv+0x10/0x10 [ 23.102839] ip_rcv+0x199/0x2a0 [ 23.102980] ? __pfx_ip_rcv+0x10/0x10 [ 23.103140] __netif_receive_skb_one_core+0x13e/0x150 [ 23.103362] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 23.103647] ? mark_held_locks+0x48/0xa0 [ 23.103819] ? process_backlog+0x36c/0x380 [ 23.103999] __netif_receive_skb+0x23/0xc0 [ 23.104179] process_backlog+0x91/0x380 [ 23.104350] __napi_poll.constprop.0+0x66/0x360 [ 23.104589] ? net_rx_action+0x1cb/0x610 [ 23.104811] net_rx_action+0x33e/0x610 [ 23.105024] ? _raw_spin_unlock+0x23/0x50 [ 23.105257] ? __pfx_net_rx_action+0x10/0x10 [ 23.105485] ? mark_held_locks+0x48/0xa0 [ 23.105741] __do_softirq+0xfa/0x5ab [ 23.105956] ? __dev_queue_xmit+0x765/0x1c00 [ 23.106193] do_softirq.part.0+0x49/0xc0 [ 23.106423] </IRQ> [ 23.106547] <TASK> [ 23.106670] __local_bh_enable_ip+0xf5/0x120 [ 23.106903] __dev_queue_xmit+0x789/0x1c00 [ 23.107131] ? __pfx___dev_queue_xmit+0x10/0x10 [ 23.107381] ? find_held_lock+0x8e/0xb0 [ 23.107585] ? lock_release+0x204/0x400 [ 23.107798] ? neigh_resolve_output+0x185/0x350 [ 23.108049] ? mark_held_locks+0x48/0xa0 [ 23.108265] ? neigh_resolve_output+0x185/0x350 [ 23.108514] neigh_resolve_output+0x246/0x350 [ 23.108753] ? neigh_resolve_output+0x246/0x350 [ 23.109003] ip_finish_output2+0x3c3/0x10b0 [ 23.109250] ? __pfx_ip_finish_output2+0x10/0x10 [ 23.109510] ? __pfx_nf_hook+0x10/0x10 [ 23.109732] __ip_finish_output+0x217/0x390 [ 23.109978] ip_finish_output+0x2f/0x130 [ 23.110207] ip_output+0xc9/0x170 [ 23.110404] ip_push_pending_frames+0x1a0/0x240 [ 23.110652] raw_sendmsg+0x102e/0x19e0 [ 23.110871] ? __pfx_raw_sendmsg+0x10/0x10 [ 23.111093] ? lock_release+0x204/0x400 [ 23.111304] ? __mod_lruvec_page_state+0x148/0x330 [ 23.111567] ? find_held_lock+0x8e/0xb0 [ 23.111777] ? find_held_lock+0x8e/0xb0 [ 23.111993] ? __rcu_read_unlock+0x7c/0x2f0 [ 23.112225] ? aa_sk_perm+0x18a/0x550 [ 23.112431] ? filemap_map_pages+0x4f1/0x900 [ 23.112665] ? __pfx_aa_sk_perm+0x10/0x10 [ 23.112880] ? find_held_lock+0x8e/0xb0 [ 23.113098] inet_sendmsg+0xa0/0xb0 [ 23.113297] ? inet_sendmsg+0xa0/0xb0 [ 23.113500] ? __pfx_inet_sendmsg+0x10/0x10 [ 23.113727] sock_sendmsg+0xf4/0x100 [ 23.113924] ? move_addr_to_kernel.part.0+0x4f/0xa0 [ 23.114190] __sys_sendto+0x1d4/0x290 [ 23.114391] ? __pfx___sys_sendto+0x10/0x10 [ 23.114621] ? __pfx_mark_lock.part.0+0x10/0x10 [ 23.114869] ? lock_release+0x204/0x400 [ 23.115076] ? find_held_lock+0x8e/0xb0 [ 23.115287] ? rcu_is_watching+0x23/0x60 [ 23.115503] ? __rseq_handle_notify_resume+0x6e2/0x860 [ 23.115778] ? __kasan_check_write+0x14/0x30 [ 23.116008] ? blkcg_maybe_throttle_current+0x8d/0x770 [ 23.116285] ? mark_held_locks+0x28/0xa0 [ 23.116503] ? do_syscall_64+0x37/0x90 [ 23.116713] __x64_sys_sendto+0x7f/0xb0 [ 23.116924] do_syscall_64+0x59/0x90 [ 23.117123] ? irqentry_exit_to_user_mode+0x25/0x30 [ 23.117387] ? irqentry_exit+0x77/0xb0 [ 23.117593] ? exc_page_fault+0x92/0x140 [ 23.117806] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 23.118081] RIP: 0033:0x7f744aee2bba [ 23.118282] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 23.119237] RSP: 002b:00007ffd04a7c9f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 23.119644] RAX: ffffffffffffffda RBX: 00007ffd04a7e0a0 RCX: 00007f744aee2bba [ 23.120023] RDX: 0000000000000040 RSI: 000056488e9e6300 RDI: 0000000000000003 [ 23.120413] RBP: 000056488e9e6300 R08: 00007ffd04a80320 R09: 0000000000000010 [ 23.120809] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040 [ 23.121219] R13: 00007ffd04a7dc38 R14: 00007ffd04a7ca00 R15: 00007ffd04a7e0a0 [ 23.121617] </TASK> [ 23.121749] [ 23.121845] The buggy address belongs to the virtual mapping at [ 23.121845] [ffffc90000000000, ffffc90000009000) created by: [ 23.121845] irq_init_percpu_irqstack+0x1cf/0x270 [ 23.122707] [ 23.122803] The buggy address belongs to the physical page: [ 23.123104] page:0000000072ac19f0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24a09 [ 23.123609] flags: 0xfffffc0001000(reserved|node=0|zone=1|lastcpupid=0x1fffff) [ 23.123998] page_type: 0xffffffff() [ 23.124194] raw: 000fffffc0001000 ffffea0000928248 ffffea0000928248 0000000000000000 [ 23.124610] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 23.125023] page dumped because: kasan: bad access detected [ 23.125326] [ 23.125421] Memory state around the buggy address: [ 23.125682] ffffc90000007800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 23.126072] ffffc90000007880: 00 00 00 00 00 f1 f1 f1 f1 f1 f1 00 00 f2 f2 00 [ 23.126455] >ffffc90000007900: 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00 [ 23.126840] ^ [ 23.127138] ffffc90000007980: 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 [ 23.127522] ffffc90000007a00: f3 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 [ 23.127906] ================================================================== [ 23.128324] Disabling lock debugging due to kernel taint Using simple s16 pointers for the 16-bit accesses fixes the problem. For the 32-bit accesses, src and dst can be used directly. Fixes: 96518518cc41 ("netfilter: add nftables") Cc: stable(a)vger.kernel.org Reported-by: Tanguy DUBROCA (@SidewayRE) from @Synacktiv working with ZDI Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)canonical.com> Reviewed-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/netfilter/nft_byteorder.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/net/netfilter/nft_byteorder.c b/net/netfilter/nft_byteorder.c index 9d5947ab8d4e..7b0b8fecb220 100644 --- a/net/netfilter/nft_byteorder.c +++ b/net/netfilter/nft_byteorder.c @@ -30,11 +30,11 @@ void nft_byteorder_eval(const struct nft_expr *expr, const struct nft_byteorder *priv = nft_expr_priv(expr); u32 *src = &regs->data[priv->sreg]; u32 *dst = &regs->data[priv->dreg]; - union { u32 u32; u16 u16; } *s, *d; + u16 *s16, *d16; unsigned int i; - s = (void *)src; - d = (void *)dst; + s16 = (void *)src; + d16 = (void *)dst; switch (priv->size) { case 8: { @@ -61,11 +61,11 @@ void nft_byteorder_eval(const struct nft_expr *expr, switch (priv->op) { case NFT_BYTEORDER_NTOH: for (i = 0; i < priv->len / 4; i++) - d[i].u32 = ntohl((__force __be32)s[i].u32); + dst[i] = ntohl((__force __be32)src[i]); break; case NFT_BYTEORDER_HTON: for (i = 0; i < priv->len / 4; i++) - d[i].u32 = (__force __u32)htonl(s[i].u32); + dst[i] = (__force __u32)htonl(src[i]); break; } break; @@ -73,11 +73,11 @@ void nft_byteorder_eval(const struct nft_expr *expr, switch (priv->op) { case NFT_BYTEORDER_NTOH: for (i = 0; i < priv->len / 2; i++) - d[i].u16 = ntohs((__force __be16)s[i].u16); + d16[i] = ntohs((__force __be16)s16[i]); break; case NFT_BYTEORDER_HTON: for (i = 0; i < priv->len / 2; i++) - d[i].u16 = (__force __u16)htons(s[i].u16); + d16[i] = (__force __u16)htons(s16[i]); break; } break; -- 2.25.1

2 1

[PATCH OLK-5.10] anolis: bond: broadcast ARP or ND messages to all slaves
by Wang Yufen 18 Jul '23

18 Jul '23

From: Tony Lu <tonylu(a)linux.alibaba.com> anolis inclusion from devel-5.10-v5.10.134-12 commit b90e28f7170e1ae40c572f9f80a50bbdc8f8b99f category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I697AN CVE: NA Reference: https://gitee.com/anolis/cloud-kernel/commit/b90e28f7170e1ae40c572f9f80a50b… --------------------------- OpenAnolis Bug Tracker:0000282 This is achieved by broadcasting ARP or ND packets to all of its slave devices on transmit side. The switch will take further actions based on proper configuration. A new sysctl knob "net.bonding.broadcast_arp_or_nd" is introduced which controls the behaviour of broadcasting. Signed-off-by: Tony Lu <tonylu(a)linux.alibaba.com> Acked-by: Dust Li <dust.li(a)linux.alibaba.com> Signed-off-by: Qiao Ma <mqaio(a)linux.alibaba.com> Reviewed-by: Shile Zhang <shile.zhang(a)linux.alibaba.com> Acked-by: Dust Li <dust.li(a)linux.alibaba.com> Signed-off-by: Wang Yufen <wangyufen(a)huawei.com> Signed-off-by: Wang Yufen <wangyufen(a)huawei.com> --- Documentation/networking/ip-sysctl.rst | 11 ++++++++++ drivers/net/bonding/Makefile | 2 +- drivers/net/bonding/bond_main.c | 40 ++++++++++++++++++++++++++++++++++ drivers/net/bonding/bond_sysctl.c | 32 +++++++++++++++++++++++++++ include/net/bonding.h | 4 ++++ 5 files changed, 88 insertions(+), 1 deletion(-) create mode 100644 drivers/net/bonding/bond_sysctl.c diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index df26cf4..b27b887 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -2665,3 +2665,14 @@ max_dgram_qlen - INTEGER Default: 10 + +``/proc/sys/net/bonding/*`` +======================== + +broadcast_arp_or_nd - INTEGER + Control broadcasting ARP or ND messages to all slaves + + 0: Not broadcasting + 1: Broadcasting + + Default: 0 diff --git a/drivers/net/bonding/Makefile b/drivers/net/bonding/Makefile index 30e8ae3..9dd55d9 100644 --- a/drivers/net/bonding/Makefile +++ b/drivers/net/bonding/Makefile @@ -5,7 +5,7 @@ obj-$(CONFIG_BONDING) += bonding.o -bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o bond_sysfs_slave.o bond_debugfs.o bond_netlink.o bond_options.o +bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o bond_sysfs_slave.o bond_debugfs.o bond_netlink.o bond_options.o bond_sysctl.o proc-$(CONFIG_PROC_FS) += bond_procfs.o bonding-objs += $(proc-y) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 1610067..ec0a4d942 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -4559,6 +4559,39 @@ int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave) return ret; } +/* Check whether the skb is arp or nd msg */ +static inline bool skb_is_arp_or_nd(struct sk_buff *skb) +{ + switch (ntohs(skb->protocol)) { + case ETH_P_ARP: + return true; + case ETH_P_IPV6: + if (pskb_may_pull(skb, sizeof(struct ipv6hdr) + + sizeof(struct nd_msg))) { + struct ipv6hdr *hdr = ipv6_hdr(skb); + u8 nexthdr = hdr->nexthdr; + struct icmp6hdr *icmp6; + + if (nexthdr == IPPROTO_ICMPV6) { + icmp6 = icmp6_hdr(skb); + + if ((icmp6->icmp6_type == + NDISC_NEIGHBOUR_SOLICITATION || + icmp6->icmp6_type == + NDISC_NEIGHBOUR_ADVERTISEMENT) && + icmp6->icmp6_code == 0) { + return true; + } + } + } + } + + return false; +} + +static netdev_tx_t bond_xmit_broadcast(struct sk_buff *skb, + struct net_device *bond_dev); + static struct slave *bond_xmit_3ad_xor_slave_get(struct bonding *bond, struct sk_buff *skb, struct bond_up_slave *slaves) @@ -4587,6 +4620,10 @@ static netdev_tx_t bond_3ad_xor_xmit(struct sk_buff *skb, struct bond_up_slave *slaves; struct slave *slave; + /* Broadcast to all slaves. */ + if (sysctl_bond_broadcast_arp_or_nd && skb_is_arp_or_nd(skb)) + return bond_xmit_broadcast(skb, dev); + slaves = rcu_dereference(bond->usable_slaves); slave = bond_xmit_3ad_xor_slave_get(bond, skb, slaves); if (likely(slave)) @@ -5503,6 +5540,7 @@ static int __init bonding_init(void) goto err_link; bond_create_debugfs(); + bond_create_sysctl(); for (i = 0; i < max_bonds; i++) { res = bond_create(&init_net, NULL); @@ -5519,6 +5557,7 @@ static int __init bonding_init(void) return res; err: bond_destroy_debugfs(); + bond_destroy_sysctl(); bond_netlink_fini(); err_link: unregister_pernet_subsys(&bond_net_ops); @@ -5531,6 +5570,7 @@ static void __exit bonding_exit(void) unregister_netdevice_notifier(&bond_netdev_notifier); bond_destroy_debugfs(); + bond_destroy_sysctl(); bond_netlink_fini(); unregister_pernet_subsys(&bond_net_ops); diff --git a/drivers/net/bonding/bond_sysctl.c b/drivers/net/bonding/bond_sysctl.c new file mode 100644 index 0000000..17404d3 --- /dev/null +++ b/drivers/net/bonding/bond_sysctl.c @@ -0,0 +1,32 @@ +// SPDX-License-Identifier: GPL-2.0 +#include <net/net_namespace.h> +#include <linux/sysctl.h> +#include <net/bonding.h> + +int sysctl_bond_broadcast_arp_or_nd __read_mostly; +EXPORT_SYMBOL(sysctl_bond_broadcast_arp_or_nd); + +struct ctl_table_header *bond_broadcast_arp_or_nd_table_header; + +static struct ctl_table bond_broadcast_arp_or_nd_table[] = { + { + .procname = "broadcast_arp_or_nd", + .data = &sysctl_bond_broadcast_arp_or_nd, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = proc_dointvec, + }, + {} +}; + +void bond_create_sysctl(void) +{ + bond_broadcast_arp_or_nd_table_header = + register_net_sysctl(&init_net, "net/bonding", + bond_broadcast_arp_or_nd_table); +} + +void bond_destroy_sysctl(void) +{ + unregister_net_sysctl_table(bond_broadcast_arp_or_nd_table_header); +} diff --git a/include/net/bonding.h b/include/net/bonding.h index d9cc3f5..467c9da 100644 --- a/include/net/bonding.h +++ b/include/net/bonding.h @@ -114,6 +114,8 @@ static inline int is_netpoll_tx_blocked(struct net_device *dev) #define is_netpoll_tx_blocked(dev) (0) #endif +extern int sysctl_bond_broadcast_arp_or_nd; + struct bond_params { int mode; int xmit_policy; @@ -659,6 +661,8 @@ struct bond_vlan_tag *bond_verify_device_path(struct net_device *start_dev, int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave); void bond_slave_arr_work_rearm(struct bonding *bond, unsigned long delay); void bond_work_init_all(struct bonding *bond); +void bond_create_sysctl(void); +void bond_destroy_sysctl(void); #ifdef CONFIG_PROC_FS void bond_create_proc_entry(struct bonding *bond); -- 1.8.3.1

2 1

[PATCH 4.19 1/2] ring-buffer: Fix deadloop issue on reading trace_pipe
by Yongqiang Liu 18 Jul '23

18 Jul '23

From: Zheng Yejian <zhengyejian1(a)huawei.com> mainline inclusion from mainline-v6.5-rc2 commit 7e42907f3a7b4ce3a2d1757f6d78336984daf8f5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7KXY9 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Soft lockup occurs when reading file 'trace_pipe': watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 ? tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ? __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Through the vmcore, I found it's because in tracing_read_pipe(), ring_buffer_empty_cpu() found some buffer is not empty but then it cannot read anything due to "rb_num_of_entries() == 0" always true, Then it infinitely loop the procedure due to user buffer not been filled, see following code path: tracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. find non-empty buffer here trace_find_next_entry_inc() // 2. loop here try to find an entry __find_next_entry() ring_buffer_empty_cpu(); // 3. find non-empty buffer peek_next_entry() // 4. but peek always return NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. because rb_num_of_entries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! } By some analyzing, I found that when resetting ringbuffer, the 'entries' of its pages are not all cleared (see rb_reset_cpu()). Then when reducing the ringbuffer, and if some reduced pages exist dirty 'entries' data, they will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which cause wrong 'overrun' count and eventually cause the deadloop issue. To fix it, we need to clear every pages in rb_reset_cpu(). Link: https://lore.kernel.org/linux-trace-kernel/20230708225144.3785600-1-zhengye… Cc: stable(a)vger.kernel.org Fixes: a5fb833172eca ("ring-buffer: Fix uninitialized read_stamp") Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Reviewed-by: Xu Kuohai <xukuohai(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- kernel/trace/ring_buffer.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 3f098e32a7df..176777060349 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -4407,28 +4407,34 @@ unsigned long ring_buffer_size(struct ring_buffer *buffer, int cpu) } EXPORT_SYMBOL_GPL(ring_buffer_size); +static void rb_clear_buffer_page(struct buffer_page *page) +{ + local_set(&page->write, 0); + local_set(&page->entries, 0); + rb_init_page(page->page); + page->read = 0; +} + static void rb_reset_cpu(struct ring_buffer_per_cpu *cpu_buffer) { + struct buffer_page *page; + rb_head_page_deactivate(cpu_buffer); cpu_buffer->head_page = list_entry(cpu_buffer->pages, struct buffer_page, list); - local_set(&cpu_buffer->head_page->write, 0); - local_set(&cpu_buffer->head_page->entries, 0); - local_set(&cpu_buffer->head_page->page->commit, 0); - - cpu_buffer->head_page->read = 0; + rb_clear_buffer_page(cpu_buffer->head_page); + list_for_each_entry(page, cpu_buffer->pages, list) { + rb_clear_buffer_page(page); + } cpu_buffer->tail_page = cpu_buffer->head_page; cpu_buffer->commit_page = cpu_buffer->head_page; INIT_LIST_HEAD(&cpu_buffer->reader_page->list); INIT_LIST_HEAD(&cpu_buffer->new_pages); - local_set(&cpu_buffer->reader_page->write, 0); - local_set(&cpu_buffer->reader_page->entries, 0); - local_set(&cpu_buffer->reader_page->page->commit, 0); - cpu_buffer->reader_page->read = 0; + rb_clear_buffer_page(cpu_buffer->reader_page); local_set(&cpu_buffer->entries_bytes, 0); local_set(&cpu_buffer->overrun, 0); -- 2.25.1

1 1

[PATCH openEuler-23.09 0/1] kernel: add OPENEULER_VERSION_CODE to version.h
by Xie XiuQi 18 Jul '23

18 Jul '23

Add OPENEULER_VERSION_CODE to version.h, so modules or applications can identify the specific kernel version. In most cases, the out-of-tree module needs to identify the release version of the openEuler for interface adaptation. The existing OPENEULER_VERSION() and OPENEULER_VERSION_CODE() cannot distinguish between LTS versions and innovative versions. Therefore, a new macro OPENEULER_LTS is introduced. The version information is generated in "linux/version.h", as bellow: include/generated/uapi/linux/version.h ``` #define OPENEULER_LTS 0 // 1: LTS; 0: none LTS #define OPENEULER_MAJOR 9999 // OS Major version, 9999: none released #define OPENEULER_MINOR 0 // SP release version #define OPENEULER_VERSION(a,b) (((a) << 8) + (b)) #define OPENEULER_VERSION_CODE 2559744 ``` Use Makefile.oever to avoid future merge conflicts. Xie XiuQi (1): kernel: add OPENEULER_VERSION_CODE to version.h Makefile | 11 ++++++++++- Makefile.oever | 4 ++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 Makefile.oever -- 2.20.1

2 2

[PATCH OLK-5.10 0/4] Fix CVE-2023-3117
by Lu Wei 17 Jul '23

17 Jul '23

Pablo Neira Ayuso (4): netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE netfilter: nf_tables: fix chain binding transaction logic netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain netfilter: nf_tables: unbind non-anonymous set if rule construction fails include/net/netfilter/nf_tables.h | 23 +++++- net/netfilter/nf_tables_api.c | 126 +++++++++++++++++++++--------- net/netfilter/nft_immediate.c | 90 ++++++++++++++++++--- 3 files changed, 194 insertions(+), 45 deletions(-) -- 2.31.1

1 4

[OLK-5.10,0/4] Fix CVE-2023-3117
by Lu Wei 17 Jul '23

17 Jul '23

Pablo Neira Ayuso (4): netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE netfilter: nf_tables: fix chain binding transaction logic netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain netfilter: nf_tables: unbind non-anonymous set if rule construction fails include/net/netfilter/nf_tables.h | 23 +++++- net/netfilter/nf_tables_api.c | 126 +++++++++++++++++++++--------- net/netfilter/nft_immediate.c | 90 ++++++++++++++++++--- 3 files changed, 194 insertions(+), 45 deletions(-) -- 2.31.1

1 4

[PATCH OLK-5.10 1/3] arm64: cpufeatures: Add capability for LDAPR instruction
by Zeng Heng 17 Jul '23

17 Jul '23

From: Will Deacon <will(a)kernel.org> mainline inclusion from mainline-v5.11-rc1 commit 364a5a8ae8dc2dd457e2fefb4da3f3fd2c0ba8b1 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7LP2Z Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Armv8.3 introduced the LDAPR instruction, which provides weaker memory ordering semantics than LDARi (RCpc vs RCsc). Generally, we provide an RCsc implementation when implementing the Linux memory model, but LDAPR can be used as a useful alternative to dependency ordering, particularly when the compiler is capable of breaking the dependencies. Since LDAPR is not available on all CPUs, add a cpufeature to detect it at runtime and allow the instruction to be used with alternative code patching. Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/arm64/Kconfig | 5 ++++- arch/arm64/include/asm/cpucaps.h | 1 + arch/arm64/kernel/cpufeature.c | 10 ++++++++++ 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 75da7a29aa19..e2c2219d5ec4 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -510,7 +510,7 @@ config ARM64_ERRATUM_1742098 are only present if the cryptography extensions are present. All software should have a fallback implementation for CPUs that don't implement the cryptography extensions. - + If unsure, say Y. config ARM64_ERRATUM_845719 @@ -1767,6 +1767,9 @@ config ARM64_AMU_EXTN config AS_HAS_ARMV8_4 def_bool $(cc-option,-Wa$(comma)-march=armv8.4-a) +config AS_HAS_LDAPR + def_bool $(as-instr,.arch_extension rcpc) + config ARM64_TLB_RANGE bool "Enable support for tlbi range feature" default y diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h index b43f8e374114..c7fe08dce205 100644 --- a/arch/arm64/include/asm/cpucaps.h +++ b/arch/arm64/include/asm/cpucaps.h @@ -75,6 +75,7 @@ #define ARM64_WORKAROUND_1742098 67 #define ARM64_HAS_WFXT 68 #define ARM64_WORKAROUND_HISILICON_ERRATUM_162100125 69 +#define ARM64_HAS_LDAPR 70 #define ARM64_NCAPS 80 diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 57631fa553f6..d92ed6383f1a 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -2063,6 +2063,16 @@ static const struct arm64_cpu_capabilities arm64_features[] = { .min_field_value = 1, .matches = has_cpuid_feature, }, + { + .desc = "RCpc load-acquire (LDAPR)", + .capability = ARM64_HAS_LDAPR, + .type = ARM64_CPUCAP_SYSTEM_FEATURE, + .sys_reg = SYS_ID_AA64ISAR1_EL1, + .sign = FTR_UNSIGNED, + .field_pos = ID_AA64ISAR1_LRCPC_SHIFT, + .matches = has_cpuid_feature, + .min_field_value = 1, + }, { .desc = "TLB range maintenance instructions", .capability = ARM64_HAS_TLB_RANGE, -- 2.25.1

1 2

[PATCH 4.19 1/3] netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE
by Yongqiang Liu 17 Jul '23

17 Jul '23

From: Pablo Neira Ayuso <pablo(a)netfilter.org> mainline inclusion from mainline-v6.4-rc7 commit 1240eb93f0616b21c675416516ff3d74798fdc97 category: bugfix bugzilla: 188953 CVE: CVE-2023-3117 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In case of error when adding a new rule that refers to an anonymous set, deactivate expressions via NFT_TRANS_PREPARE state, not NFT_TRANS_RELEASE. Thus, the lookup expression marks anonymous sets as inactive in the next generation to ensure it is not reachable in this transaction anymore and decrement the set refcount as introduced by c1592a89942e ("netfilter: nf_tables: deactivate anonymous set from preparation phase"). The abort step takes care of undoing the anonymous set. This is also consistent with rule deletion, where NFT_TRANS_PREPARE is used. Note that this error path is exercised in the preparation step of the commit protocol. This patch replaces nf_tables_rule_release() by the deactivate and destroy calls, this time with NFT_TRANS_PREPARE. Due to this incorrect error handling, it is possible to access a dangling pointer to the anonymous set that remains in the transaction list. [1009.379054] BUG: KASAN: use-after-free in nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379106] Read of size 8 at addr ffff88816c4c8020 by task nft-rule-add/137110 [1009.379116] CPU: 7 PID: 137110 Comm: nft-rule-add Not tainted 6.4.0-rc4+ #256 [1009.379128] Call Trace: [1009.379132] <TASK> [1009.379135] dump_stack_lvl+0x33/0x50 [1009.379146] ? nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379191] print_address_description.constprop.0+0x27/0x300 [1009.379201] kasan_report+0x107/0x120 [1009.379210] ? nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379255] nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379302] nft_lookup_init+0xa5/0x270 [nf_tables] [1009.379350] nf_tables_newrule+0x698/0xe50 [nf_tables] [1009.379397] ? nf_tables_rule_release+0xe0/0xe0 [nf_tables] [1009.379441] ? kasan_unpoison+0x23/0x50 [1009.379450] nfnetlink_rcv_batch+0x97c/0xd90 [nfnetlink] [1009.379470] ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink] [1009.379485] ? __alloc_skb+0xb8/0x1e0 [1009.379493] ? __alloc_skb+0xb8/0x1e0 [1009.379502] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0 [1009.379509] ? unwind_get_return_address+0x2a/0x40 [1009.379517] ? write_profile+0xc0/0xc0 [1009.379524] ? avc_lookup+0x8f/0xc0 [1009.379532] ? __rcu_read_unlock+0x43/0x60 Fixes: 958bee14d071 ("netfilter: nf_tables: use new transaction infrastructure to handle sets") Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> conflict: net/netfilter/nf_tables_api.c Signed-off-by: Lu Wei <luwei32(a)huawei.com> Reviewed-by: Yue Haibing <yuehaibing(a)huawei.com> Reviewed-by: Wang Weiyang <wangweiyang2(a)huawei.com> Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- net/netfilter/nf_tables_api.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c index f76558e03b24..0e27e489fc69 100644 --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -2755,7 +2755,8 @@ static int nf_tables_newrule(struct net *net, struct sock *nlsk, return 0; err2: - nf_tables_rule_release(&ctx, rule); + nft_rule_expr_deactivate(&ctx, rule, NFT_TRANS_PREPARE); + nf_tables_rule_destroy(&ctx, rule); err1: for (i = 0; i < n; i++) { if (info[i].ops) { -- 2.25.1

1 2

[openEuler-1.0-LTS,0/3] Fix CVE-2023-3117
by Lu Wei 17 Jul '23

17 Jul '23

Pablo Neira Ayuso (3): netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain netfilter: nf_tables: unbind non-anonymous set if rule construction fails include/net/netfilter/nf_tables.h | 1 + net/netfilter/nf_tables_api.c | 29 +++++++++++++++++++++++++---- 2 files changed, 26 insertions(+), 4 deletions(-) -- 2.31.1

1 3

[openEuler-1.0-LTS,0/3] Fix CVE-2023-3117
by Lu Wei 17 Jul '23

17 Jul '23

Pablo Neira Ayuso (3): netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain netfilter: nf_tables: unbind non-anonymous set if rule construction fails include/net/netfilter/nf_tables.h | 1 + net/netfilter/nf_tables_api.c | 29 +++++++++++++++++++++++++---- 2 files changed, 26 insertions(+), 4 deletions(-) -- 2.31.1

1 3

[PATCH openEuler-23.09 0/1] kconfig: Add script to check & update openeuler_defconfig
by Xie XiuQi 15 Jul '23

15 Jul '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, the some command is added to help developers to check and update the defconfig. It is also convenient for continuous integration tools to check the consistency of defconfig. Reference: https://gitee.com/openeuler/kernel/issues/I68D0O Reference: https://gitee.com/openeuler/kernel/issues/I63KVP Reference: https://gitee.com/openeuler/kernel/pulls/286 Reference: https://gitee.com/openeuler/kernel/commit/ca1af5899ef7c1e1617913ecee37d5397… ``` Usage: make check_oedefconfig # # New options might needs to be updated to the default configuration # file. Use the following command: # 'make openeuler_defconfig/menuconfig/update_oedefconfig/save_oedefconfig' # !!! DO NOT EDIT !!! # # defconfig: arch/arm64/configs/openeuler_defconfig # CONFIG_MEMCG=n CONFIG_BLK_CGROUP=n CONFIG_CFS_BANDWIDTH=n CONFIG_RT_GROUP_SCHED=n CONFIG_CGROUP_PIDS=n CONFIG_CGROUP_RDMA=n CONFIG_CGROUP_FREEZER=n CONFIG_CGROUP_HUGETLB=n CONFIG_CPUSETS=n make update_oedefconfig # Update openeuler_defconfig base on current source code make save_oedefconfig # Save current .config to openeuler_defconfig' ``` If someone adds a new Kconfig, he should also explicitly update openeuler_defconfig, whether it's enabled or disabled. Again, do *NOT* edit openeuler_defconfig directly. Link: https://gitee.com/openeuler/kernel/pulls/286 Xie XiuQi (1): kconfig: Add script to check & update openeuler_defconfig scripts/kconfig/Makefile | 23 +++++++++++++++++++++++ scripts/kconfig/makeconfig.sh | 24 ++++++++++++++++++++++++ 2 files changed, 47 insertions(+) create mode 100644 scripts/kconfig/makeconfig.sh -- 2.20.1

2 2

[PATCH openEuler-23.09 v1 0/8] Add NUMA-awareness to qspinlock
by Wei Li 15 Jul '23

15 Jul '23

Backport compact NUMA-aware lock feature v15 from linux maillist, and add support for arch arm64. bugzilla: https://gitee.com/openeuler/kernel/issues/I7LEG5 Reference: https://lore.kernel.org/linux-arm-kernel/20210514200743.3026725-1-alex.koga… Alex Kogan (6): locking/qspinlock: Rename mcs lock/unlock macros and make them more generic locking/qspinlock: Refactor the qspinlock slow path locking/qspinlock: Introduce CNA into the slow path of qspinlock locking/qspinlock: Introduce starvation avoidance into CNA locking/qspinlock: Avoid moving certain threads between waiting queues in CNA locking/qspinlock: Introduce the shuffle reduction optimization into CNA Wei Li (2): locking/qspinlock: Add CNA support for ARM64 locking/qspinlock: Disable CNA by default .../admin-guide/kernel-parameters.txt | 18 + arch/arm/include/asm/mcs_spinlock.h | 6 +- arch/arm64/Kconfig | 16 + arch/x86/Kconfig | 20 + arch/x86/include/asm/qspinlock.h | 4 + include/asm-generic/mcs_spinlock.h | 4 +- kernel/locking/mcs_spinlock.h | 20 +- kernel/locking/qspinlock.c | 82 +++- kernel/locking/qspinlock_cna.h | 425 ++++++++++++++++++ kernel/locking/qspinlock_paravirt.h | 2 +- mm/mempolicy.c | 4 + 11 files changed, 578 insertions(+), 23 deletions(-) create mode 100644 kernel/locking/qspinlock_cna.h -- 2.25.1

2 9

[PATCH] KVM: fix overflow of zero page refcount with ksm running
by Lei Chen 14 Jul '23

14 Jul '23

From: Zhuang Yanying <ann.zhuangyanying(a)huawei.com> mainline inclusion from mainline-v5.10 commit 7df003c85218b5f5b10a7f6418208f31e813f38f category: bugfix -------------------------------- We are testing Virtual Machine with KSM on v5.4-rc2 kernel, and found the zero_page refcount overflow. The cause of refcount overflow is increased in try_async_pf (get_user_page) without being decreased in mmu_set_spte() while handling ept violation. In kvm_release_pfn_clean(), only unreserved page will call put_page. However, zero page is reserved. So, as well as creating and destroy vm, the refcount of zero page will continue to increase until it overflows. step1: echo 10000 > /sys/kernel/pages_to_scan/pages_to_scan echo 1 > /sys/kernel/pages_to_scan/run echo 1 > /sys/kernel/pages_to_scan/use_zero_pages step2: just create several normal qemu kvm vms. And destroy it after 10s. Repeat this action all the time. After a long period of time, all domains hang because of the refcount of zero page overflow. Qemu print error log as follow: â€¦ error: kvm run failed Bad address EAX=00006cdc EBX=00000008 ECX=80202001 EDX=078bfbfd ESI=ffffffff EDI=00000000 EBP=00000008 ESP=00006cc4 EIP=000efd75 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 000f7070 00000037 IDT= 000f70ae 00000000 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=00 01 00 00 00 e9 e8 00 00 00 c7 05 4c 55 0f 00 01 00 00 00 <8b> 35 00 00 01 00 8b 3d 04 00 01 00 b8 d8 d3 00 00 c1 e0 08 0c ea a3 00 00 01 00 c7 05 04 â€¦ Meanwhile, a kernel warning is departed. [40914.836375] WARNING: CPU: 3 PID: 82067 at ./include/linux/mm.h:987 try_get_page+0x1f/0x30 [40914.836412] CPU: 3 PID: 82067 Comm: CPU 0/KVM Kdump: loaded Tainted: G OE 5.2.0-rc2 #5 [40914.836415] RIP: 0010:try_get_page+0x1f/0x30 [40914.836417] Code: 40 00 c3 0f 1f 84 00 00 00 00 00 48 8b 47 08 a8 01 75 11 8b 47 34 85 c0 7e 10 f0 ff 47 34 b8 01 00 00 00 c3 48 8d 78 ff eb e9 <0f> 0b 31 c0 c3 66 90 66 2e 0f 1f 84 00 0 0 00 00 00 48 8b 47 08 a8 [40914.836418] RSP: 0018:ffffb4144e523988 EFLAGS: 00010286 [40914.836419] RAX: 0000000080000000 RBX: 0000000000000326 RCX: 0000000000000000 [40914.836420] RDX: 0000000000000000 RSI: 00004ffdeba10000 RDI: ffffdf07093f6440 [40914.836421] RBP: ffffdf07093f6440 R08: 800000424fd91225 R09: 0000000000000000 [40914.836421] R10: ffff9eb41bfeebb8 R11: 0000000000000000 R12: ffffdf06bbd1e8a8 [40914.836422] R13: 0000000000000080 R14: 800000424fd91225 R15: ffffdf07093f6440 [40914.836423] FS: 00007fb60ffff700(0000) GS:ffff9eb4802c0000(0000) knlGS:0000000000000000 [40914.836425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40914.836426] CR2: 0000000000000000 CR3: 0000002f220e6002 CR4: 00000000003626e0 [40914.836427] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [40914.836427] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [40914.836428] Call Trace: [40914.836433] follow_page_pte+0x302/0x47b [40914.836437] __get_user_pages+0xf1/0x7d0 [40914.836441] ? irq_work_queue+0x9/0x70 [40914.836443] get_user_pages_unlocked+0x13f/0x1e0 [40914.836469] __gfn_to_pfn_memslot+0x10e/0x400 [kvm] [40914.836486] try_async_pf+0x87/0x240 [kvm] [40914.836503] tdp_page_fault+0x139/0x270 [kvm] [40914.836523] kvm_mmu_page_fault+0x76/0x5e0 [kvm] [40914.836588] vcpu_enter_guest+0xb45/0x1570 [kvm] [40914.836632] kvm_arch_vcpu_ioctl_run+0x35d/0x580 [kvm] [40914.836645] kvm_vcpu_ioctl+0x26e/0x5d0 [kvm] [40914.836650] do_vfs_ioctl+0xa9/0x620 [40914.836653] ksys_ioctl+0x60/0x90 [40914.836654] __x64_sys_ioctl+0x16/0x20 [40914.836658] do_syscall_64+0x5b/0x180 [40914.836664] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [40914.836666] RIP: 0033:0x7fb61cb6bfc7 Signed-off-by: LinFeng <linfeng23(a)huawei.com> Signed-off-by: Zhuang Yanying <ann.zhuangyanying(a)huawei.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Lei Chen <lei.chen(a)smartx.com> --- virt/kvm/kvm_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 96fb21ac7224..e4e3dc429ec4 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -170,6 +170,7 @@ bool kvm_is_reserved_pfn(kvm_pfn_t pfn) */ if (pfn_valid(pfn)) return PageReserved(pfn_to_page(pfn)) && + !is_zero_pfn(pfn) && !kvm_is_zone_device_pfn(pfn); return true; -- 2.34.1

2 1