GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
oesa-2025-1928
Vulnerability from osv_openeuler
Published
2025-08-01 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, the following vulnerability has been resolved:

HID: ignore non-functional sensor in HP 5MP Camera

The HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor.

[453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff

Add this device to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-21992)

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

dmaengine: idxd: fix memory leak in error handling path of idxd_alloc

Memory allocated for idxd is not freed if an error occurs during idxd_alloc(). To fix it, free the allocated memory in the reverse order of allocation before exiting the function in case of an error.(CVE-2025-38015)

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

nvmet-tcp: don't restore null sk_state_change

queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if the TCP connection isn't established when nvmet_tcp_set_queue_sock() is called then queue->state_change isn't set and sock->sk->sk_state_change isn't replaced.

As such we don't need to restore sock->sk->sk_state_change if queue->state_change is NULL.

This avoids NULL pointer dereferences such as this:

[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode [ 286.463796][ C0] #PF: error_code(0x0010) - not-present page [ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0 [ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI [ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary) [ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 286.467147][ C0] RIP: 0010:0x0 [ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246 [ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43 [ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100 [ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c [ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3 [ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268 [ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000 [ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0 [ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 286.475453][ C0] Call Trace: [ 286.476102][ C0] <IRQ> [ 286.476719][ C0] tcp_fin+0x2bb/0x440 [ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60 [ 286.478174][ C0] ? __build_skb_around+0x234/0x330 [ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10 [ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0 [ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30 [ 286.482769][ C0] ? ktime_get+0x66/0x150 [ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050 [ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0 [ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10 [ 286.486917][ C0] ? lock_release+0x217/0x2c0 [ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0 [ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30 [ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0 [ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10 [ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10 [ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack] [ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370 [ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420 [ 286.494268][ C0] ip_local_deliver+0x168/0x430 [ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10 [ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20 [ 286.496806][ C0] ? lock_release+0x217/0x2c0 [ 286.497414][ C0] ip_rcv+0x455/0x6e0 [ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10 [ ---truncated---(CVE-2025-38035)

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

atm: Revert atm_account_tx() if copy_from_iter_full() fails.

In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc by atm_account_tx().

It is expected to be reverted by atm_pop_raw() later called by vcc->dev->ops->send(vcc, skb).

However, vcc_sendmsg() misses the same revert when copy_from_iter_full() fails, and then we will leak a socket.

Let's factorise the revert part as atm_return_tx() and call it in the failure path.

Note that the corresponding sk_wmem_alloc operation can be found in alloc_tx() as of the blamed commit.

$ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~(CVE-2025-38190)

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

fbcon: Make sure modelist not set on unregistered console

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.(CVE-2025-38198)

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

i40e: fix MMIO write access to an invalid page in i40e_clear_hw

When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page.

Prevent the integer underflow by changing the type of related variables.(CVE-2025-38200)

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

configfs-tsm-report: Fix NULL dereference of tsm_ops

Unlike sysfs, the lifetime of configfs objects is controlled by userspace. There is no mechanism for the kernel to find and delete all created config-items. Instead, the configfs-tsm-report mechanism has an expectation that tsm_unregister() can happen at any time and cause established config-item access to start failing.

That expectation is not fully satisfied. While tsm_report_read(), tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail if tsm_ops have been unregistered, tsm_report_privlevel_store() tsm_report_provider_show() fail to check for ops registration. Add the missing checks for tsm_ops having been removed.

Now, in supporting the ability for tsm_unregister() to always succeed, it leaves the problem of what to do with lingering config-items. The expectation is that the admin that arranges for the ->remove() (unbind) of the ${tsm_arch}-guest driver is also responsible for deletion of all open config-items. Until that deletion happens, ->probe() (reload / bind) of the ${tsm_arch}-guest driver fails.

This allows for emergency shutdown / revocation of attestation interfaces, and requires coordinated restart.(CVE-2025-38210)

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

nvme-tcp: sanitize request list handling

Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing.(CVE-2025-38264)

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

mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().

As syzbot reported [0], mpls_route_input_rcu() can be called from mpls_getroute(), where is under RTNL.

net->mpls.platform_label is only updated under RTNL.

Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() to silence the splat.

[0]: WARNING: suspicious RCU usage 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted

net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961

stack backtrace: CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] _syssendmsg+0xa98/0xc70 net/socket.c:2566 _sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969 RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268 </TASK>(CVE-2025-38324)

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

usb: typec: altmodes/displayport: do not index invalid pin_assignments

A poorly implemented DisplayPort Alt Mode port partner can indicate that its pin assignment capabilities are greater than the maximum value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show will cause a BRK exception due to an out of bounds array access.

Prevent for loop in pin_assignment_show from accessing invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop condition.(CVE-2025-38391)

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-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-debuginfo-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-debugsource-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-devel-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-extra-modules-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-headers-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-source-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-tools-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "kernel-tools-devel-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "perf-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "perf-debuginfo-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "python3-perf-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-103.0.0.109.oe2403sp2.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-103.0.0.109.oe2403sp2.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-debuginfo-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-debugsource-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-devel-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-extra-modules-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-headers-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-source-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-tools-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "kernel-tools-devel-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "perf-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "perf-debuginfo-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "python3-perf-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-103.0.0.109.oe2403sp2.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP2",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-103.0.0.109.oe2403sp2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\n\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: ignore non-functional sensor in HP 5MP Camera\n\nThe HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that\nis not actually implemented. Attempting to access this non-functional\nsensor via iio_info causes system hangs as runtime PM tries to wake up\nan unresponsive sensor.\n\n  [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff\n  [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff\n\nAdd this device to the HID ignore list since the sensor interface is\nnon-functional by design and should not be exposed to userspace.(CVE-2025-21992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: fix memory leak in error handling path of idxd_alloc\n\nMemory allocated for idxd is not freed if an error occurs during\nidxd_alloc(). To fix it, free the allocated memory in the reverse order\nof allocation before exiting the function in case of an error.(CVE-2025-38015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: don\u0026apos;t restore null sk_state_change\n\nqueue-\u0026gt;state_change is set as part of nvmet_tcp_set_queue_sock(), but if\nthe TCP connection isn\u0026apos;t established when nvmet_tcp_set_queue_sock() is\ncalled then queue-\u0026gt;state_change isn\u0026apos;t set and sock-\u0026gt;sk-\u0026gt;sk_state_change\nisn\u0026apos;t replaced.\n\nAs such we don\u0026apos;t need to restore sock-\u0026gt;sk-\u0026gt;sk_state_change if\nqueue-\u0026gt;state_change is NULL.\n\nThis avoids NULL pointer dereferences such as this:\n\n[  286.462026][    C0] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[  286.462814][    C0] #PF: supervisor instruction fetch in kernel mode\n[  286.463796][    C0] #PF: error_code(0x0010) - not-present page\n[  286.464392][    C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0\n[  286.465086][    C0] Oops: Oops: 0010 [#1] SMP KASAN PTI\n[  286.465559][    C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)\n[  286.466393][    C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014\n[  286.467147][    C0] RIP: 0010:0x0\n[  286.467420][    C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n[  286.467977][    C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246\n[  286.468425][    C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43\n[  286.469019][    C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100\n[  286.469545][    C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c\n[  286.470072][    C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3\n[  286.470585][    C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268\n[  286.471070][    C0] FS:  00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000\n[  286.471644][    C0] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  286.472543][    C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0\n[  286.473500][    C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  286.474467][    C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400\n[  286.475453][    C0] Call Trace:\n[  286.476102][    C0]  \u0026lt;IRQ\u0026gt;\n[  286.476719][    C0]  tcp_fin+0x2bb/0x440\n[  286.477429][    C0]  tcp_data_queue+0x190f/0x4e60\n[  286.478174][    C0]  ? __build_skb_around+0x234/0x330\n[  286.478940][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.479659][    C0]  ? __pfx_tcp_data_queue+0x10/0x10\n[  286.480431][    C0]  ? tcp_try_undo_loss+0x640/0x6c0\n[  286.481196][    C0]  ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90\n[  286.482046][    C0]  ? kvm_clock_get_cycles+0x14/0x30\n[  286.482769][    C0]  ? ktime_get+0x66/0x150\n[  286.483433][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.484146][    C0]  tcp_rcv_established+0x6e4/0x2050\n[  286.484857][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.485523][    C0]  ? ipv4_dst_check+0x160/0x2b0\n[  286.486203][    C0]  ? __pfx_tcp_rcv_established+0x10/0x10\n[  286.486917][    C0]  ? lock_release+0x217/0x2c0\n[  286.487595][    C0]  tcp_v4_do_rcv+0x4d6/0x9b0\n[  286.488279][    C0]  tcp_v4_rcv+0x2af8/0x3e30\n[  286.488904][    C0]  ? raw_local_deliver+0x51b/0xad0\n[  286.489551][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.490198][    C0]  ? __pfx_tcp_v4_rcv+0x10/0x10\n[  286.490813][    C0]  ? __pfx_raw_local_deliver+0x10/0x10\n[  286.491487][    C0]  ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack]\n[  286.492275][    C0]  ? rcu_is_watching+0x11/0xb0\n[  286.492900][    C0]  ip_protocol_deliver_rcu+0x8f/0x370\n[  286.493579][    C0]  ip_local_deliver_finish+0x297/0x420\n[  286.494268][    C0]  ip_local_deliver+0x168/0x430\n[  286.494867][    C0]  ? __pfx_ip_local_deliver+0x10/0x10\n[  286.495498][    C0]  ? __pfx_ip_local_deliver_finish+0x10/0x10\n[  286.496204][    C0]  ? ip_rcv_finish_core+0x19a/0x1f20\n[  286.496806][    C0]  ? lock_release+0x217/0x2c0\n[  286.497414][    C0]  ip_rcv+0x455/0x6e0\n[  286.497945][    C0]  ? __pfx_ip_rcv+0x10/0x10\n[ \n---truncated---(CVE-2025-38035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: Revert atm_account_tx() if copy_from_iter_full() fails.\n\nIn vcc_sendmsg(), we account skb-\u0026gt;truesize to sk-\u0026gt;sk_wmem_alloc by\natm_account_tx().\n\nIt is expected to be reverted by atm_pop_raw() later called by\nvcc-\u0026gt;dev-\u0026gt;ops-\u0026gt;send(vcc, skb).\n\nHowever, vcc_sendmsg() misses the same revert when copy_from_iter_full()\nfails, and then we will leak a socket.\n\nLet\u0026apos;s factorise the revert part as atm_return_tx() and call it in\nthe failure path.\n\nNote that the corresponding sk_wmem_alloc operation can be found in\nalloc_tx() as of the blamed commit.\n\n  $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~(CVE-2025-38190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: Make sure modelist not set on unregistered console\n\nIt looks like attempting to write to the \u0026quot;store_modes\u0026quot; sysfs node will\nrun afoul of unregistered consoles:\n\nUBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28\nindex -1 is out of range for type \u0026apos;fb_info *[32]\u0026apos;\n...\n fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122\n fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048\n fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673\n store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113\n dev_attr_store+0x55/0x80 drivers/base/core.c:2439\n\nstatic struct fb_info *fbcon_registered_fb[FB_MAX];\n...\nstatic signed char con2fb_map[MAX_NR_CONSOLES];\n...\nstatic struct fb_info *fbcon_info_from_console(int console)\n...\n        return fbcon_registered_fb[con2fb_map[console]];\n\nIf con2fb_map contains a -1 things go wrong here. Instead, return NULL,\nas callers of fbcon_info_from_console() are trying to compare against\nexisting \u0026quot;info\u0026quot; pointers, so error handling should kick in correctly.(CVE-2025-38198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix MMIO write access to an invalid page in i40e_clear_hw\n\nWhen the device sends a specific input, an integer underflow can occur, leading\nto MMIO write access to an invalid page.\n\nPrevent the integer underflow by changing the type of related variables.(CVE-2025-38200)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nconfigfs-tsm-report: Fix NULL dereference of tsm_ops\n\nUnlike sysfs, the lifetime of configfs objects is controlled by\nuserspace. There is no mechanism for the kernel to find and delete all\ncreated config-items. Instead, the configfs-tsm-report mechanism has an\nexpectation that tsm_unregister() can happen at any time and cause\nestablished config-item access to start failing.\n\nThat expectation is not fully satisfied. While tsm_report_read(),\ntsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail\nif tsm_ops have been unregistered, tsm_report_privlevel_store()\ntsm_report_provider_show() fail to check for ops registration. Add the\nmissing checks for tsm_ops having been removed.\n\nNow, in supporting the ability for tsm_unregister() to always succeed,\nit leaves the problem of what to do with lingering config-items. The\nexpectation is that the admin that arranges for the -\u0026gt;remove() (unbind)\nof the ${tsm_arch}-guest driver is also responsible for deletion of all\nopen config-items. Until that deletion happens, -\u0026gt;probe() (reload /\nbind) of the ${tsm_arch}-guest driver fails.\n\nThis allows for emergency shutdown / revocation of attestation\ninterfaces, and requires coordinated restart.(CVE-2025-38210)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: sanitize request list handling\n\nValidate the request in nvme_tcp_handle_r2t() to ensure it\u0026apos;s not part of\nany list, otherwise a malicious R2T PDU might inject a loop in request\nlist processing.(CVE-2025-38264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().\n\nAs syzbot reported [0], mpls_route_input_rcu() can be called\nfrom mpls_getroute(), where is under RTNL.\n\nnet-\u0026gt;mpls.platform_label is only updated under RTNL.\n\nLet\u0026apos;s use rcu_dereference_rtnl() in mpls_route_input_rcu() to\nsilence the splat.\n\n[0]:\nWARNING: suspicious RCU usage\n6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted\n ----------------------------\nnet/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n1 lock held by syz.2.4451/17730:\n #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]\n #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865\n mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84\n mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381\n rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964\n netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620\n __sys_sendmmsg+0x200/0x420 net/socket.c:2709\n __do_sys_sendmmsg net/socket.c:2736 [inline]\n __se_sys_sendmmsg net/socket.c:2733 [inline]\n __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f0a2818e969\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133\nRAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969\nRDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003\nRBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268\n \u0026lt;/TASK\u0026gt;(CVE-2025-38324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: altmodes/displayport: do not index invalid pin_assignments\n\nA poorly implemented DisplayPort Alt Mode port partner can indicate\nthat its pin assignment capabilities are greater than the maximum\nvalue, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show\nwill cause a BRK exception due to an out of bounds array access.\n\nPrevent for loop in pin_assignment_show from accessing\ninvalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX\nvalue in typec_dp.h and using i \u0026lt; DP_PIN_ASSIGN_MAX as a loop\ncondition.(CVE-2025-38391)",
  "id": "OESA-2025-1928",
  "modified": "2026-08-06T11:09:00Z",
  "published": "2025-08-01T11:09:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1928"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21992"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38015"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38190"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38198"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38200"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38210"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38264"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38324"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38391"
    }
  ],
  "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-2025-21992",
    "CVE-2025-38015",
    "CVE-2025-38035",
    "CVE-2025-38190",
    "CVE-2025-38198",
    "CVE-2025-38200",
    "CVE-2025-38210",
    "CVE-2025-38264",
    "CVE-2025-38324",
    "CVE-2025-38391"
  ]
}



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.