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

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel's JSM serial driver, a resource leak vulnerability exists in the probe function. The error path needs to properly unwind instead of just returning directly, which may lead to resource leakage issues.(CVE-2022-50312)

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

rapidio: fix possible name leaks when rio_add_device() fails

Patch series "rapidio: fix three possible memory leaks".

This patchset fixes three name leaks in error handling. - patch #1 fixes two name leaks while rio_add_device() fails. - patch #2 fixes a name leak while rio_register_mport() fails.

This patch (of 2):

If rio_add_device() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and the 'rdev' can be freed in rio_release_dev().(CVE-2022-50343)

In the Linux kernel, there is a memory leak vulnerability in the tpm_crb driver. In the crb_acpi_add() function, after obtaining the TPM2 table to retrieve information such as startup methods and assigning them to private data, the TPM2 table is no longer used after initialization is completed, but is not released correctly, resulting in memory leaks.(CVE-2022-50389)

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

ext4: avoid deadlock in fs reclaim with page writeback

Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like:

CPU0 CPU1

ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever

Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.(CVE-2023-53149)

In the Linux kernel, a NULL pointer dereference vulnerability has been resolved. If ipi_send_mask() or ipi_send_single() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does not verify its 'data' parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-53332)

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

net: bridge: fix soft lockup in br_multicast_query_expired()

When set multicast_query_interval to a large value, the local variable 'time' in br_multicast_send_query() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call mod_timer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up

The multicast_startup_query_interval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.(CVE-2025-39773)

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

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2509.6.0.0345.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2509.6.0.0345.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2509.6.0.0345.oe2003sp4"
            }
          ],
          "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\u0026apos;s JSM serial driver, a resource leak vulnerability exists in the probe function. The error path needs to properly unwind instead of just returning directly, which may lead to resource leakage issues.(CVE-2022-50312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrapidio: fix possible name leaks when rio_add_device() fails\n\nPatch series \u0026quot;rapidio: fix three possible memory leaks\u0026quot;.\n\nThis patchset fixes three name leaks in error handling.\n - patch #1 fixes two name leaks while rio_add_device() fails.\n - patch #2 fixes a name leak while  rio_register_mport() fails.\n\n\nThis patch (of 2):\n\nIf rio_add_device() returns error, the name allocated by dev_set_name()\nneed be freed.  It should use put_device() to give up the reference in the\nerror path, so that the name can be freed in kobject_cleanup(), and the\n\u0026apos;rdev\u0026apos; can be freed in rio_release_dev().(CVE-2022-50343)\n\nIn the Linux kernel, there is a memory leak vulnerability in the tpm_crb driver. In the crb_acpi_add() function, after obtaining the TPM2 table to retrieve information such as startup methods and assigning them to private data, the TPM2 table is no longer used after initialization is completed, but is not released correctly, resulting in memory leaks.(CVE-2022-50389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid deadlock in fs reclaim with page writeback\n\nExt4 has a filesystem wide lock protecting ext4_writepages() calls to\navoid races with switching of journalled data flag or inode format. This\nlock can however cause a deadlock like:\n\nCPU0                            CPU1\n\next4_writepages()\n  percpu_down_read(sbi-\u0026gt;s_writepages_rwsem);\n                                ext4_change_inode_journal_flag()\n                                  percpu_down_write(sbi-\u0026gt;s_writepages_rwsem);\n                                    - blocks, all readers block from now on\n  ext4_do_writepages()\n    ext4_init_io_end()\n      kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)\n        fs_reclaim frees dentry...\n          dentry_unlink_inode()\n            iput() - last ref =\u0026gt;\n              iput_final() - inode dirty =\u0026gt;\n                write_inode_now()...\n                  ext4_writepages() tries to acquire sbi-\u0026gt;s_writepages_rwsem\n                    and blocks forever\n\nMake sure we cannot recurse into filesystem reclaim from writeback code\nto avoid the deadlock.(CVE-2023-53149)\n\nIn the Linux kernel, a NULL pointer dereference vulnerability has been resolved. If ipi_send_mask() or ipi_send_single() is called with an invalid interrupt number, all the local variables there will be NULL. ipi_send_verify() which is invoked from these functions does not verify its \u0026apos;data\u0026apos; parameter, resulting in a kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets dereferenced. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-53332)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix soft lockup in br_multicast_query_expired()\n\nWhen set multicast_query_interval to a large value, the local variable\n\u0026apos;time\u0026apos; in br_multicast_send_query() may overflow. If the time is smaller\nthan jiffies, the timer will expire immediately, and then call mod_timer()\nagain, which creates a loop and may trigger the following soft lockup\nissue.\n\n  watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]\n  CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)\n  Call Trace:\n   \u0026lt;IRQ\u0026gt;\n   __netdev_alloc_skb+0x2e/0x3a0\n   br_ip6_multicast_alloc_query+0x212/0x1b70\n   __br_multicast_send_query+0x376/0xac0\n   br_multicast_send_query+0x299/0x510\n   br_multicast_query_expired.constprop.0+0x16d/0x1b0\n   call_timer_fn+0x3b/0x2a0\n   __run_timers+0x619/0x950\n   run_timer_softirq+0x11c/0x220\n   handle_softirqs+0x18e/0x560\n   __irq_exit_rcu+0x158/0x1a0\n   sysvec_apic_timer_interrupt+0x76/0x90\n   \u0026lt;/IRQ\u0026gt;\n\nThis issue can be reproduced with:\n  ip link add br0 type bridge\n  echo 1 \u0026gt; /sys/class/net/br0/bridge/multicast_querier\n  echo 0xffffffffffffffff \u0026gt;\n  \t/sys/class/net/br0/bridge/multicast_query_interval\n  ip link set dev br0 up\n\nThe multicast_startup_query_interval can also cause this issue. Similar to\nthe commit 99b40610956a (\u0026quot;net: bridge: mcast: add and enforce query\ninterval minimum\u0026quot;), add check for the query interval maximum to fix this\nissue.(CVE-2025-39773)",
  "id": "OESA-2025-2348",
  "modified": "2026-08-06T11:09:25Z",
  "published": "2025-09-26T11:09:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2348"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50312"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50343"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50389"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53149"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53332"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39773"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-50312",
    "CVE-2022-50343",
    "CVE-2022-50389",
    "CVE-2023-53149",
    "CVE-2023-53332",
    "CVE-2025-39773"
  ]
}



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.