GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
oesa-2025-2805
Vulnerability from osv_openeuler
Published
2025-12-12 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:

sctp: handle the error returned from sctp_auth_asoc_init_active_key

When it returns an error from sctp_auth_asoc_init_active_key(), the active_key is actually not updated. The old sh_key will be freeed while it's still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot:

sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734

This patch is to fix it by not replacing the sh_key when it returns errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key(). For sctp_auth_set_active_key(), old active_key_id will be set back to asoc->active_key_id when the same thing happens.(CVE-2022-50243)

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

igb: Do not free q_vector unless new one was allocated

Avoid potential use-after-free condition under memory pressure. If the kzalloc() fails, q_vector will be freed but left in the original adapter->q_vector[v_idx] array position.(CVE-2022-50252)

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

wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()

This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware version string by memcpy() in brcmf_fil_iovar_data_get(). The patch ensures buf is null-terminated.

Found by a modified version of syzkaller.

[ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][ T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [ 47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30 [ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897] ? usb_suspend+0x590/0x590 [ 47.631397][ T1897] really_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.633002][ ---truncated---(CVE-2022-50258)

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

wifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit()

The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb in case of pskb_expand_head() fails, add dev_kfree_skb() to fix it. Compile tested only.(CVE-2022-50321)

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

tipc: fix a null-ptr-deref in tipc_topsrv_accept

syzbot found a crash in tipc_topsrv_accept:

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipc_rcv tipc_topsrv_accept RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487 Call Trace: <TASK> tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

It was caused by srv->listener that might be set to null by tipc_topsrv_stop() in net .exit whereas it's still used in tipc_topsrv_accept() worker.

srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add a check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to avoid the null-ptr-deref. To ensure the lsock is not released during the tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop() where it's waiting until the tipc_topsrv_accept worker to be done.

Note that sk_callback_lock is used to protect sk->sk_user_data instead of srv->listener, and it should check srv in tipc_topsrv_listener_data_ready() instead. This also ensures that no more tipc_topsrv_accept worker will be started after tipc_conn_close() is called in tipc_topsrv_stop() where it sets sk->sk_user_data to null.(CVE-2022-50555)

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

igb: Fix igb_down hung on surprise removal

In a setup where a Thunderbolt hub connects to Ethernet and a display through USB Type-C, users may experience a hung task timeout when they remove the cable between the PC and the Thunderbolt hub. This is because the igb_down function is called multiple times when the Thunderbolt hub is unplugged. For example, the igb_io_error_detected triggers the first call, and the igb_remove triggers the second call. The second call to igb_down will block at napi_synchronize. Here's the call trace: __schedule+0x3b0/0xddb ? __mod_timer+0x164/0x5d3 schedule+0x44/0xa8 schedule_timeout+0xb2/0x2a4 ? run_local_timers+0x4e/0x4e msleep+0x31/0x38 igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4] __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4] igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4] __dev_close_many+0x95/0xec dev_close_many+0x6e/0x103 unregister_netdevice_many+0x105/0x5b1 unregister_netdevice_queue+0xc2/0x10d unregister_netdev+0x1c/0x23 igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4] pci_device_remove+0x3f/0x9c device_release_driver_internal+0xfe/0x1b4 pci_stop_bus_device+0x5b/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_and_remove_bus_device+0x12/0x19 pciehp_unconfigure_device+0x76/0xe9 pciehp_disable_slot+0x6e/0x131 pciehp_handle_presence_or_link_change+0x7a/0x3f7 pciehp_ist+0xbe/0x194 irq_thread_fn+0x22/0x4d ? irq_thread+0x1fd/0x1fd irq_thread+0x17b/0x1fd ? irq_forced_thread_fn+0x5f/0x5f kthread+0x142/0x153 ? __irq_get_irqchip_state+0x46/0x46 ? kthread_associate_blkcg+0x71/0x71 ret_from_fork+0x1f/0x30

In this case, igb_io_error_detected detaches the network interface and requests a PCIE slot reset, however, the PCIE reset callback is not being invoked and thus the Ethernet connection breaks down. As the PCIE error in this case is a non-fatal one, requesting a slot reset can be avoided. This patch fixes the task hung issue and preserves Ethernet connection by ignoring non-fatal PCIE errors.(CVE-2023-53148)

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

wifi: cfg80211: Fix use after free for wext

Key information in wext.connect is not reset on (re)connect and can hold data from a previous connection.

Reset key data to avoid that drivers or mac80211 incorrectly detect a WEP connection request and access the freed or already reused memory.

Additionally optimize cfg80211_sme_connect() and avoid an useless schedule of conn_work.(CVE-2023-53153)

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

jfs: jfs_dmap: Validate db_l2nbperpage while mounting

In jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block number inside dbFree(). db_l2nbperpage, which is the log2 number of blocks per page, is passed as an argument to BLKTODMAP which uses it for shifting.

Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is too big. This happens because the large value is set without any validation in dbMount() at line 181.

Thus, make sure that db_l2nbperpage is correct while mounting.

Max number of blocks per page = Page size / Min block size => log2(Max num_block per page) = log2(Page size / Min block size) = log2(Page size) - log2(Min block size)

=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE(CVE-2023-53222)

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

net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime

Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme.

The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running:

# ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1

When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1].

Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime:

$ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0

Root cause is as below: step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0 step4: real_dev down vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0 step5: delete vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is null

Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the "rx-vlan-filter" feature.

[1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _sys_sendmsg+0xfc/0x180

[2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK ---truncated---(CVE-2025-38470)

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

net/packet: fix a race in packet_set_ring() and packet_notifier()

When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event.

This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()").

There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.

The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.(CVE-2025-38617)

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": [
          "bpftool-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2512.1.0.0354.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2512.1.0.0354.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2512.1.0.0354.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-2512.1.0.0354.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, the following vulnerability has been resolved:\n\nsctp: handle the error returned from sctp_auth_asoc_init_active_key\n\nWhen it returns an error from sctp_auth_asoc_init_active_key(), the\nactive_key is actually not updated. The old sh_key will be freeed\nwhile it\u0026apos;s still used as active key in asoc. Then an use-after-free\nwill be triggered when sending patckets, as found by syzbot:\n\n  sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112\n  sctp_set_owner_w net/sctp/socket.c:132 [inline]\n  sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863\n  sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025\n  inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819\n  sock_sendmsg_nosec net/socket.c:714 [inline]\n  sock_sendmsg+0xcf/0x120 net/socket.c:734\n\nThis patch is to fix it by not replacing the sh_key when it returns\nerrors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().\nFor sctp_auth_set_active_key(), old active_key_id will be set back\nto asoc-\u0026gt;active_key_id when the same thing happens.(CVE-2022-50243)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigb: Do not free q_vector unless new one was allocated\n\nAvoid potential use-after-free condition under memory pressure. If the\nkzalloc() fails, q_vector will be freed but left in the original\nadapter-\u0026gt;q_vector[v_idx] array position.(CVE-2022-50252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()\n\nThis patch fixes a stack-out-of-bounds read in brcmfmac that occurs\nwhen \u0026apos;buf\u0026apos; that is not null-terminated is passed as an argument of\nstrsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware\nversion string by memcpy() in brcmf_fil_iovar_data_get().\nThe patch ensures buf is null-terminated.\n\nFound by a modified version of syzkaller.\n\n[   47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3\n[   47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available\n[   47.601565][ T1897] ==================================================================\n[   47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0\n[   47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897\n[   47.604336][ T1897]\n[   47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #131\n[   47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\n[   47.606907][ T1897] Workqueue: usb_hub_wq hub_event\n[   47.607453][ T1897] Call Trace:\n[   47.607801][ T1897]  dump_stack_lvl+0x8e/0xd1\n[   47.608295][ T1897]  print_address_description.constprop.0.cold+0xf/0x334\n[   47.609009][ T1897]  ? strsep+0x1b2/0x1f0\n[   47.609434][ T1897]  ? strsep+0x1b2/0x1f0\n[   47.609863][ T1897]  kasan_report.cold+0x83/0xdf\n[   47.610366][ T1897]  ? strsep+0x1b2/0x1f0\n[   47.610882][ T1897]  strsep+0x1b2/0x1f0\n[   47.611300][ T1897]  ? brcmf_fil_iovar_data_get+0x3a/0xf0\n[   47.611883][ T1897]  brcmf_c_preinit_dcmds+0x995/0xc40\n[   47.612434][ T1897]  ? brcmf_c_set_joinpref_default+0x100/0x100\n[   47.613078][ T1897]  ? rcu_read_lock_sched_held+0xa1/0xd0\n[   47.613662][ T1897]  ? rcu_read_lock_bh_held+0xb0/0xb0\n[   47.614208][ T1897]  ? lock_acquire+0x19d/0x4e0\n[   47.614704][ T1897]  ? find_held_lock+0x2d/0x110\n[   47.615236][ T1897]  ? brcmf_usb_deq+0x1a7/0x260\n[   47.615741][ T1897]  ? brcmf_usb_rx_fill_all+0x5a/0xf0\n[   47.616288][ T1897]  brcmf_attach+0x246/0xd40\n[   47.616758][ T1897]  ? wiphy_new_nm+0x1703/0x1dd0\n[   47.617280][ T1897]  ? kmemdup+0x43/0x50\n[   47.617720][ T1897]  brcmf_usb_probe+0x12de/0x1690\n[   47.618244][ T1897]  ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n[   47.618901][ T1897]  usb_probe_interface+0x2aa/0x760\n[   47.619429][ T1897]  ? usb_probe_device+0x250/0x250\n[   47.619950][ T1897]  really_probe+0x205/0xb70\n[   47.620435][ T1897]  ? driver_allows_async_probing+0x130/0x130\n[   47.621048][ T1897]  __driver_probe_device+0x311/0x4b0\n[   47.621595][ T1897]  ? driver_allows_async_probing+0x130/0x130\n[   47.622209][ T1897]  driver_probe_device+0x4e/0x150\n[   47.622739][ T1897]  __device_attach_driver+0x1cc/0x2a0\n[   47.623287][ T1897]  bus_for_each_drv+0x156/0x1d0\n[   47.623796][ T1897]  ? bus_rescan_devices+0x30/0x30\n[   47.624309][ T1897]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n[   47.624907][ T1897]  ? trace_hardirqs_on+0x46/0x160\n[   47.625437][ T1897]  __device_attach+0x23f/0x3a0\n[   47.625924][ T1897]  ? device_bind_driver+0xd0/0xd0\n[   47.626433][ T1897]  ? kobject_uevent_env+0x287/0x14b0\n[   47.627057][ T1897]  bus_probe_device+0x1da/0x290\n[   47.627557][ T1897]  device_add+0xb7b/0x1eb0\n[   47.628027][ T1897]  ? wait_for_completion+0x290/0x290\n[   47.628593][ T1897]  ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0\n[   47.629249][ T1897]  usb_set_configuration+0xf59/0x16f0\n[   47.629829][ T1897]  usb_generic_driver_probe+0x82/0xa0\n[   47.630385][ T1897]  usb_probe_device+0xbb/0x250\n[   47.630927][ T1897]  ? usb_suspend+0x590/0x590\n[   47.631397][ T1897]  really_probe+0x205/0xb70\n[   47.631855][ T1897]  ? driver_allows_async_probing+0x130/0x130\n[   47.632469][ T1897]  __driver_probe_device+0x311/0x4b0\n[   47.633002][ \n---truncated---(CVE-2022-50258)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit()\n\nThe brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb\nin case of pskb_expand_head() fails, add dev_kfree_skb() to fix it.\nCompile tested only.(CVE-2022-50321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix a null-ptr-deref in tipc_topsrv_accept\n\nsyzbot found a crash in tipc_topsrv_accept:\n\n  KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n  Workqueue: tipc_rcv tipc_topsrv_accept\n  RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460\n   process_one_work+0x991/0x1610 kernel/workqueue.c:2289\n   worker_thread+0x665/0x1080 kernel/workqueue.c:2436\n   kthread+0x2e4/0x3a0 kernel/kthread.c:376\n   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n\nIt was caused by srv-\u0026gt;listener that might be set to null by\ntipc_topsrv_stop() in net .exit whereas it\u0026apos;s still used in\ntipc_topsrv_accept() worker.\n\nsrv-\u0026gt;listener is protected by srv-\u0026gt;idr_lock in tipc_topsrv_stop(), so add\na check for srv-\u0026gt;listener under srv-\u0026gt;idr_lock in tipc_topsrv_accept() to\navoid the null-ptr-deref. To ensure the lsock is not released during the\ntipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()\nwhere it\u0026apos;s waiting until the tipc_topsrv_accept worker to be done.\n\nNote that sk_callback_lock is used to protect sk-\u0026gt;sk_user_data instead of\nsrv-\u0026gt;listener, and it should check srv in tipc_topsrv_listener_data_ready()\ninstead. This also ensures that no more tipc_topsrv_accept worker will be\nstarted after tipc_conn_close() is called in tipc_topsrv_stop() where it\nsets sk-\u0026gt;sk_user_data to null.(CVE-2022-50555)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigb: Fix igb_down hung on surprise removal\n\nIn a setup where a Thunderbolt hub connects to Ethernet and a display\nthrough USB Type-C, users may experience a hung task timeout when they\nremove the cable between the PC and the Thunderbolt hub.\nThis is because the igb_down function is called multiple times when\nthe Thunderbolt hub is unplugged. For example, the igb_io_error_detected\ntriggers the first call, and the igb_remove triggers the second call.\nThe second call to igb_down will block at napi_synchronize.\nHere\u0026apos;s the call trace:\n    __schedule+0x3b0/0xddb\n    ? __mod_timer+0x164/0x5d3\n    schedule+0x44/0xa8\n    schedule_timeout+0xb2/0x2a4\n    ? run_local_timers+0x4e/0x4e\n    msleep+0x31/0x38\n    igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]\n    __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]\n    igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]\n    __dev_close_many+0x95/0xec\n    dev_close_many+0x6e/0x103\n    unregister_netdevice_many+0x105/0x5b1\n    unregister_netdevice_queue+0xc2/0x10d\n    unregister_netdev+0x1c/0x23\n    igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]\n    pci_device_remove+0x3f/0x9c\n    device_release_driver_internal+0xfe/0x1b4\n    pci_stop_bus_device+0x5b/0x7f\n    pci_stop_bus_device+0x30/0x7f\n    pci_stop_bus_device+0x30/0x7f\n    pci_stop_and_remove_bus_device+0x12/0x19\n    pciehp_unconfigure_device+0x76/0xe9\n    pciehp_disable_slot+0x6e/0x131\n    pciehp_handle_presence_or_link_change+0x7a/0x3f7\n    pciehp_ist+0xbe/0x194\n    irq_thread_fn+0x22/0x4d\n    ? irq_thread+0x1fd/0x1fd\n    irq_thread+0x17b/0x1fd\n    ? irq_forced_thread_fn+0x5f/0x5f\n    kthread+0x142/0x153\n    ? __irq_get_irqchip_state+0x46/0x46\n    ? kthread_associate_blkcg+0x71/0x71\n    ret_from_fork+0x1f/0x30\n\nIn this case, igb_io_error_detected detaches the network interface\nand requests a PCIE slot reset, however, the PCIE reset callback is\nnot being invoked and thus the Ethernet connection breaks down.\nAs the PCIE error in this case is a non-fatal one, requesting a\nslot reset can be avoided.\nThis patch fixes the task hung issue and preserves Ethernet\nconnection by ignoring non-fatal PCIE errors.(CVE-2023-53148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: Fix use after free for wext\n\nKey information in wext.connect is not reset on (re)connect and can hold\ndata from a previous connection.\n\nReset key data to avoid that drivers or mac80211 incorrectly detect a\nWEP connection request and access the freed or already reused memory.\n\nAdditionally optimize cfg80211_sme_connect() and avoid an useless\nschedule of conn_work.(CVE-2023-53153)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: jfs_dmap: Validate db_l2nbperpage while mounting\n\nIn jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block\nnumber inside dbFree(). db_l2nbperpage, which is the log2 number of\nblocks per page, is passed as an argument to BLKTODMAP which uses it\nfor shifting.\n\nSyzbot reported a shift out-of-bounds crash because db_l2nbperpage is\ntoo big. This happens because the large value is set without any\nvalidation in dbMount() at line 181.\n\nThus, make sure that db_l2nbperpage is correct while mounting.\n\nMax number of blocks per page = Page size / Min block size\n=\u0026gt; log2(Max num_block per page) = log2(Page size / Min block size)\n\t\t\t\t= log2(Page size) - log2(Min block size)\n\n=\u0026gt; Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE(CVE-2023-53222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime\n\nAssuming the \u0026quot;rx-vlan-filter\u0026quot; feature is enabled on a net device, the\n8021q module will automatically add or remove VLAN 0 when the net device\nis put administratively up or down, respectively. There are a couple of\nproblems with the above scheme.\n\nThe first problem is a memory leak that can happen if the \u0026quot;rx-vlan-filter\u0026quot;\nfeature is disabled while the device is running:\n\n # ip link add bond1 up type bond mode 0\n # ethtool -K bond1 rx-vlan-filter off\n # ip link del dev bond1\n\nWhen the device is put administratively down the \u0026quot;rx-vlan-filter\u0026quot;\nfeature is disabled, so the 8021q module will not remove VLAN 0 and the\nmemory will be leaked [1].\n\nAnother problem that can happen is that the kernel can automatically\ndelete VLAN 0 when the device is put administratively down despite not\nadding it when the device was put administratively up since during that\ntime the \u0026quot;rx-vlan-filter\u0026quot; feature was disabled. null-ptr-unref or\nbug_on[2] will be triggered by unregister_vlan_dev() for refcount\nimbalance if toggling filtering during runtime:\n\n$ ip link add bond0 type bond mode 0\n$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q\n$ ethtool -K bond0 rx-vlan-filter off\n$ ifconfig bond0 up\n$ ethtool -K bond0 rx-vlan-filter on\n$ ifconfig bond0 down\n$ ip link del vlan0\n\nRoot cause is as below:\nstep1: add vlan0 for real_dev, such as bond, team.\nregister_vlan_dev\n    vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1\nstep2: disable vlan filter feature and enable real_dev\nstep3: change filter from 0 to 1\nvlan_device_event\n    vlan_filter_push_vids\n        ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0\nstep4: real_dev down\nvlan_device_event\n    vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0\n        vlan_info_rcu_free //free vlan0\nstep5: delete vlan0\nunregister_vlan_dev\n    BUG_ON(!vlan_info); //vlan_info is null\n\nFix both problems by noting in the VLAN info whether VLAN 0 was\nautomatically added upon NETDEV_UP and based on that decide whether it\nshould be deleted upon NETDEV_DOWN, regardless of the state of the\n\u0026quot;rx-vlan-filter\u0026quot; feature.\n\n[1]\nunreferenced object 0xffff8880068e3100 (size 256):\n  comm \u0026quot;ip\u0026quot;, pid 384, jiffies 4296130254\n  hex dump (first 32 bytes):\n    00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00  . 0.............\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace (crc 81ce31fa):\n    __kmalloc_cache_noprof+0x2b5/0x340\n    vlan_vid_add+0x434/0x940\n    vlan_device_event.cold+0x75/0xa8\n    notifier_call_chain+0xca/0x150\n    __dev_notify_flags+0xe3/0x250\n    rtnl_configure_link+0x193/0x260\n    rtnl_newlink_create+0x383/0x8e0\n    __rtnl_newlink+0x22c/0xa40\n    rtnl_newlink+0x627/0xb00\n    rtnetlink_rcv_msg+0x6fb/0xb70\n    netlink_rcv_skb+0x11f/0x350\n    netlink_unicast+0x426/0x710\n    netlink_sendmsg+0x75a/0xc20\n    __sock_sendmsg+0xc1/0x150\n    ____sys_sendmsg+0x5aa/0x7b0\n    ___sys_sendmsg+0xfc/0x180\n\n[2]\nkernel BUG at net/8021q/vlan.c:99!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))\nRSP: 0018:ffff88810badf310 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8\nRBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80\nR10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000\nR13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e\nFS:  00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\n---truncated---(CVE-2025-38470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)",
  "id": "OESA-2025-2805",
  "modified": "2026-08-06T11:09:56Z",
  "published": "2025-12-12T11:09:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2805"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50243"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50252"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50258"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50321"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50555"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53148"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53222"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38470"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
    }
  ],
  "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-2022-50243",
    "CVE-2022-50252",
    "CVE-2022-50258",
    "CVE-2022-50321",
    "CVE-2022-50555",
    "CVE-2023-53148",
    "CVE-2023-53153",
    "CVE-2023-53222",
    "CVE-2025-38470",
    "CVE-2025-38617"
  ]
}



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.