- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] arm64: Fix a typo in xcall_init_task()
by Jinjie Ruan 08 Jul '25

08 Jul '25

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/release-management/issues/IC9Q31 -------------------------------- In xcall_init_task(), it should copy the original xcall enable bitmap to the new process. Fixes: f22baea0113c ("arm64: Reserve a kabi in task_struct exclusively for xcall") Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/arm64/kernel/xcall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/xcall.c b/arch/arm64/kernel/xcall.c index fd62b8dd3020..f778671c21cf 100644 --- a/arch/arm64/kernel/xcall.c +++ b/arch/arm64/kernel/xcall.c @@ -19,7 +19,7 @@ int xcall_init_task(struct task_struct *p, struct task_struct *orig) return -ENOMEM; if (orig->xinfo) { - bitmap_copy(TASK_XINFO(p)->xcall_enable, TASK_XINFO(p)->xcall_enable, + bitmap_copy(TASK_XINFO(p)->xcall_enable, TASK_XINFO(orig)->xcall_enable, __NR_syscalls); #ifdef CONFIG_XCALL_PREFETCH TASK_XINFO(p)->prefetch = TASK_XINFO(orig)->prefetch; -- 2.34.1

2 1

[PATCH OLK-5.10 00/12] RDMA/hns: Stability and Security Fixes and Improvements
by huangdonghua 08 Jul '25

08 Jul '25

Fixes issues such as memory leaks, invalid access, information leakage, and parameter errors. Improves parameter validation and resource initialization to enhance driver stability and security. Chengchang Tang (1): RDMA/hns: Fix accessing invalid dip_ctx during destroying QP Junxian Huang (7): RDMA/hns: Add check between dca_min_size and dca_max_size RDMA/hns: Fix accessing uninitialized resources RDMA/hns: Fix poe memory leak in error flow RDMA/hns: Fix descriptions of stars api RDMA/hns: Fix divide-by-zero error in dca debugfs RDMA/hns: Use __free_page() to free pages allocated with alloc_page() RDMA/hns: Fix unmatched condition in error flow Yuyu Li (2): RDMA/hns: Fix congestion control algorithm parameter range RDMA/hns: Fix scc_param failed logic judgments wenglianfa (2): RDMA/hns: Fix address information leakage of DCA memory RDMA/hns: Fix double destruction of rsv_qp drivers/infiniband/hw/hns/hns_roce_dca.c | 5 +-- drivers/infiniband/hw/hns/hns_roce_debugfs.c | 7 ++++ drivers/infiniband/hw/hns/hns_roce_device.h | 2 ++ drivers/infiniband/hw/hns/hns_roce_ext.h | 22 ++++++++++++- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 34 ++++++++++++-------- drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 22 +++++++++---- drivers/infiniband/hw/hns/hns_roce_main.c | 20 ++++-------- drivers/infiniband/hw/hns/hns_roce_qp.c | 2 ++ drivers/infiniband/hw/hns/hns_roce_sysfs.c | 3 +- 9 files changed, 79 insertions(+), 38 deletions(-) -- 2.33.0

2 13

[PATCH openEuler-1.0-LTS] net: ch9200: fix uninitialised access during mii_nway_restart
by Zhang Changzhong 08 Jul '25

08 Jul '25

From: Qasim Ijaz <qasdev00(a)gmail.com> mainline inclusion from mainline-v6.16-rc1 commit 9ad0452c0277b816a435433cca601304cfac7c21 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICIQAB CVE: CVE-2025-38086 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read(): return (buff[0] | buff[1] << 8); The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff". To fix this we should check the return value of control_read() and return early on error. Reported-by: syzbot <syzbot+3361c2d6f78a3e0892f9(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=3361c2d6f78a3e0892f9 Tested-by: syzbot <syzbot+3361c2d6f78a3e0892f9(a)syzkaller.appspotmail.com> Fixes: 4a476bd6d1d9 ("usbnet: New driver for QinHeng CH9200 devices") Cc: stable(a)vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> Link: https://patch.msgid.link/20250526183607.66527-1-qasdev00@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/net/usb/ch9200.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/ch9200.c b/drivers/net/usb/ch9200.c index 9df3c1f..52d73b7 100644 --- a/drivers/net/usb/ch9200.c +++ b/drivers/net/usb/ch9200.c @@ -180,6 +180,7 @@ static int ch9200_mdio_read(struct net_device *netdev, int phy_id, int loc) { struct usbnet *dev = netdev_priv(netdev); unsigned char buff[2]; + int ret; netdev_dbg(netdev, "ch9200_mdio_read phy_id:%02x loc:%02x\n", phy_id, loc); @@ -187,8 +188,10 @@ static int ch9200_mdio_read(struct net_device *netdev, int phy_id, int loc) if (phy_id != 0) return -ENODEV; - control_read(dev, REQUEST_READ, 0, loc * 2, buff, 0x02, - CONTROL_TIMEOUT_MS); + ret = control_read(dev, REQUEST_READ, 0, loc * 2, buff, 0x02, + CONTROL_TIMEOUT_MS); + if (ret < 0) + return ret; return (buff[0] | buff[1] << 8); } -- 2.9.5

2 1

[PATCH OLK-6.6] iio: light: opt3001: fix deadlock due to concurrent flag access
by Ye Bin 08 Jul '25

08 Jul '25

From: Luca Ceresoli <luca.ceresoli(a)bootlin.com> mainline inclusion from mainline-v6.15-rc6 commit f063a28002e3350088b4577c5640882bf4ea17ea category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC992V CVE: CVE-2025-37968 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock. Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages. Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor") Cc: stable(a)vger.kernel.org Signed-off-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> Link: https://patch.msgid.link/20250321-opt3001-irq-fix-v1-1-6c520d851562@bootlin… Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Conflicts: drivers/iio/light/opt3001.c [As context diff] Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/iio/light/opt3001.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/iio/light/opt3001.c b/drivers/iio/light/opt3001.c index dc529cbe3805..25a45c4251fb 100644 --- a/drivers/iio/light/opt3001.c +++ b/drivers/iio/light/opt3001.c @@ -692,8 +692,9 @@ static irqreturn_t opt3001_irq(int irq, void *_iio) struct opt3001 *opt = iio_priv(iio); int ret; bool wake_result_ready_queue = false; + bool ok_to_ignore_lock = opt->ok_to_ignore_lock; - if (!opt->ok_to_ignore_lock) + if (!ok_to_ignore_lock) mutex_lock(&opt->lock); ret = i2c_smbus_read_word_swapped(opt->client, OPT3001_CONFIGURATION); @@ -730,7 +731,7 @@ static irqreturn_t opt3001_irq(int irq, void *_iio) } out: - if (!opt->ok_to_ignore_lock) + if (!ok_to_ignore_lock) mutex_unlock(&opt->lock); if (wake_result_ready_queue) -- 2.34.1

2 1

[PATCH OLK-5.10] iio: light: opt3001: fix deadlock due to concurrent flag access
by Ye Bin 08 Jul '25

08 Jul '25

From: Luca Ceresoli <luca.ceresoli(a)bootlin.com> mainline inclusion from mainline-v6.15-rc6 commit f063a28002e3350088b4577c5640882bf4ea17ea category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC992V CVE: CVE-2025-37968 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock. Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages. Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor") Cc: stable(a)vger.kernel.org Signed-off-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> Link: https://patch.msgid.link/20250321-opt3001-irq-fix-v1-1-6c520d851562@bootlin… Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Conflicts: drivers/iio/light/opt3001.c [As context diff] Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/iio/light/opt3001.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/iio/light/opt3001.c b/drivers/iio/light/opt3001.c index ff776259734a..a6823130d387 100644 --- a/drivers/iio/light/opt3001.c +++ b/drivers/iio/light/opt3001.c @@ -688,8 +688,9 @@ static irqreturn_t opt3001_irq(int irq, void *_iio) struct opt3001 *opt = iio_priv(iio); int ret; bool wake_result_ready_queue = false; + bool ok_to_ignore_lock = opt->ok_to_ignore_lock; - if (!opt->ok_to_ignore_lock) + if (!ok_to_ignore_lock) mutex_lock(&opt->lock); ret = i2c_smbus_read_word_swapped(opt->client, OPT3001_CONFIGURATION); @@ -726,7 +727,7 @@ static irqreturn_t opt3001_irq(int irq, void *_iio) } out: - if (!opt->ok_to_ignore_lock) + if (!ok_to_ignore_lock) mutex_unlock(&opt->lock); if (wake_result_ready_queue) -- 2.34.1

2 1

[PATCH OLK-6.6] parisc: Fix double SIGFPE crash
by Ye Bin 08 Jul '25

08 Jul '25

From: Helge Deller <deller(a)gmx.de> stable inclusion from stable-v6.6.90 commit 6a098c51d18ec99485668da44294565c43dbc106 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC9958 CVE: CVE-2025-37991 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit de3629baf5a33af1919dec7136d643b0662e85ef upstream. Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters *any* floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace. The issue can be reproduced with this test program: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception Signed-off-by: Helge Deller <deller(a)gmx.de> Suggested-by: John David Anglin <dave.anglin(a)bell.net> Reported-by: Camm Maguire <camm(a)maguirefamily.org> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- arch/parisc/math-emu/driver.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/arch/parisc/math-emu/driver.c b/arch/parisc/math-emu/driver.c index 6ce427b58836..ecd27b48d61f 100644 --- a/arch/parisc/math-emu/driver.c +++ b/arch/parisc/math-emu/driver.c @@ -103,9 +103,19 @@ handle_fpe(struct pt_regs *regs) memcpy(regs->fr, frcopy, sizeof regs->fr); if (signalcode != 0) { - force_sig_fault(signalcode >> 24, signalcode & 0xffffff, - (void __user *) regs->iaoq[0]); - return -1; + int sig = signalcode >> 24; + + if (sig == SIGFPE) { + /* + * Clear floating point trap bit to avoid trapping + * again on the first floating-point instruction in + * the userspace signal handler. + */ + regs->fr[0] &= ~(1ULL << 38); + } + force_sig_fault(sig, signalcode & 0xffffff, + (void __user *) regs->iaoq[0]); + return -1; } return signalcode ? -1 : 0; -- 2.34.1

2 1

[PATCH OLK-6.6] drm/amdkfd: Fix mode1 reset crash issue
by Ye Bin 08 Jul '25

08 Jul '25

From: Philip Yang <Philip.Yang(a)amd.com> stable inclusion from stable-v6.6.80 commit 89af6b39f028c130d4362f57042927f005423e6a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC6M0E CVE: CVE-2025-37854 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit f0b4440cdc1807bb6ec3dce0d6de81170803569b ] If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM. There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash. To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs. Signed-off-by: Philip Yang <Philip.Yang(a)amd.com> Reviewed-by: Lijo Lazar <lijo.lazar(a)amd.com> Reviewed-by: Felix Kuehling <felix.kuehling(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 64346c71c62a..a6d08dee74f6 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -35,6 +35,7 @@ #include <linux/pm_runtime.h> #include "amdgpu_amdkfd.h" #include "amdgpu.h" +#include "amdgpu_reset.h" struct mm_struct; @@ -1110,6 +1111,17 @@ static void kfd_process_remove_sysfs(struct kfd_process *p) p->kobj = NULL; } +/* + * If any GPU is ongoing reset, wait for reset complete. + */ +static void kfd_process_wait_gpu_reset_complete(struct kfd_process *p) +{ + int i; + + for (i = 0; i < p->n_pdds; i++) + flush_workqueue(p->pdds[i]->dev->adev->reset_domain->wq); +} + /* No process locking is needed in this function, because the process * is not findable any more. We must assume that no other thread is * using it any more, otherwise we couldn't safely free the process @@ -1123,6 +1135,11 @@ static void kfd_process_wq_release(struct work_struct *work) kfd_process_dequeue_from_all_devices(p); pqm_uninit(&p->pqm); + /* + * If GPU in reset, user queues may still running, wait for reset complete. + */ + kfd_process_wait_gpu_reset_complete(p); + /* Signal the eviction fence after user mode queues are * destroyed. This allows any BOs to be freed without * triggering pointless evictions or waiting for fences. -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] fix CVE-2025-38118
by Ye Bin 08 Jul '25

08 Jul '25

Luiz Augusto von Dentz (2): Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete Bluetooth: MGMT: Fix sparse errors include/net/bluetooth/hci_core.h | 1 - net/bluetooth/hci_core.c | 4 +--- net/bluetooth/mgmt.c | 39 ++++++++++---------------------- 3 files changed, 13 insertions(+), 31 deletions(-) -- 2.34.1

2 3

[PATCH OLK-6.6] LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()
by Ye Bin 08 Jul '25

08 Jul '25

From: Tianyang Zhang <zhangtianyang(a)loongson.cn> stable inclusion from stable-v6.6.95 commit b427d98d55217b53c88643579fbbd8a4c351a105 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICK4OF CVE: CVE-2025-38195 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ee084fa96123ede8b0563a1b5a9b23adc43cd50d upstream. ERROR INFO: CPU 25 Unable to handle kernel paging request at virtual address 0x0 ... Call Trace: [<900000000023c30c>] huge_pte_offset+0x3c/0x58 [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438 [<900000000051fee8>] __get_user_pages+0xe0/0x4c8 [<9000000000522414>] faultin_page_range+0x84/0x380 [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48 [<900000000056689c>] do_madvise+0x1bc/0x3e8 [<9000000000566df4>] sys_madvise+0x24/0x38 [<90000000015b9e88>] do_syscall+0x78/0x98 [<9000000000221f18>] handle_syscall+0xb8/0x158 In some cases, pmd may be NULL and rely on NULL as the return value for processing, so it is necessary to determine this situation here. Cc: stable(a)vger.kernel.org Fixes: bd51834d1cf6 ("LoongArch: Return NULL from huge_pte_offset() for invalid PMD") Signed-off-by: Tianyang Zhang <zhangtianyang(a)loongson.cn> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- arch/loongarch/mm/hugetlbpage.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/loongarch/mm/hugetlbpage.c b/arch/loongarch/mm/hugetlbpage.c index aca52c42e94e..fb09fb70661e 100644 --- a/arch/loongarch/mm/hugetlbpage.c +++ b/arch/loongarch/mm/hugetlbpage.c @@ -47,7 +47,8 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, pmd = pmd_offset(pud, addr); } } - return pmd_none(pmdp_get(pmd)) ? NULL : (pte_t *) pmd; + + return (!pmd || pmd_none(pmdp_get(pmd))) ? NULL : (pte_t *) pmd; } int pmd_huge(pmd_t pmd) -- 2.34.1

2 1

[PATCH OLK-6.6] fbcon: Make sure modelist not set on unregistered console
by Yifan Qiao 08 Jul '25

08 Jul '25

From: Kees Cook <kees(a)kernel.org> stable inclusion from stable-v6.6.95 commit 519ba75728ee8cd561dce25fc52a2ec5c47171dc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICK4O9 CVE: CVE-2025-38198 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit cedc1b63394a866bf8663a3e40f4546f1d28c8d8 ] It looks like attempting to write to the "store_modes" sysfs node will run afoul of unregistered consoles: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing "info" pointers, so error handling should kick in correctly. Reported-by: syzbot+a7d4444e7b6e743572f7(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/679d0a8f.050a0220.163cdc.000c.GAE@google.com/ Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- drivers/video/fbdev/core/fbcon.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 405d587450ef..b46719b95a8a 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -115,9 +115,14 @@ static signed char con2fb_map_boot[MAX_NR_CONSOLES]; static struct fb_info *fbcon_info_from_console(int console) { + signed char fb; WARN_CONSOLE_UNLOCKED(); - return fbcon_registered_fb[con2fb_map[console]]; + fb = con2fb_map[console]; + if (fb < 0 || fb >= ARRAY_SIZE(fbcon_registered_fb)) + return NULL; + + return fbcon_registered_fb[fb]; } static int logo_lines; -- 2.39.2

2 1