{"schema_version":"1.7.2","id":"OESA-2025-1114","modified":"2025-02-14T12:12:45Z","published":"2025-02-14T12:12:45Z","upstream":["CVE-2024-47141","CVE-2024-49571","CVE-2024-50051","CVE-2024-53203","CVE-2024-53222","CVE-2024-53690","CVE-2024-57887","CVE-2024-57893","CVE-2024-57910"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinmux: Use sequential access to access desc-\u0026gt;pinmux data\n\nWhen two client of the same gpio call pinctrl_select_state() for the\nsame functionality, we are seeing NULL pointer issue while accessing\ndesc-\u0026gt;mux_owner.\n\nLet\u0026apos;s say two processes A, B executing in pin_request() for the same pin\nand process A updates the desc-\u0026gt;mux_usecount but not yet updated the\ndesc-\u0026gt;mux_owner while process B see the desc-\u0026gt;mux_usecount which got\nupdated by A path and further executes strcmp and while accessing\ndesc-\u0026gt;mux_owner it crashes with NULL pointer.\n\nSerialize the access to mux related setting with a mutex lock.\n\n\tcpu0 (process A)\t\t\tcpu1(process B)\n\npinctrl_select_state() {\t\t  pinctrl_select_state() {\n  pin_request() {\t\t\t\tpin_request() {\n  ...\n\t\t\t\t\t\t ....\n    } else {\n         desc-\u0026gt;mux_usecount++;\n    \t\t\t\t\t\tdesc-\u0026gt;mux_usecount \u0026amp;\u0026amp; strcmp(desc-\u0026gt;mux_owner, owner)) {\n\n         if (desc-\u0026gt;mux_usecount \u0026gt; 1)\n               return 0;\n         desc-\u0026gt;mux_owner = owner;\n\n  }\t\t\t\t\t\t}(CVE-2024-47141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg\n\nWhen receiving proposal msg in server, the field iparea_offset\nand the field ipv6_prefixes_cnt in proposal msg are from the\nremote client and can not be fully trusted. Especially the\nfield iparea_offset, once exceed the max value, there has the\nchance to access wrong address, and crash may happen.\n\nThis patch checks iparea_offset and ipv6_prefixes_cnt before using them.(CVE-2024-49571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: mpc52xx: Add cancel_work_sync before module remove\n\nIf we remove the module which will call mpc52xx_spi_remove\nit will free \u0026apos;ms\u0026apos; through spi_unregister_controller.\nwhile the work ms-\u0026gt;work will be used. The sequence of operations\nthat may lead to a UAF bug.\n\nFix it by ensuring that the work is canceled before proceeding with\nthe cleanup in mpc52xx_spi_remove.(CVE-2024-50051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: fix potential array underflow in ucsi_ccg_sync_control()\n\nThe \u0026quot;command\u0026quot; variable can be controlled by the user via debugfs.  The\nworry is that if con_index is zero then \u0026quot;\u0026amp;uc-\u0026gt;ucsi-\u0026gt;connector[con_index\n- 1]\u0026quot; would be an array underflow.(CVE-2024-53203)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nzram: fix NULL pointer in comp_algorithm_show()\n\nLTP reported a NULL pointer dereference as followed:\n\n CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __pi_strcmp+0x24/0x140\n lr : zcomp_available_show+0x60/0x100 [zram]\n sp : ffff800088b93b90\n x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0\n x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000\n x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900\n x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280\n x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c\n x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000\n Call trace:\n  __pi_strcmp+0x24/0x140\n  comp_algorithm_show+0x40/0x70 [zram]\n  dev_attr_show+0x28/0x80\n  sysfs_kf_seq_show+0x90/0x140\n  kernfs_seq_show+0x34/0x48\n  seq_read_iter+0x1d4/0x4e8\n  kernfs_fop_read_iter+0x40/0x58\n  new_sync_read+0x9c/0x168\n  vfs_read+0x1a8/0x1f8\n  ksys_read+0x74/0x108\n  __arm64_sys_read+0x24/0x38\n  invoke_syscall+0x50/0x120\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x38/0x138\n  el0t_64_sync_handler+0xc0/0xc8\n  el0t_64_sync+0x188/0x190\n\nThe zram-\u0026gt;comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if\ncomp_algorithm_set() has not been called.  User can access the zram device\nby sysfs after device_add_disk(), so there is a time window to trigger the\nNULL pointer dereference.  Move it ahead device_add_disk() to make sure\nwhen user can access the zram device, it is ready.  comp_algorithm_set()\nis protected by zram-\u0026gt;init_lock in other places and no such problem.(CVE-2024-53222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: prevent use of deleted inode\n\nsyzbot reported a WARNING in nilfs_rmdir. [1]\n\nBecause the inode bitmap is corrupted, an inode with an inode number that\nshould exist as a \u0026quot;.nilfs\u0026quot; file was reassigned by nilfs_mkdir for \u0026quot;file0\u0026quot;,\ncausing an inode duplication during execution.  And this causes an\nunderflow of i_nlink in rmdir operations.\n\nThe inode is used twice by the same task to unmount and remove directories\n\u0026quot;.nilfs\u0026quot; and \u0026quot;file0\u0026quot;, it trigger warning in nilfs_rmdir.\n\nAvoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it means\nthat this inode has been deleted, and iput is executed to reclaim it.\n\n[1]\nWARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342\n vfs_rmdir+0x3a3/0x510 fs/namei.c:4394\n do_rmdir+0x3b5/0x580 fs/namei.c:4453\n __do_sys_rmdir fs/namei.c:4472 [inline]\n __se_sys_rmdir fs/namei.c:4470 [inline]\n __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53690)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm: adv7511: Fix use-after-free in adv7533_attach_dsi()\n\nThe host_node pointer was assigned and freed in adv7533_parse_dt(), and\nlater, adv7533_attach_dsi() uses the same. Fix this use-after-free issue\nby dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()\nin error path of probe() and also in the remove().(CVE-2024-57887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: seq: oss: Fix races at processing SysEx messages\n\nOSS sequencer handles the SysEx messages split in 6 bytes packets, and\nALSA sequencer OSS layer tries to combine those.  It stores the data\nin the internal buffer and this access is racy as of now, which may\nlead to the out-of-bounds access.\n\nAs a temporary band-aid fix, introduce a mutex for serializing the\nprocess of the SysEx message packets.(CVE-2024-57893)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: light: vcnl4035: fix information leak in triggered buffer\n\nThe \u0026apos;buffer\u0026apos; local array is used to push data to userspace from a\ntriggered buffer, but it does not set an initial value for the single\ndata element, which is an u16 aligned to 8 bytes. That leaves at least\n4 bytes uninitialized even after writing an integer value with\nregmap_read().\n\nInitialize the array to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57910)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-249.0.0.152.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","kernel-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","perf-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-249.0.0.152.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","kernel-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","perf-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1114"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47141"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49571"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50051"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53203"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53222"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53690"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57887"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57893"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57910"}],"database_specific":{"severity":"High"}}