GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
oesa-2026-3155
Vulnerability from osv_openeuler
Published
2026-07-24 11:12
Modified
2026-08-06 11:12
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:

iio: accel: bmc150: Fix irq assumption regression

The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts:

Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read

PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4

This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why.

Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.(CVE-2025-68330)

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

iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver

at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq).

If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:

CPU0 CPU1

                                 | at91_adc_workq_handler

at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev

Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.(CVE-2025-71199)

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

nilfs2: Fix potential block overflow that cause system hang

When a user executes the FITRIM command, an underflow can occur when calculating nblocks if end_block is too small. Since nblocks is of type sector_t, which is u64, a negative nblocks value will become a very large positive integer. This ultimately leads to the block layer function __blkdev_issue_discard() taking an excessively long time to process the bio chain, and the ns_segctor_sem lock remains held for a long period. This prevents other tasks from acquiring the ns_segctor_sem lock, resulting in the hang reported by syzbot in [1].

If the ending block is too small, typically if it is smaller than 4KiB range, depending on the usage of the segment 0, it may be possible to attempt a discard request beyond the device size causing the hang.

Exiting successfully and assign the discarded size (0 in this case) to range->len.

Although the start and len values in the user input range are too small, a conservative strategy is adopted here to safely ignore them, which is equivalent to a no-op; it will not perform any trimming and will not throw an error.

[1] task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000 Call Trace: rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272 nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline] nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684

ryusuke: corrected part of the commit message about the consequences

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

dmaengine: omap-dma: fix dma_pool resource leak in error paths

The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths.

Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.(CVE-2026-23033)

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

net/sched: act_ife: avoid possible NULL deref

tcf_ife_encode() must make sure ife_encode() does not return NULL.

syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: <TASK> ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798(CVE-2026-23064)

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

wifi: rsi: Fix memory corruption due to not set vif driver data size

The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed.

The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure "struct vif_priv". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory.

In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv vif_info = (struct vif_priv )vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash.

The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do "ip link set wlan0 up", "sleep 1", "ip link set wlan0 down" and the crash occurs.

Fix this by setting the correct size of vif driver data, which is the size of "struct vif_priv", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.(CVE-2026-23073)

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

netrom: fix double-free in nr_route_frame()

In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug.

Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.(CVE-2026-23098)

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

platform/x86: toshiba_haps: Fix memory leaks in add/remove routines

toshiba_haps_add() leaks the haps object allocated by it if it returns an error after allocating that object successfully.

toshiba_haps_remove() does not free the object pointed to by toshiba_haps before clearing that pointer, so it becomes unreachable allocated memory.

Address these memory leaks by using devm_kzalloc() for allocating the memory in question.(CVE-2026-23176)

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

scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()

A malicious or compromised VIO server can return a num_written value in the discover targets MAD response that exceeds max_targets. This value is stored directly in vhost->num_targets without validation, and is then used as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which is only allocated for max_targets entries. Indices at or beyond max_targets access kernel memory outside the DMA-coherent allocation. The out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI MADs that are sent back to the VIO server, leaking kernel memory.

Fix by clamping num_written to max_targets before storing it.(CVE-2026-31464)

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

ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY

filemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY, as documented in mm/filemap.c:

"If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap()."

When this happens, a concurrent munmap() can call remove_vma() and free the vm_area_struct via RCU. The saved 'vma' pointer in ocfs2_fault() then becomes a dangling pointer, and the subsequent trace_ocfs2_fault() call dereferences it -- a use-after-free.

Fix this by saving ip_blkno as a plain integer before calling filemap_fault(), and removing vma from the trace event. Since ip_blkno is copied by value before the lock can be dropped, it remains valid regardless of what happens to the vma or inode afterward.(CVE-2026-31597)

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

ocfs2: fix possible deadlock between unlink and dio_end_io_write

ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key.

Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock B

Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A

Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode)

Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.(CVE-2026-31598)

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

usbip: validate number_of_packets in usbip_pack_ret_submit()

When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the original number_of_packets from the CMD_SUBMIT.

A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region.

KASAN confirmed this with kernel 7.0.0-rc5:

BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69

The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)

The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets.

This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size.

Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbip_recv_iso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit.

Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.(CVE-2026-31607)

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

fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO

Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.(CVE-2026-31618)

In the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler. The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target->nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays") fixed similar missing checks against the same field on the NCI path.(CVE-2026-31622)

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

fbdev: vt8500lcdfb: fix missing dma_free_coherent()

fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached.(CVE-2026-43202)

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

net/rds: No shortcut out of RDS_CONN_ERROR

RDS connections carry a state "rds_conn_path::cp_state" and transitions from one state to another and are conditional upon an expected state: "rds_conn_path_transition."

There is one exception to this conditionality, which is "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop" regardless of what state the condition is currently in.

But as soon as a connection enters state "RDS_CONN_ERROR", the connection handling code expects it to go through the shutdown-path.

The RDS/TCP multipath changes added a shortcut out of "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING" via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change").

A subsequent "rds_tcp_reset_callbacks" can then transition the state to "RDS_CONN_RESETTING" with a shutdown-worker queued.

That'll trip up "rds_conn_init_shutdown", which was never adjusted to handle "RDS_CONN_RESETTING" and subsequently drops the connection with the dreaded "DR_INV_CONN_STATE", which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever.

So we do two things here:

a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code.

b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again."(CVE-2026-43226)

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

misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()

ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60).

A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started.

The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes:

queue_begin + reader * sizeof(struct remote_input)

with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception.

Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.(CVE-2026-46022)

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

net: caif: clear client service pointer on teardown

caif_connect() can tear down an existing client after remote shutdown by calling caif_disconnect_client() followed by caif_free_client(). caif_free_client() releases the service layer referenced by adap_layer-&gt;dn, but leaves that pointer stale.

When the socket is later destroyed, caif_sock_destructor() calls caif_free_client() again and dereferences the freed service pointer.

Clear the client/service links before releasing the service object so repeated teardown becomes harmless.(CVE-2026-46098)

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

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2607.3.0.0381.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2607.3.0.0381.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2607.3.0.0381.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-2607.3.0.0381.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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\niio: accel: bmc150: Fix irq assumption regression\n\nThe code in bmc150-accel-core.c unconditionally calls\nbmc150_accel_set_interrupt() in the iio_buffer_setup_ops,\nsuch as on the runtime PM resume path giving a kernel\nsplat like this if the device has no interrupts:\n\nUnable to handle kernel NULL pointer dereference at virtual\n  address 00000001 when read\n\nPC is at bmc150_accel_set_interrupt+0x98/0x194\nLR is at __pm_runtime_resume+0x5c/0x64\n(...)\nCall trace:\nbmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108\nbmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc\n__iio_update_buffers from enable_store+0x84/0xc8\nenable_store from kernfs_fop_write_iter+0x154/0x1b4\n\nThis bug seems to have been in the driver since the beginning,\nbut it only manifests recently, I do not know why.\n\nStore the IRQ number in the state struct, as this is a common\npattern in other drivers, then use this to determine if we have\nIRQ support or not.(CVE-2025-68330)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver\n\nat91_adc_interrupt can call at91_adc_touch_data_handler function\nto start the work by schedule_work(\u0026amp;st-\u0026gt;touch_st.workq).\n\nIf we remove the module which will call at91_adc_remove to\nmake cleanup, it will free indio_dev through iio_device_unregister but\nquite a bit later. While the work mentioned above will be used. The\nsequence of operations that may lead to a UAF bug is as follows:\n\nCPU0                                      CPU1\n\n                                     | at91_adc_workq_handler\nat91_adc_remove                      |\niio_device_unregister(indio_dev)     |\n//free indio_dev a bit later         |\n                                     | iio_push_to_buffers(indio_dev)\n                                     | //use indio_dev\n\nFix it by ensuring that the work is canceled before proceeding with\nthe cleanup in at91_adc_remove.(CVE-2025-71199)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: Fix potential block overflow that cause system hang\n\nWhen a user executes the FITRIM command, an underflow can occur when\ncalculating nblocks if end_block is too small. Since nblocks is of\ntype sector_t, which is u64, a negative nblocks value will become a\nvery large positive integer. This ultimately leads to the block layer\nfunction __blkdev_issue_discard() taking an excessively long time to\nprocess the bio chain, and the ns_segctor_sem lock remains held for a\nlong period. This prevents other tasks from acquiring the ns_segctor_sem\nlock, resulting in the hang reported by syzbot in [1].\n\nIf the ending block is too small, typically if it is smaller than 4KiB\nrange, depending on the usage of the segment 0, it may be possible to\nattempt a discard request beyond the device size causing the hang.\n\nExiting successfully and assign the discarded size (0 in this case)\nto range-\u0026gt;len.\n\nAlthough the start and len values in the user input range are too small,\na conservative strategy is adopted here to safely ignore them, which is\nequivalent to a no-op; it will not perform any trimming and will not\nthrow an error.\n\n[1]\ntask:segctord state:D stack:28968 pid:6093 tgid:6093  ppid:2 task_flags:0x200040 flags:0x00080000\nCall Trace:\n rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272\n nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]\n nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684\n\n[ryusuke: corrected part of the commit message about the consequences](CVE-2025-71237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: omap-dma: fix dma_pool resource leak in error paths\n\nThe dma_pool created by dma_pool_create() is not destroyed when\ndma_async_device_register() or of_dma_controller_register() fails,\ncausing a resource leak in the probe error paths.\n\nAdd dma_pool_destroy() in both error paths to properly release the\nallocated dma_pool resource.(CVE-2026-23033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ife: avoid possible NULL deref\n\ntcf_ife_encode() must make sure ife_encode() does not return NULL.\n\nsyzbot reported:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166\nCPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full)\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101\n  tcf_ife_encode net/sched/act_ife.c:841 [inline]\n  tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877\n  tc_act include/net/tc_wrapper.h:130 [inline]\n  tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152\n  tcf_exts_exec include/net/pkt_cls.h:349 [inline]\n  mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42\n  tc_classify include/net/tc_wrapper.h:197 [inline]\n  __tcf_classify net/sched/cls_api.c:1764 [inline]\n  tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860\n  multiq_classify net/sched/sch_multiq.c:39 [inline]\n  multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66\n  dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147\n  __dev_xmit_skb net/core/dev.c:4262 [inline]\n  __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798(CVE-2026-23064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rsi: Fix memory corruption due to not set vif driver data size\n\nThe struct ieee80211_vif contains trailing space for vif driver data,\nwhen struct ieee80211_vif is allocated, the total memory size that is\nallocated is sizeof(struct ieee80211_vif) + size of vif driver data.\nThe size of vif driver data is set by each WiFi driver as needed.\n\nThe RSI911x driver does not set vif driver data size, no trailing space\nfor vif driver data is therefore allocated past struct ieee80211_vif .\nThe RSI911x driver does however use the vif driver data to store its\nvif driver data structure \u0026quot;struct vif_priv\u0026quot;. An access to vif-\u0026gt;drv_priv\nleads to access out of struct ieee80211_vif bounds and corruption of\nsome memory.\n\nIn case of the failure observed locally, rsi_mac80211_add_interface()\nwould write struct vif_priv *vif_info = (struct vif_priv *)vif-\u0026gt;drv_priv;\nvif_info-\u0026gt;vap_id = vap_idx. This write corrupts struct fq_tin member\nstruct list_head new_flows . The flow = list_first_entry(head, struct\nfq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus\naddress, which when accessed causes a crash.\n\nThe trigger is very simple, boot the machine with init=/bin/sh , mount\ndevtmpfs, sysfs, procfs, and then do \u0026quot;ip link set wlan0 up\u0026quot;, \u0026quot;sleep 1\u0026quot;,\n\u0026quot;ip link set wlan0 down\u0026quot; and the crash occurs.\n\nFix this by setting the correct size of vif driver data, which is the\nsize of \u0026quot;struct vif_priv\u0026quot;, so that memory is allocated and the driver\ncan store its driver data in it, instead of corrupting memory around\nit.(CVE-2026-23073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: fix double-free in nr_route_frame()\n\nIn nr_route_frame(), old_skb is immediately freed without checking if\nnr_neigh-\u0026gt;ax25 pointer is NULL. Therefore, if nr_neigh-\u0026gt;ax25 is NULL,\nthe caller function will free old_skb again, causing a double-free bug.\n\nTherefore, to prevent this, we need to modify it to check whether\nnr_neigh-\u0026gt;ax25 is NULL before freeing old_skb.(CVE-2026-23098)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: toshiba_haps: Fix memory leaks in add/remove routines\n\ntoshiba_haps_add() leaks the haps object allocated by it if it returns\nan error after allocating that object successfully.\n\ntoshiba_haps_remove() does not free the object pointed to by\ntoshiba_haps before clearing that pointer, so it becomes unreachable\nallocated memory.\n\nAddress these memory leaks by using devm_kzalloc() for allocating\nthe memory in question.(CVE-2026-23176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()\n\nA malicious or compromised VIO server can return a num_written value in the\ndiscover targets MAD response that exceeds max_targets. This value is\nstored directly in vhost-\u0026gt;num_targets without validation, and is then used\nas the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which\nis only allocated for max_targets entries. Indices at or beyond max_targets\naccess kernel memory outside the DMA-coherent allocation.  The\nout-of-bounds data is subsequently embedded in Implicit Logout and PLOGI\nMADs that are sent back to the VIO server, leaking kernel memory.\n\nFix by clamping num_written to max_targets before storing it.(CVE-2026-31464)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY\n\nfilemap_fault() may drop the mmap_lock before returning VM_FAULT_RETRY,\nas documented in mm/filemap.c:\n\n  \u0026quot;If our return value has VM_FAULT_RETRY set, it\u0026apos;s because the mmap_lock\n  may be dropped before doing I/O or by lock_folio_maybe_drop_mmap().\u0026quot;\n\nWhen this happens, a concurrent munmap() can call remove_vma() and free\nthe vm_area_struct via RCU. The saved \u0026apos;vma\u0026apos; pointer in ocfs2_fault() then\nbecomes a dangling pointer, and the subsequent trace_ocfs2_fault() call\ndereferences it -- a use-after-free.\n\nFix this by saving ip_blkno as a plain integer before calling\nfilemap_fault(), and removing vma from the trace event. Since\nip_blkno is copied by value before the lock can be dropped, it\nremains valid regardless of what happens to the vma or inode\nafterward.(CVE-2026-31597)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix possible deadlock between unlink and dio_end_io_write\n\nocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,\nwhile in ocfs2_dio_end_io_write, it acquires these locks in reverse order.\nThis creates an ABBA lock ordering violation on lock classes\nocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and\nocfs2_file_ip_alloc_sem_key.\n\nLock Chain #0 (orphan dir inode_lock -\u0026gt; ip_alloc_sem):\nocfs2_unlink\n  ocfs2_prepare_orphan_dir\n    ocfs2_lookup_lock_orphan_dir\n      inode_lock(orphan_dir_inode) \u0026lt;- lock A\n    __ocfs2_prepare_orphan_dir\n      ocfs2_prepare_dir_for_insert\n        ocfs2_extend_dir\n\t  ocfs2_expand_inline_dir\n\t    down_write(\u0026amp;oi-\u0026gt;ip_alloc_sem) \u0026lt;- Lock B\n\nLock Chain #1 (ip_alloc_sem -\u0026gt; orphan dir inode_lock):\nocfs2_dio_end_io_write\n  down_write(\u0026amp;oi-\u0026gt;ip_alloc_sem) \u0026lt;- Lock B\n  ocfs2_del_inode_from_orphan()\n    inode_lock(orphan_dir_inode) \u0026lt;- Lock A\n\nDeadlock Scenario:\n  CPU0 (unlink)                     CPU1 (dio_end_io_write)\n  ------                            ------\n  inode_lock(orphan_dir_inode)\n                                    down_write(ip_alloc_sem)\n  down_write(ip_alloc_sem)\n                                    inode_lock(orphan_dir_inode)\n\nSince ip_alloc_sem is to protect allocation changes, which is unrelated\nwith operations in ocfs2_del_inode_from_orphan.  So move\nocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.(CVE-2026-31598)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbip: validate number_of_packets in usbip_pack_ret_submit()\n\nWhen a USB/IP client receives a RET_SUBMIT response,\nusbip_pack_ret_submit() unconditionally overwrites\nurb-\u0026gt;number_of_packets from the network PDU. This value is\nsubsequently used as the loop bound in usbip_recv_iso() and\nusbip_pad_iso() to iterate over urb-\u0026gt;iso_frame_desc[], a flexible\narray whose size was fixed at URB allocation time based on the\n*original* number_of_packets from the CMD_SUBMIT.\n\nA malicious USB/IP server can set number_of_packets in the response\nto a value larger than what was originally submitted, causing a heap\nout-of-bounds write when usbip_recv_iso() writes to\nurb-\u0026gt;iso_frame_desc[i] beyond the allocated region.\n\nKASAN confirmed this with kernel 7.0.0-rc5:\n\n  BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640\n  Write of size 4 at addr ffff888106351d40 by task vhci_rx/69\n\n  The buggy address is located 0 bytes to the right of\n   allocated 320-byte region [ffff888106351c00, ffff888106351d40)\n\nThe server side (stub_rx.c) and gadget side (vudc_rx.c) already\nvalidate number_of_packets in the CMD_SUBMIT path since commits\nc6688ef9f297 (\u0026quot;usbip: fix stub_rx: harden CMD_SUBMIT path to handle\nmalicious input\u0026quot;) and b78d830f0049 (\u0026quot;usbip: fix vudc_rx: harden\nCMD_SUBMIT path to handle malicious input\u0026quot;). The server side validates\nagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.\nOn the client side we have the original URB, so we can use the tighter\nbound: the response must not exceed the original number_of_packets.\n\nThis mirrors the existing validation of actual_length against\ntransfer_buffer_length in usbip_recv_xbuff(), which checks the\nresponse value against the original allocation size.\n\nKelvin Mbogo\u0026apos;s series (\u0026quot;usb: usbip: fix integer overflow in\nusbip_recv_iso()\u0026quot;, v2) hardens the receive-side functions themselves;\nthis patch complements that work by catching the bad value at its\nsource -- in usbip_pack_ret_submit() before the overwrite -- and\nusing the tighter per-URB allocation bound rather than the global\nUSBIP_MAX_ISO_PACKETS limit.\n\nFix this by checking rpdu-\u0026gt;number_of_packets against\nurb-\u0026gt;number_of_packets in usbip_pack_ret_submit() before the\noverwrite. On violation, clamp to zero so that usbip_recv_iso() and\nusbip_pad_iso() safely return early.(CVE-2026-31607)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO\n\nMuch like commit 19f953e74356 (\u0026quot;fbdev: fb_pm2fb: Avoid potential divide\nby zero error\u0026quot;), we also need to prevent that same crash from happening\nin the udlfb driver as it uses pixclock directly when dividing, which\nwill crash.(CVE-2026-31618)\n\nIn the Linux kernel, the following vulnerability has been resolved: NFC: digital: Bounds check NFC-A cascade depth in SDD response handler. The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3 or 4 bytes to target-\u0026gt;nfcid1 on each round, but the number of cascade rounds is controlled entirely by the peer device. The peer sets the cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the cascade-incomplete bit in the SEL_RES (deciding whether another round follows). ISO 14443-3 limits NFC-A to three cascade levels and target-\u0026gt;nfcid1 is sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver actually enforces this. This means a malicious peer can keep the cascade running, writing past the heap-allocated nfc_target with each round. Fix this by rejecting the response when the accumulated UID would exceed the buffer. Commit e329e71013c9 (\u0026quot;NFC: nci: Bounds check struct nfc_target arrays\u0026quot;) fixed similar missing checks against the same field on the NCI path.(CVE-2026-31622)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: vt8500lcdfb: fix missing dma_free_coherent()\n\nfbi-\u0026gt;fb.screen_buffer is allocated with dma_alloc_coherent() but is not\nfreed if the error path is reached.(CVE-2026-43202)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/rds: No shortcut out of RDS_CONN_ERROR\n\nRDS connections carry a state \u0026quot;rds_conn_path::cp_state\u0026quot;\nand transitions from one state to another and are conditional\nupon an expected state: \u0026quot;rds_conn_path_transition.\u0026quot;\n\nThere is one exception to this conditionality, which is\n\u0026quot;RDS_CONN_ERROR\u0026quot; that can be enforced by \u0026quot;rds_conn_path_drop\u0026quot;\nregardless of what state the condition is currently in.\n\nBut as soon as a connection enters state \u0026quot;RDS_CONN_ERROR\u0026quot;,\nthe connection handling code expects it to go through the\nshutdown-path.\n\nThe RDS/TCP multipath changes added a shortcut out of\n\u0026quot;RDS_CONN_ERROR\u0026quot; straight back to \u0026quot;RDS_CONN_CONNECTING\u0026quot;\nvia \u0026quot;rds_tcp_accept_one_path\u0026quot; (e.g. after \u0026quot;rds_tcp_state_change\u0026quot;).\n\nA subsequent \u0026quot;rds_tcp_reset_callbacks\u0026quot; can then transition\nthe state to \u0026quot;RDS_CONN_RESETTING\u0026quot; with a shutdown-worker queued.\n\nThat\u0026apos;ll trip up \u0026quot;rds_conn_init_shutdown\u0026quot;, which was\nnever adjusted to handle \u0026quot;RDS_CONN_RESETTING\u0026quot; and subsequently\ndrops the connection with the dreaded \u0026quot;DR_INV_CONN_STATE\u0026quot;,\nwhich leaves \u0026quot;RDS_SHUTDOWN_WORK_QUEUED\u0026quot; on forever.\n\nSo we do two things here:\n\na) Don\u0026apos;t shortcut \u0026quot;RDS_CONN_ERROR\u0026quot;, but take the longer\n   path through the shutdown code.\n\nb) Add \u0026quot;RDS_CONN_RESETTING\u0026quot; to the expected states in\n  \u0026quot;rds_conn_init_shutdown\u0026quot; so that we won\u0026apos;t error out\n  and get stuck, if we ever hit weird state transitions\n  like this again.\u0026quot;(CVE-2026-43226)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()\n\nibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read\nwhen the queue reader or writer index from hardware exceeds\nREMOTE_QUEUE_SIZE (60).\n\nA compromised service processor can trigger this by writing an\nout-of-range value to the reader or writer MMIO register before\nasserting an interrupt. Since writer is re-read from hardware on\nevery loop iteration, it can also be set to an out-of-range value\nafter the loop has already started.\n\nThe root cause is that get_queue_reader() and get_queue_writer() return\nraw readl() values that are passed directly into get_queue_entry(),\nwhich computes:\n\n  queue_begin + reader * sizeof(struct remote_input)\n\nwith no bounds check. This unchecked MMIO address is then passed to\nmemcpy_fromio(), reading 8 bytes from unintended device registers.\nFor sufficiently large values the address falls outside the PCI BAR\nmapping entirely, triggering a machine check exception.\n\nFix by checking both indices against REMOTE_QUEUE_SIZE at the top of\nthe loop body, before any call to get_queue_entry(). On an out-of-range\nvalue, reset the reader register to 0 via set_queue_reader() before\nbreaking, so that normal queue operation can resume if the corrupted\nhardware state is transient.(CVE-2026-46022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: caif: clear client service pointer on teardown\n\n`caif_connect()` can tear down an existing client after remote shutdown by\ncalling `caif_disconnect_client()` followed by `caif_free_client()`.\n`caif_free_client()` releases the service layer referenced by\n`adap_layer-\u0026gt;dn`, but leaves that pointer stale.\n\nWhen the socket is later destroyed, `caif_sock_destructor()` calls\n`caif_free_client()` again and dereferences the freed service pointer.\n\nClear the client/service links before releasing the service object so\nrepeated teardown becomes harmless.(CVE-2026-46098)",
  "id": "OESA-2026-3155",
  "modified": "2026-08-06T11:12:02Z",
  "published": "2026-07-24T11:12:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3155"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68330"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71199"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71237"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23033"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23064"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23073"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23098"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23176"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31464"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31597"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31598"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31607"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31618"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31622"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43202"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43226"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46022"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46098"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2025-68330",
    "CVE-2025-71199",
    "CVE-2025-71237",
    "CVE-2026-23033",
    "CVE-2026-23064",
    "CVE-2026-23073",
    "CVE-2026-23098",
    "CVE-2026-23176",
    "CVE-2026-31464",
    "CVE-2026-31597",
    "CVE-2026-31598",
    "CVE-2026-31607",
    "CVE-2026-31618",
    "CVE-2026-31622",
    "CVE-2026-43202",
    "CVE-2026-43226",
    "CVE-2026-46022",
    "CVE-2026-46098"
  ]
}



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.