GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
oesa-2025-1113
Vulnerability from osv_openeuler
Published
2025-02-14 11:08
Modified
2026-08-06 11:08
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

pinmux: Use sequential access to access desc->pinmux data

When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner.

Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer.

Serialize the access to mux related setting with a mutex lock.

cpu0 (process A)            cpu1(process B)

pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) {

     if (desc->mux_usecount > 1)
           return 0;
     desc->mux_owner = owner;

} }(CVE-2024-47141)

In the Linux kernel, the following vulnerability has been resolved:

net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg

When receiving proposal msg in server, the field iparea_offset and the field ipv6_prefixes_cnt in proposal msg are from the remote client and can not be fully trusted. Especially the field iparea_offset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks iparea_offset and ipv6_prefixes_cnt before using them.(CVE-2024-49571)

In the Linux kernel, the following vulnerability has been resolved:

spi: mpc52xx: Add cancel_work_sync before module remove

If we remove the module which will call mpc52xx_spi_remove it will free 'ms' through spi_unregister_controller. while the work ms->work will be used. The sequence of operations that may lead to a UAF bug.

Fix it by ensuring that the work is canceled before proceeding with the cleanup in mpc52xx_spi_remove.(CVE-2024-50051)

In the Linux kernel, the following vulnerability has been resolved:

usb: typec: fix potential array underflow in ucsi_ccg_sync_control()

The "command" variable can be controlled by the user via debugfs. The worry is that if con_index is zero then "&uc->ucsi->connector[con_index - 1]" would be an array underflow.(CVE-2024-53203)

In the Linux kernel, the following vulnerability has been resolved:

zram: fix NULL pointer in comp_algorithm_show()

LTP reported a NULL pointer dereference as followed:

CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_strcmp+0x24/0x140 lr : zcomp_available_show+0x60/0x100 [zram] sp : ffff800088b93b90 x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0 x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000 x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280 x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000 Call trace: __pi_strcmp+0x24/0x140 comp_algorithm_show+0x40/0x70 [zram] dev_attr_show+0x28/0x80 sysfs_kf_seq_show+0x90/0x140 kernfs_seq_show+0x34/0x48 seq_read_iter+0x1d4/0x4e8 kernfs_fop_read_iter+0x40/0x58 new_sync_read+0x9c/0x168 vfs_read+0x1a8/0x1f8 ksys_read+0x74/0x108 __arm64_sys_read+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x38/0x138 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188/0x190

The zram->comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if comp_algorithm_set() has not been called. User can access the zram device by sysfs after device_add_disk(), so there is a time window to trigger the NULL pointer dereference. Move it ahead device_add_disk() to make sure when user can access the zram device, it is ready. comp_algorithm_set() is protected by zram->init_lock in other places and no such problem.(CVE-2024-53222)

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: prevent use of deleted inode

syzbot reported a WARNING in nilfs_rmdir. [1]

Because the inode bitmap is corrupted, an inode with an inode number that should exist as a ".nilfs" file was reassigned by nilfs_mkdir for "file0", causing an inode duplication during execution. And this causes an underflow of i_nlink in rmdir operations.

The inode is used twice by the same task to unmount and remove directories ".nilfs" and "file0", it trigger warning in nilfs_rmdir.

Avoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it means that this inode has been deleted, and iput is executed to reclaim it.

[1] WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407 ... Call Trace: <TASK> nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342 vfs_rmdir+0x3a3/0x510 fs/namei.c:4394 do_rmdir+0x3b5/0x580 fs/namei.c:4453 __do_sys_rmdir fs/namei.c:4472 [inline] __se_sys_rmdir fs/namei.c:4470 [inline] __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53690)

In the Linux kernel, the following vulnerability has been resolved:

drm: adv7511: Fix use-after-free in adv7533_attach_dsi()

The host_node pointer was assigned and freed in adv7533_parse_dt(), and later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue by dropping of_node_put() in adv7533_parse_dt() and calling of_node_put() in error path of probe() and also in the remove().(CVE-2024-57887)

In the Linux kernel, the following vulnerability has been resolved:

ALSA: seq: oss: Fix races at processing SysEx messages

OSS sequencer handles the SysEx messages split in 6 bytes packets, and ALSA sequencer OSS layer tries to combine those. It stores the data in the internal buffer and this access is racy as of now, which may lead to the out-of-bounds access.

As a temporary band-aid fix, introduce a mutex for serializing the process of the SysEx message packets.(CVE-2024-57893)

In the Linux kernel, the following vulnerability has been resolved:

iio: light: vcnl4035: fix information leak in triggered buffer

The 'buffer' local array is used to push data to userspace from a triggered buffer, but it does not set an initial value for the single data element, which is an u16 aligned to 8 bytes. That leaves at least 4 bytes uninitialized even after writing an integer value with regmap_read().

Initialize the array to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57910)

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-249.0.0.151.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-249.0.0.151.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-249.0.0.151.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-249.0.0.151.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\u00a0dropping 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)",
  "id": "OESA-2025-1113",
  "modified": "2026-08-06T11:08:12Z",
  "published": "2025-02-14T11:08:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1113"
    },
    {
      "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "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"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.