- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] nvme: fix memory allocation in nvme_pr_read_keys()
by Long Li 26 Mar '26

26 Mar '26

From: Sungwoo Kim <iam(a)sung-woo.kim> mainline inclusion from mainline-v6.17-rc7 commit c3320153769f05fd7fe9d840cb555dd3080ae424 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13870 CVE: CVE-2026-23244 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- nvme_pr_read_keys() takes num_keys from userspace and uses it to calculate the allocation size for rse via struct_size(). The upper limit is PR_KEYS_MAX (64K). A malicious or buggy userspace can pass a large num_keys value that results in a 4MB allocation attempt at most, causing a warning in the page allocator when the order exceeds MAX_PAGE_ORDER. To fix this, use kvzalloc() instead of kzalloc(). This bug has the same reasoning and fix with the patch below: https://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gm… Warning log: WARNING: mm/page_alloc.c:5216 at __alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216, CPU#1: syz-executor117/272 Modules linked in: CPU: 1 UID: 0 PID: 272 Comm: syz-executor117 Not tainted 6.19.0 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:__alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216 Code: ff 83 bd a8 fe ff ff 0a 0f 86 69 fb ff ff 0f b6 1d f9 f9 c4 04 80 fb 01 0f 87 3b 76 30 ff 83 e3 01 75 09 c6 05 e4 f9 c4 04 01 <0f> 0b 48 c7 85 70 fe ff ff 00 00 00 00 e9 8f fd ff ff 31 c0 e9 0d RSP: 0018:ffffc90000fcf450 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff920001f9ea0 RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000040dc0 RBP: ffffc90000fcf648 R08: ffff88800b6c3380 R09: 0000000000000001 R10: ffffc90000fcf840 R11: ffff88807ffad280 R12: 0000000000000000 R13: 0000000000040dc0 R14: 0000000000000001 R15: ffffc90000fcf620 FS: 0000555565db33c0(0000) GS:ffff8880be26c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000000c CR3: 0000000003b72000 CR4: 00000000000006f0 Call Trace: <TASK> alloc_pages_mpol+0x236/0x4d0 mm/mempolicy.c:2486 alloc_frozen_pages_noprof+0x149/0x180 mm/mempolicy.c:2557 ___kmalloc_large_node+0x10c/0x140 mm/slub.c:5598 __kmalloc_large_node_noprof+0x25/0xc0 mm/slub.c:5629 __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x483/0x6f0 mm/slub.c:5669 kmalloc_noprof include/linux/slab.h:961 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] nvme_pr_read_keys+0x8f/0x4c0 drivers/nvme/host/pr.c:245 blkdev_pr_read_keys block/ioctl.c:456 [inline] blkdev_common_ioctl+0x1b71/0x29b0 block/ioctl.c:730 blkdev_ioctl+0x299/0x700 block/ioctl.c:786 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x1bf/0x220 fs/ioctl.c:583 x64_sys_call+0x1280/0x21b0 mnt/fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x71/0x330 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb893d3108d Code: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffff61f2f38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffff61f3138 RCX: 00007fb893d3108d RDX: 0000000020000040 RSI: 00000000c01070ce RDI: 0000000000000003 RBP: 0000000000000001 R08: 0000000000000000 R09: 00007ffff61f3138 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffff61f3128 R14: 00007fb893dae530 R15: 0000000000000001 </TASK> Fixes: 5fd96a4e15de (nvme: Add pr_ops read_keys support) Acked-by: Chao Shi <cshi008(a)fiu.edu> Acked-by: Weidong Zhu <weizhu(a)fiu.edu> Acked-by: Dave Tian <daveti(a)purdue.edu> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Sungwoo Kim <iam(a)sung-woo.kim> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/host/pr.c [Context conflicts] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- drivers/nvme/host/pr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/host/pr.c b/drivers/nvme/host/pr.c index 803efc97fd1e..08b8965bd945 100644 --- a/drivers/nvme/host/pr.c +++ b/drivers/nvme/host/pr.c @@ -213,7 +213,7 @@ static int nvme_pr_read_keys(struct block_device *bdev, * enough to get enough keys to fill the return keys buffer. */ rse_len = struct_size(rse, regctl_eds, num_keys); - rse = kzalloc(rse_len, GFP_KERNEL); + rse = kvzalloc(rse_len, GFP_KERNEL); if (!rse) return -ENOMEM; @@ -238,7 +238,7 @@ static int nvme_pr_read_keys(struct block_device *bdev, } free_rse: - kfree(rse); + kvfree(rse); return ret; } -- 2.39.2

2 1

[PATCH OLK-6.6 0/5] Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 25 Mar '26

25 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

2 6

[PATCH OLK-6.6] perf: Fix __perf_event_overflow() vs perf_remove_from_context() race
by Luo Gengkun 25 Mar '26

25 Mar '26

From: Peter Zijlstra <peterz(a)infradead.org> mainline inclusion from mainline-v7.0-rc2 commit c9bc1753b3cc41d0e01fbca7f035258b5f4db0ae category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13907 CVE: CVE-2026-23271 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- Make sure that __perf_event_overflow() runs with IRQs disabled for all possible callchains. Specifically the software events can end up running it with only preemption disabled. This opens up a race vs perf_event_exit_event() and friends that will go and free various things the overflow path expects to be present, like the BPF program. Fixes: 592903cdcbf6 ("perf_counter: add an event_list") Reported-by: Simond Hu <cmdhh1767(a)gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Tested-by: Simond Hu <cmdhh1767(a)gmail.com> Link: https://patch.msgid.link/20260224122909.GV1395416@noisy.programming.kicks-a… Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 42 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index e5c2105625a2..1d3f8eed6d0d 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -9708,6 +9708,13 @@ int perf_event_overflow(struct perf_event *event, struct perf_sample_data *data, struct pt_regs *regs) { + /* + * Entry point from hardware PMI, interrupts should be disabled here. + * This serializes us against perf_event_remove_from_context() in + * things like perf_event_release_kernel(). + */ + lockdep_assert_irqs_disabled(); + return __perf_event_overflow(event, 1, data, regs); } @@ -9788,6 +9795,19 @@ static void perf_swevent_event(struct perf_event *event, u64 nr, { struct hw_perf_event *hwc = &event->hw; + /* + * This is: + * - software preempt + * - tracepoint preempt + * - tp_target_task irq (ctx->lock) + * - uprobes preempt/irq + * - kprobes preempt/irq + * - hw_breakpoint irq + * + * Any of these are sufficient to hold off RCU and thus ensure @event + * exists. + */ + lockdep_assert_preemption_disabled(); local64_add(nr, &event->count); if (!regs) @@ -9796,6 +9816,16 @@ static void perf_swevent_event(struct perf_event *event, u64 nr, if (!is_sampling_event(event)) return; + /* + * Serialize against event_function_call() IPIs like normal overflow + * event handling. Specifically, must not allow + * perf_event_release_kernel() -> perf_remove_from_context() to make + * progress and 'release' the event from under us. + */ + guard(irqsave)(); + if (event->state != PERF_EVENT_STATE_ACTIVE) + return; + if ((event->attr.sample_type & PERF_SAMPLE_PERIOD) && !event->attr.freq) { data->period = nr; return perf_swevent_overflow(event, 1, data, regs); @@ -10299,6 +10329,11 @@ void perf_tp_event(u16 event_type, u64 count, void *record, int entry_size, struct perf_sample_data data; struct perf_event *event; + /* + * Per being a tracepoint, this runs with preemption disabled. + */ + lockdep_assert_preemption_disabled(); + struct perf_raw_record raw = { .frag = { .size = entry_size, @@ -10712,6 +10747,11 @@ void perf_bp_event(struct perf_event *bp, void *data) struct perf_sample_data sample; struct pt_regs *regs = data; + /* + * Exception context, will have interrupts disabled. + */ + lockdep_assert_irqs_disabled(); + perf_sample_data_init(&sample, bp->attr.bp_addr, 0); if (!bp->hw.state && !perf_exclude_event(bp, regs)) @@ -11164,7 +11204,7 @@ static enum hrtimer_restart perf_swevent_hrtimer(struct hrtimer *hrtimer) if (regs && !perf_exclude_event(event, regs)) { if (!(event->attr.exclude_idle && is_idle_task(current))) - if (__perf_event_overflow(event, 1, &data, regs)) + if (perf_event_overflow(event, &data, regs)) ret = HRTIMER_NORESTART; } -- 2.34.1

2 1

[PATCH 0/5] Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 25 Mar '26

25 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

1 5

[PATCH OLK-6.6] media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
by Chen Jinghuang 25 Mar '26

25 Mar '26

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v7.0-rc2 commit bfbc0b5b32a8f28ce284add619bf226716a59bc0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13873 CVE: CVE-2026-23253 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock. Cc: stable(a)vger.kernel.org Fixes: 34731df288a5 ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer") Reported-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ab12f0c08dd7ab8d057c Tested-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: drivers/media/dvb-core/dmxdev.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/media/dvb-core/dmxdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c index 9ce5f010de3f..4ce3ae3954c5 100644 --- a/drivers/media/dvb-core/dmxdev.c +++ b/drivers/media/dvb-core/dmxdev.c @@ -168,7 +168,9 @@ static int dvb_dvr_open(struct inode *inode, struct file *file) mutex_unlock(&dmxdev->mutex); return -ENOMEM; } - dvb_ringbuffer_init(&dmxdev->dvr_buffer, mem, DVR_BUFFER_SIZE); + dmxdev->dvr_buffer.data = mem; + dmxdev->dvr_buffer.size = DVR_BUFFER_SIZE; + dvb_ringbuffer_reset(&dmxdev->dvr_buffer); if (dmxdev->may_do_mmap) dvb_vb2_init(&dmxdev->dvr_vb2_ctx, "dvr", file->f_flags & O_NONBLOCK); -- 2.34.1

2 1

[PATCH 0/5] Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 25 Mar '26

25 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

1 5

[PATCH OLK-6.6] arm64: fix compile error if CONFIG_ARCH_HAS_COPY_MC not enabled
by Wupeng Ma 24 Mar '26

24 Mar '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8386 ------------------------------------------ If CONFIG_ARCH_HAS_COPY_MC is not enabled, kernel can not be compiled with the following error: aarch64-linux-gnu-ld: arch/arm64/mm/flush.o: in function `copy_mc_to_user_page': arch/arm64/mm/flush.c:56:(.text+0x3a4): undefined reference to `memcpy_mc' aarch64-linux-gnu-ld: mm/memory.o: in function `__access_remote_vm': mm/memory.c:6674:(.text+0xe138): undefined reference to `memcpy_mc' aarch64-linux-gnu-ld: mm/kasan/shadow.o: in function `memcpy_mc': mm/kasan/shadow.c:90:(.text+0xa94): undefined reference to `__memcpy_mc' Fix this by add stub function of memcpy_mc which just call memcpy. Fixes: d51d1b114c86 ("arm64: mm: support recovery from copy_{from/to}_user_page()") Fixes: b991780c836c ("arm64: introduce copy_mc_to_kernel() implementation") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- arch/arm64/include/asm/string.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/include/asm/string.h b/arch/arm64/include/asm/string.h index 23eca4fb24fa6..97844a8e3ed3a 100644 --- a/arch/arm64/include/asm/string.h +++ b/arch/arm64/include/asm/string.h @@ -36,8 +36,13 @@ extern void *memcpy(void *, const void *, __kernel_size_t); extern void *__memcpy(void *, const void *, __kernel_size_t); #define __HAVE_ARCH_MEMCPY_MC +#ifdef CONFIG_ARCH_HAS_COPY_MC extern int memcpy_mc(void *, const void *, __kernel_size_t); extern int __memcpy_mc(void *, const void *, __kernel_size_t); +#else +#define memcpy_mc(dst, src, len) __memcpy(dst, src, len) +#define __memcpy_mc(dst, src, len) __memcpy(dst, src, len) +#endif #define __HAVE_ARCH_MEMMOVE extern void *memmove(void *, const void *, __kernel_size_t); @@ -61,7 +66,9 @@ void memcpy_flushcache(void *dst, const void *src, size_t cnt); */ #define memcpy(dst, src, len) __memcpy(dst, src, len) +#ifndef memcpy_mc #define memcpy_mc(dst, src, len) __memcpy_mc(dst, src, len) +#endif #define memmove(dst, src, len) __memmove(dst, src, len) #define memset(s, c, n) __memset(s, c, n) -- 2.43.0

2 1

[PATCH OLK-6.6] media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
by Chen Jinghuang 24 Mar '26

24 Mar '26

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v7.0-rc2 commit bfbc0b5b32a8f28ce284add619bf226716a59bc0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13873 CVE: CVE-2026-23253 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock. Cc: stable(a)vger.kernel.org Fixes: 34731df288a5f ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer") Reported-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Tested-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: drivers/media/dvb-core/dmxdev.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/media/dvb-core/dmxdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c index 9ce5f010de3f..4ce3ae3954c5 100644 --- a/drivers/media/dvb-core/dmxdev.c +++ b/drivers/media/dvb-core/dmxdev.c @@ -168,7 +168,9 @@ static int dvb_dvr_open(struct inode *inode, struct file *file) mutex_unlock(&dmxdev->mutex); return -ENOMEM; } - dvb_ringbuffer_init(&dmxdev->dvr_buffer, mem, DVR_BUFFER_SIZE); + dmxdev->dvr_buffer.data = mem; + dmxdev->dvr_buffer.size = DVR_BUFFER_SIZE; + dvb_ringbuffer_reset(&dmxdev->dvr_buffer); if (dmxdev->may_do_mmap) dvb_vb2_init(&dmxdev->dvr_vb2_ctx, "dvr", file->f_flags & O_NONBLOCK); -- 2.34.1

2 1

[PATCH OLK-6.6] media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
by Chen Jinghuang 24 Mar '26

24 Mar '26

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v7.0-rc2 commit bfbc0b5b32a8f28ce284add619bf226716a59bc0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13873 CVE: CVE-2026-23253 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty. Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}. The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions. Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock. Cc: stable(a)vger.kernel.org Fixes: 34731df288a5f ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer") Reported-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Tested-by: syzbot+ab12f0c08dd7ab8d057c(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Conflicts: drivers/media/dvb-core/dmxdev.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/media/dvb-core/dmxdev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c index 9ce5f010de3f..4ce3ae3954c5 100644 --- a/drivers/media/dvb-core/dmxdev.c +++ b/drivers/media/dvb-core/dmxdev.c @@ -168,7 +168,9 @@ static int dvb_dvr_open(struct inode *inode, struct file *file) mutex_unlock(&dmxdev->mutex); return -ENOMEM; } - dvb_ringbuffer_init(&dmxdev->dvr_buffer, mem, DVR_BUFFER_SIZE); + dmxdev->dvr_buffer.data = mem; + dmxdev->dvr_buffer.size = DVR_BUFFER_SIZE; + dvb_ringbuffer_reset(&dmxdev->dvr_buffer); if (dmxdev->may_do_mmap) dvb_vb2_init(&dmxdev->dvr_vb2_ctx, "dvr", file->f_flags & O_NONBLOCK); -- 2.34.1

2 1

[PATCH 0/5] Transition from CPU Type to MIDR Register for
by liqiqi 24 Mar '26

24 Mar '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register and removes the need for defining CPU types and their related interfaces. liqiqi (5): kvm: arm64: use MIDR_HISI_TSV110 to determine whether NCSNP is supported kvm: arm64: Add HIP10, HIP10C MIDR definitions kvm: arm64: Use MIDR to determine whether DVMBM is supported kvm: arm64: Use MIDR to determine whether IPIv is supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 15 insertions(+), 113 deletions(-) -- 2.43.0

1 5