- Kernel - mailweb.openeuler.org

[openeuler:OLK-6.6 1693/1693] drivers/gpu/drm/loongson/ast_old/ast_mode.c:746:19: sparse: sparse: cast removes address space '__iomem' of expression
by kernel test robot 03 Jan '25

03 Jan '25

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: c2f1662c3fb301fe7ba127fe06c14538112982d4 commit: 2815e6db6a7a2f0759dfc574e28b3b807a1a3377 [1693/1693] drm/loongson: use old version of ast driver for LoongArch platform config: loongarch-randconfig-r112-20250103 (https://download.01.org/0day-ci/archive/20250103/202501031239.NY9f5zcm-lkp@…) compiler: loongarch64-linux-gcc (GCC) 14.2.0 reproduce: (https://download.01.org/0day-ci/archive/20250103/202501031239.NY9f5zcm-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202501031239.NY9f5zcm-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/loongson/ast_old/ast_mode.c:746:19: sparse: sparse: cast removes address space '__iomem' of expression >> drivers/gpu/drm/loongson/ast_old/ast_mode.c:746:16: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected unsigned char [noderef] [usertype] __iomem *dstxor @@ got unsigned char [usertype] * @@ drivers/gpu/drm/loongson/ast_old/ast_mode.c:746:16: sparse: expected unsigned char [noderef] [usertype] __iomem *dstxor drivers/gpu/drm/loongson/ast_old/ast_mode.c:746:16: sparse: got unsigned char [usertype] * drivers/gpu/drm/loongson/ast_old/ast_mode.c: note: in included file (through arch/loongarch/include/asm/cpu-info.h, arch/loongarch/include/asm/processor.h, ...): arch/loongarch/include/asm/loongarch.h:1136:16: sparse: sparse: undefined identifier '__builtin_loongarch_csrrd_w' vim +/__iomem +746 drivers/gpu/drm/loongson/ast_old/ast_mode.c 719 720 /* 721 * Cursor plane 722 */ 723 724 static void ast_update_cursor_image(u8 __iomem *dst, const u8 *src, int width, 725 int height) 726 { 727 union { 728 u32 ul; 729 u8 b[4]; 730 } srcdata32[2], data32; 731 union { 732 u16 us; 733 u8 b[2]; 734 } data16; 735 u32 csum = 0; 736 s32 alpha_dst_delta, last_alpha_dst_delta; 737 u8 __iomem *dstxor; 738 const u8 *srcxor; 739 int i, j; 740 u32 per_pixel_copy, two_pixel_copy; 741 742 alpha_dst_delta = AST_MAX_HWC_WIDTH << 1; 743 last_alpha_dst_delta = alpha_dst_delta - (width << 1); 744 745 srcxor = src; > 746 dstxor = (u8 *)dst + last_alpha_dst_delta + 747 (AST_MAX_HWC_HEIGHT - height) * alpha_dst_delta; 748 per_pixel_copy = width & 1; 749 two_pixel_copy = width >> 1; 750 751 for (j = 0; j < height; j++) { 752 for (i = 0; i < two_pixel_copy; i++) { 753 srcdata32[0].ul = *((u32 *)srcxor) & 0xf0f0f0f0; 754 srcdata32[1].ul = *((u32 *)(srcxor + 4)) & 0xf0f0f0f0; 755 data32.b[0] = srcdata32[0].b[1] | 756 (srcdata32[0].b[0] >> 4); 757 data32.b[1] = srcdata32[0].b[3] | 758 (srcdata32[0].b[2] >> 4); 759 data32.b[2] = srcdata32[1].b[1] | 760 (srcdata32[1].b[0] >> 4); 761 data32.b[3] = srcdata32[1].b[3] | 762 (srcdata32[1].b[2] >> 4); 763 764 writel(data32.ul, dstxor); 765 csum += data32.ul; 766 767 dstxor += 4; 768 srcxor += 8; 769 } 770 771 for (i = 0; i < per_pixel_copy; i++) { 772 srcdata32[0].ul = *((u32 *)srcxor) & 0xf0f0f0f0; 773 data16.b[0] = srcdata32[0].b[1] | 774 (srcdata32[0].b[0] >> 4); 775 data16.b[1] = srcdata32[0].b[3] | 776 (srcdata32[0].b[2] >> 4); 777 writew(data16.us, dstxor); 778 csum += (u32)data16.us; 779 780 dstxor += 2; 781 srcxor += 4; 782 } 783 dstxor += last_alpha_dst_delta; 784 } 785 786 /* write checksum + signature */ 787 dst += AST_HWC_SIZE; 788 writel(csum, dst); 789 writel(width, dst + AST_HWC_SIGNATURE_SizeX); 790 writel(height, dst + AST_HWC_SIGNATURE_SizeY); 791 writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTX); 792 writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTY); 793 } 794 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1] usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer
by Liu Mingrui 03 Jan '25

03 Jan '25

From: Lianqin Hu <hulianqin(a)vivo.com> stable inclusion from stable-v5.10.232 commit 28b3c03a6790de1f6f2683919ad657840f0f0f58 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAO8 CVE: CVE-2024-56670 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4cfbca86f6a8b801f3254e0e3c8f2b1d2d64be2b upstream. Considering that in some extreme cases, when u_serial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gs_open, Thread B is executing the disconnect operation and calling the gserial_disconnect function,The port->port_usb pointer will be set to NULL. E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Crash This causes thread A to access a null pointer (port->port_usb is null) when calling the gs_free_requests function, causing a crash. If port_usb is NULL, the release request will be skipped as it will be done by gserial_disconnect. So add a null pointer check to gs_start_io before attempting to access the value of the pointer port->port_usb. Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68 Fixes: c1dca562be8a ("usb gadget: split out serial core") Cc: stable(a)vger.kernel.org Suggested-by: Prashanth K <quic_prashk(a)quicinc.com> Signed-off-by: Lianqin Hu <hulianqin(a)vivo.com> Acked-by: Prashanth K <quic_prashk(a)quicinc.com> Link: https://lore.kernel.org/r/TYUPR06MB62178DC3473F9E1A537DCD02D2362@TYUPR06MB6… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/usb/gadget/function/u_serial.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c index 2caccbb6e014..b3cb3bef06d2 100644 --- a/drivers/usb/gadget/function/u_serial.c +++ b/drivers/usb/gadget/function/u_serial.c @@ -569,9 +569,12 @@ static int gs_start_io(struct gs_port *port) * we didn't in gs_start_tx() */ tty_wakeup(port->port.tty); } else { - gs_free_requests(ep, head, &port->read_allocated); - gs_free_requests(port->port_usb->in, &port->write_pool, - &port->write_allocated); + /* Free reqs only if we are still connected */ + if (port->port_usb) { + gs_free_requests(ep, head, &port->read_allocated); + gs_free_requests(port->port_usb->in, &port->write_pool, + &port->write_allocated); + } status = -EIO; } -- 2.25.1

2 8

[PATCH OLK-5.10] usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer
by Liu Mingrui 03 Jan '25

03 Jan '25

From: Lianqin Hu <hulianqin(a)vivo.com> stable inclusion from stable-v5.10.232 commit 28b3c03a6790de1f6f2683919ad657840f0f0f58 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAO8 CVE: CVE-2024-56670 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4cfbca86f6a8b801f3254e0e3c8f2b1d2d64be2b upstream. Considering that in some extreme cases, when u_serial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gs_open, Thread B is executing the disconnect operation and calling the gserial_disconnect function,The port->port_usb pointer will be set to NULL. E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Crash This causes thread A to access a null pointer (port->port_usb is null) when calling the gs_free_requests function, causing a crash. If port_usb is NULL, the release request will be skipped as it will be done by gserial_disconnect. So add a null pointer check to gs_start_io before attempting to access the value of the pointer port->port_usb. Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68 Fixes: c1dca562be8a ("usb gadget: split out serial core") Cc: stable(a)vger.kernel.org Suggested-by: Prashanth K <quic_prashk(a)quicinc.com> Signed-off-by: Lianqin Hu <hulianqin(a)vivo.com> Acked-by: Prashanth K <quic_prashk(a)quicinc.com> Link: https://lore.kernel.org/r/TYUPR06MB62178DC3473F9E1A537DCD02D2362@TYUPR06MB6… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/usb/gadget/function/u_serial.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c index 2caccbb6e014..b3cb3bef06d2 100644 --- a/drivers/usb/gadget/function/u_serial.c +++ b/drivers/usb/gadget/function/u_serial.c @@ -569,9 +569,12 @@ static int gs_start_io(struct gs_port *port) * we didn't in gs_start_tx() */ tty_wakeup(port->port.tty); } else { - gs_free_requests(ep, head, &port->read_allocated); - gs_free_requests(port->port_usb->in, &port->write_pool, - &port->write_allocated); + /* Free reqs only if we are still connected */ + if (port->port_usb) { + gs_free_requests(ep, head, &port->read_allocated); + gs_free_requests(port->port_usb->in, &port->write_pool, + &port->write_allocated); + } status = -EIO; } -- 2.25.1

2 9

[PATCH OLK-6.6] usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer
by Liu Mingrui 03 Jan '25

03 Jan '25

From: Lianqin Hu <hulianqin(a)vivo.com> stable inclusion from stable-v6.6.67 commit 8ca07a3d18f39b1669927ef536e485787e856df6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAO8 CVE: CVE-2024-56670 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4cfbca86f6a8b801f3254e0e3c8f2b1d2d64be2b upstream. Considering that in some extreme cases, when u_serial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gs_open, Thread B is executing the disconnect operation and calling the gserial_disconnect function,The port->port_usb pointer will be set to NULL. E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Crash This causes thread A to access a null pointer (port->port_usb is null) when calling the gs_free_requests function, causing a crash. If port_usb is NULL, the release request will be skipped as it will be done by gserial_disconnect. So add a null pointer check to gs_start_io before attempting to access the value of the pointer port->port_usb. Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68 Fixes: c1dca562be8a ("usb gadget: split out serial core") Cc: stable(a)vger.kernel.org Suggested-by: Prashanth K <quic_prashk(a)quicinc.com> Signed-off-by: Lianqin Hu <hulianqin(a)vivo.com> Acked-by: Prashanth K <quic_prashk(a)quicinc.com> Link: https://lore.kernel.org/r/TYUPR06MB62178DC3473F9E1A537DCD02D2362@TYUPR06MB6… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/usb/gadget/function/u_serial.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c index 8962f96ae729..729b0472bab0 100644 --- a/drivers/usb/gadget/function/u_serial.c +++ b/drivers/usb/gadget/function/u_serial.c @@ -575,9 +575,12 @@ static int gs_start_io(struct gs_port *port) * we didn't in gs_start_tx() */ tty_wakeup(port->port.tty); } else { - gs_free_requests(ep, head, &port->read_allocated); - gs_free_requests(port->port_usb->in, &port->write_pool, - &port->write_allocated); + /* Free reqs only if we are still connected */ + if (port->port_usb) { + gs_free_requests(ep, head, &port->read_allocated); + gs_free_requests(port->port_usb->in, &port->write_pool, + &port->write_allocated); + } status = -EIO; } -- 2.25.1

2 9

[PATCH openEuler-1.0-LTS] selinux: ignore unknown extended permissions
by Gu Bowen 03 Jan '25

03 Jan '25

From: Thiébaud Weksteen <tweek(a)google.com> mainline inclusion from mainline-v6.13-rc4 commit 900f83cf376bdaf798b6f5dcb2eae0c822e908b6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEUBD Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels. Cc: stable(a)vger.kernel.org Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls") Signed-off-by: Thiébaud Weksteen <tweek(a)google.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> Conflicts: security/selinux/ss/services.c [Due to commit d1d991efaf346 ("selinux: Add netlink xperm support") add a new policy and refactored the function, there are context conflicts happened.] Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- security/selinux/ss/services.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c index a1ea7d90ce4f..83b499980041 100644 --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -965,7 +965,10 @@ void services_compute_xperms_decision(struct extended_perms_decision *xpermd, xpermd->driver)) return; } else { - BUG(); + pr_warn_once( + "SELinux: unknown extended permission (%u) will be ignored\n", + node->datum.u.xperms->specified); + return; } if (node->key.specified == AVTAB_XPERMS_ALLOWED) { @@ -1002,7 +1005,8 @@ void services_compute_xperms_decision(struct extended_perms_decision *xpermd, node->datum.u.xperms->perms.p[i]; } } else { - BUG(); + pr_warn_once("SELinux: unknown specified key (%u)\n", + node->key.specified); } } -- 2.25.1

2 1

[PATCH OLK-6.6] net: usb: lan78xx: Fix double free issue with interrupt buffer allocation
by Zicheng Qu 03 Jan '25

03 Jan '25

From: Oleksij Rempel <o.rempel(a)pengutronix.de> stable inclusion from stable-v6.6.64 commit a422ebec863d99d5607fb41bb7af3347fcb436d3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAEY CVE: CVE-2024-53213 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 03819abbeb11117dcbba40bfe322b88c0c88a6b6 ] In lan78xx_probe(), the buffer `buf` was being freed twice: once implicitly through `usb_free_urb(dev->urb_intr)` with the `URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This caused a double free issue. To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls to simplify the initialization sequence and removed the redundant `kfree(buf)`. Now, `buf` is allocated after `usb_alloc_urb()`, ensuring it is correctly managed by `usb_fill_int_urb()` and freed by `usb_free_urb()` as intended. Fixes: a6df95cae40b ("lan78xx: Fix memory allocation bug") Cc: John Efstathiades <john.efstathiades(a)pebblebay.com> Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Link: https://patch.msgid.link/20241116130558.1352230-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- drivers/net/usb/lan78xx.c | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c index 921ae046f860..2ae33ecb6749 100644 --- a/drivers/net/usb/lan78xx.c +++ b/drivers/net/usb/lan78xx.c @@ -4414,29 +4414,30 @@ static int lan78xx_probe(struct usb_interface *intf, period = ep_intr->desc.bInterval; maxp = usb_maxpacket(dev->udev, dev->pipe_intr); - buf = kmalloc(maxp, GFP_KERNEL); - if (!buf) { + + dev->urb_intr = usb_alloc_urb(0, GFP_KERNEL); + if (!dev->urb_intr) { ret = -ENOMEM; goto out5; } - dev->urb_intr = usb_alloc_urb(0, GFP_KERNEL); - if (!dev->urb_intr) { + buf = kmalloc(maxp, GFP_KERNEL); + if (!buf) { ret = -ENOMEM; - goto out6; - } else { - usb_fill_int_urb(dev->urb_intr, dev->udev, - dev->pipe_intr, buf, maxp, - intr_complete, dev, period); - dev->urb_intr->transfer_flags |= URB_FREE_BUFFER; + goto free_urbs; } + usb_fill_int_urb(dev->urb_intr, dev->udev, + dev->pipe_intr, buf, maxp, + intr_complete, dev, period); + dev->urb_intr->transfer_flags |= URB_FREE_BUFFER; + dev->maxpacket = usb_maxpacket(dev->udev, dev->pipe_out); /* Reject broken descriptors. */ if (dev->maxpacket == 0) { ret = -ENODEV; - goto out6; + goto free_urbs; } /* driver requires remote-wakeup capability during autosuspend. */ @@ -4444,7 +4445,7 @@ static int lan78xx_probe(struct usb_interface *intf, ret = lan78xx_phy_init(dev); if (ret < 0) - goto out7; + goto free_urbs; ret = register_netdev(netdev); if (ret != 0) { @@ -4466,10 +4467,8 @@ static int lan78xx_probe(struct usb_interface *intf, out8: phy_disconnect(netdev->phydev); -out7: +free_urbs: usb_free_urb(dev->urb_intr); -out6: - kfree(buf); out5: lan78xx_unbind(dev, intf); out4: -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] media: wl128x: Fix atomicity violation in fmc_send_cmd()
by dinglongwei 03 Jan '25

03 Jan '25

From: Qiu-ji Chen <chenqiuji666(a)gmail.com> stable inclusion from stable-v4.19.325 commit d16109c9fdc1b8cea4fe63b42e06e926c3f68990 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDOW CVE: CVE-2024-56700 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ca59f9956d4519ab18ab2270be47c6b8c6ced091 upstream. Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/media/radio/wl128x/fmdrv_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/radio/wl128x/fmdrv_common.c b/drivers/media/radio/wl128x/fmdrv_common.c index 1cf4019689a5..8b8453dab660 100644 --- a/drivers/media/radio/wl128x/fmdrv_common.c +++ b/drivers/media/radio/wl128x/fmdrv_common.c @@ -472,11 +472,12 @@ int fmc_send_cmd(struct fmdev *fmdev, u8 fm_op, u16 type, void *payload, jiffies_to_msecs(FM_DRV_TX_TIMEOUT) / 1000); return -ETIMEDOUT; } + spin_lock_irqsave(&fmdev->resp_skb_lock, flags); if (!fmdev->resp_skb) { + spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); fmerr("Response SKB is missing\n"); return -EFAULT; } - spin_lock_irqsave(&fmdev->resp_skb_lock, flags); skb = fmdev->resp_skb; fmdev->resp_skb = NULL; spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); -- 2.22.0

2 2

[PATCH openEuler-22.03-LTS-SP1] media: wl128x: Fix atomicity violation in fmc_send_cmd()
by dinglongwei 03 Jan '25

03 Jan '25

From: Qiu-ji Chen <chenqiuji666(a)gmail.com> stable inclusion from stable-v5.10.231 commit d7408a052aa1b4f6fb6f1c7a8877b84017a07ac9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDOW CVE: CVE-2024-56700 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ca59f9956d4519ab18ab2270be47c6b8c6ced091 upstream. Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/media/radio/wl128x/fmdrv_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/radio/wl128x/fmdrv_common.c b/drivers/media/radio/wl128x/fmdrv_common.c index 6142484d5cb4..d9287a935a9e 100644 --- a/drivers/media/radio/wl128x/fmdrv_common.c +++ b/drivers/media/radio/wl128x/fmdrv_common.c @@ -465,11 +465,12 @@ int fmc_send_cmd(struct fmdev *fmdev, u8 fm_op, u16 type, void *payload, jiffies_to_msecs(FM_DRV_TX_TIMEOUT) / 1000); return -ETIMEDOUT; } + spin_lock_irqsave(&fmdev->resp_skb_lock, flags); if (!fmdev->resp_skb) { + spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); fmerr("Response SKB is missing\n"); return -EFAULT; } - spin_lock_irqsave(&fmdev->resp_skb_lock, flags); skb = fmdev->resp_skb; fmdev->resp_skb = NULL; spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); -- 2.22.0

2 2

[PATCH OLK-5.10] media: wl128x: Fix atomicity violation in fmc_send_cmd()
by dinglongwei 03 Jan '25

03 Jan '25

From: Qiu-ji Chen <chenqiuji666(a)gmail.com> stable inclusion from stable-v5.10.231 commit d7408a052aa1b4f6fb6f1c7a8877b84017a07ac9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDOW CVE: CVE-2024-56700 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ca59f9956d4519ab18ab2270be47c6b8c6ced091 upstream. Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/media/radio/wl128x/fmdrv_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/radio/wl128x/fmdrv_common.c b/drivers/media/radio/wl128x/fmdrv_common.c index 6142484d5cb4..d9287a935a9e 100644 --- a/drivers/media/radio/wl128x/fmdrv_common.c +++ b/drivers/media/radio/wl128x/fmdrv_common.c @@ -465,11 +465,12 @@ int fmc_send_cmd(struct fmdev *fmdev, u8 fm_op, u16 type, void *payload, jiffies_to_msecs(FM_DRV_TX_TIMEOUT) / 1000); return -ETIMEDOUT; } + spin_lock_irqsave(&fmdev->resp_skb_lock, flags); if (!fmdev->resp_skb) { + spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); fmerr("Response SKB is missing\n"); return -EFAULT; } - spin_lock_irqsave(&fmdev->resp_skb_lock, flags); skb = fmdev->resp_skb; fmdev->resp_skb = NULL; spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); -- 2.22.0

2 2

[PATCH OLK-6.6] media: wl128x: Fix atomicity violation in fmc_send_cmd()
by dinglongwei 03 Jan '25

03 Jan '25

From: Qiu-ji Chen <chenqiuji666(a)gmail.com> stable inclusion from stable-v6.6.64 commit 378ce4e08ca2b1ac7bbf1d57b68643ca4226c5f8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDOW CVE: CVE-2024-56700 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ca59f9956d4519ab18ab2270be47c6b8c6ced091 upstream. Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/media/radio/wl128x/fmdrv_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/radio/wl128x/fmdrv_common.c b/drivers/media/radio/wl128x/fmdrv_common.c index 3da8e5102bec..1225dab9fc7d 100644 --- a/drivers/media/radio/wl128x/fmdrv_common.c +++ b/drivers/media/radio/wl128x/fmdrv_common.c @@ -466,11 +466,12 @@ int fmc_send_cmd(struct fmdev *fmdev, u8 fm_op, u16 type, void *payload, jiffies_to_msecs(FM_DRV_TX_TIMEOUT) / 1000); return -ETIMEDOUT; } + spin_lock_irqsave(&fmdev->resp_skb_lock, flags); if (!fmdev->resp_skb) { + spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); fmerr("Response SKB is missing\n"); return -EFAULT; } - spin_lock_irqsave(&fmdev->resp_skb_lock, flags); skb = fmdev->resp_skb; fmdev->resp_skb = NULL; spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); -- 2.22.0

2 3

2025

2024

2023

2022

2021

2020

2019

Kernel