{"id":"OESA-2026-3702","summary":"kernel security update","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\nnet/9p: fix double req put in p9_fd_cancelled\n\nSyzkaller reports a KASAN issue as below:\n\ngeneral protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]\nCPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:__list_del include/linux/list.h:114 [inline]\nRIP: 0010:__list_del_entry include/linux/list.h:137 [inline]\nRIP: 0010:list_del include/linux/list.h:148 [inline]\nRIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734\n\nCall Trace:\n <TASK>\n p9_client_flush+0x351/0x440 net/9p/client.c:614\n p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734\n p9_client_version net/9p/client.c:920 [inline]\n p9_client_create+0xb51/0x1240 net/9p/client.c:1027\n v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408\n v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126\n legacy_get_tree+0x108/0x220 fs/fs_context.c:632\n vfs_get_tree+0x8e/0x300 fs/super.c:1573\n do_new_mount fs/namespace.c:3056 [inline]\n path_mount+0x6a6/0x1e90 fs/namespace.c:3386\n do_mount fs/namespace.c:3399 [inline]\n __do_sys_mount fs/namespace.c:3607 [inline]\n __se_sys_mount fs/namespace.c:3584 [inline]\n __x64_sys_mount+0x283/0x300 fs/namespace.c:3584\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nThis happens because of a race condition between:\n\n- The 9p client sending an invalid flush request and later cleaning it up;\n- The 9p client in p9_read_work() canceled all pending requests.\n\n      Thread 1                              Thread 2\n    ...\n    p9_client_create()\n    ...\n    p9_fd_create()\n    ...\n    p9_conn_create()\n    ...\n    // start Thread 2\n    INIT_WORK(&m->rq, p9_read_work);\n                                        p9_read_work()\n    ...\n    p9_client_rpc()\n    ...\n                                        ...\n                                        p9_conn_cancel()\n                                        ...\n                                        spin_lock(&m->req_lock);\n    ...\n    p9_fd_cancelled()\n    ...\n                                        ...\n                                        spin_unlock(&m->req_lock);\n                                        // status rewrite\n                                        p9_client_cb(m->client, req, REQ_STATUS_ERROR)\n                                        // first remove\n                                        list_del(&req->req_list);\n                                        ...\n\n    spin_lock(&m->req_lock)\n    ...\n    // second remove\n    list_del(&req->req_list);\n    spin_unlock(&m->req_lock)\n  ...\n\nCommit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in\np9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem\nclient where the req_list could be deleted simultaneously by both\np9_read_work and p9_fd_cancelled functions, but for the case where req->status\nequals REQ_STATUS_RCVD.\n\nUpdate the check for req->status in p9_fd_cancelled to skip processing not\njust received requests, but anything that is not SENT, as whatever\nchanged the state from SENT also removed the request from its list.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.\n\n[updated the check from status == RECV || status == ERROR to status != SENT](CVE-2025-40027)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nexfat: validate cluster allocation bits of the allocation bitmap\n\nsyzbot created an exfat image with cluster bits not set for the allocation\nbitmap. exfat-fs reads and uses the allocation bitmap without checking\nthis. The problem is that if the start cluster of the allocation bitmap\nis 6, cluster 6 can be allocated when creating a directory with mkdir.\nexfat zeros out this cluster in exfat_mkdir, which can delete existing\nentries. This can reallocate the allocated entries. In addition,\nthe allocation bitmap is also zeroed out, so cluster 6 can be reallocated.\nThis patch adds exfat_test_bitmap_range to validate that clusters used for\nthe allocation bitmap are correctly marked as in-use.(CVE-2025-40307)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: stop tp_meter sessions during mesh teardown\n\nTP meter sessions remain linked on bat_priv->tp_list after the netlink\nrequest has already finished. When the mesh interface is removed,\nbatadv_mesh_free() currently tears down the mesh without first draining\nthese sessions.\n\nA running sender thread or a late incoming tp_meter packet can then keep\nprocessing against a mesh instance which is already shutting down.\nSynchronize tp_meter with the mesh lifetime by stopping all active\nsessions from batadv_mesh_free() and waiting for sender threads to exit\nbefore teardown continues.(CVE-2026-46208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: diag: reject stale associations in dump_one path\n\nThe SCTP exact sock_diag lookup can hold a transport reference, block on\nlock_sock(sk), and then resume after sctp_association_free() has marked\nthe association dead and freed its bind address list.\n\nWhen that happens, inet_assoc_attr_size() and\ninet_diag_msg_sctpasoc_fill() can still dereference association state\nthat is no longer valid for reporting. In particular,\ninet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a\nreal sctp_sockaddr_entry and trigger an out-of-bounds read from\nunrelated association memory.\n\nReject the association after taking the socket lock if it has been\nreaped or detached from the endpoint, and report the lookup as stale.\nThis keeps the exact dump-one path from formatting torn association\nstate.(CVE-2026-52917)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: Fix potential out-of-bounds access in crush_decode()\n\nA message of type CEPH_MSG_OSD_MAP containing a crush map with at least\none bucket has two fields holding the bucket algorithm. If the values\nin these two fields differ, an out-of-bounds access can occur. This is\nthe case because the first algorithm field (alg) is used to allocate\nthe correct amount of memory for a bucket of this type, while the second\nalgorithm field inside the bucket (b->alg) is used in the subsequent\nprocessing.\n\nThis patch fixes the issue by adding a check that compares alg and\nb->alg and aborts the processing in case they differ. Furthermore,\nb->alg is set to 0 in this case, because the destruction of the crush\nmap also uses this field to determine the bucket type, which can again\nresult in an out-of-bounds access when trying to free the memory pointed\nto by the fields of the bucket. To correctly free the memory allocated\nfor the bucket in such a case, the corresponding call to kfree is moved\nfrom the algorithm-specific crush_destroy_bucket functions to the\ngeneric crush_destroy_bucket().(CVE-2026-52955)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf\n\nnetvsc_copy_to_send_buf() copies page buffer entries into the VMBus\nsend buffer using phys_to_virt() on the entry PFN. Entries for the\nRNDIS header and the skb linear data come from kmalloc'd memory and\nare always in the kernel direct map, but entries for skb fragments\nreference page cache or user pages, which on 32-bit x86 with\nCONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page\nphys_to_virt() returns an address outside the direct map and the\nsubsequent memcpy() faults on the transmit softirq path, which is\nfatal.\n\nMap the pages with kmap_local_page() instead, handling two properties\nof the page buffer entries:\n\n - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity,\n   not a native PFN. Reconstruct the physical address first and derive\n   the native page from it, so the mapping stays correct where\n   PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages).\n\n - Since commit 41a6328b2c55 ("hv_netvsc: Preserve contiguous PFN\n   grouping in the page buffer array"), an entry describes a full\n   physically contiguous fragment and pb[i].len can exceed PAGE_SIZE,\n   while kmap_local_page() maps a single page. Copy page by page,\n   splitting at native page boundaries.\n\nThe copy path only handles packets smaller than the send section size\n(6144 bytes by default); larger packets take the cp_partial path where\nonly the RNDIS header is copied. So entries here are bounded by the\nsection size and a copy is split at most once on 4K-page systems. On\n!CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and\nno mapping work is added.(CVE-2026-53199)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix uninit-value in __sctp_rcv_asconf_lookup()\n\n__sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF\nchunk can hold the ADDIP header and a parameter header, then calls\naf->from_addr_param(), which reads the full address (16 bytes for IPv6)\ntrusting the parameter's declared length.\n\nAn unauthenticated peer can send a truncated trailing ASCONF chunk that\ndeclares an IPv6 address parameter but stops after the 4-byte parameter\nheader; reached from the no-association lookup path, from_addr_param() then\nreads uninitialized bytes past the parameter.\n\nImpact: an unauthenticated SCTP peer makes the receive path read up to 16\nbytes of uninitialized memory past a truncated ASCONF address parameter.\n\nThe sibling __sctp_rcv_init_lookup() bounds parameters with\nsctp_walk_params(); this path open-codes the fetch and omits the bound.\nVerify the whole address parameter lies within the chunk before\nfrom_addr_param() reads it, the same class of fix as commit 51e5ad549c43\n("net: sctp: fix KMSAN uninit-value in sctp_inq_pop").(CVE-2026-53225)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix slab-use-after-free Read in tipc_aead_decrypt_done\n\ntipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to\ncrypto_aead_decrypt(req) without taking a reference on the netns, unlike\nthe encrypt path. When crypto_aead_decrypt() is offloaded asynchronously\n(e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs\ntipc_aead_decrypt_done() later. If the bearer's netns is torn down in the\nmeantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the\nper-netns tipc_crypto, and the completion then reads it:\ntipc_aead_decrypt_done() dereferences aead->crypto->stats and\naead->crypto->net, and tipc_crypto_rcv_complete() dereferences\naead->crypto->aead[] and the node table -- reading freed memory.\n\nDecoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO):\n\n  BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999)\n  Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51\n  Workqueue: events_unbound\n  Call Trace:\n   tipc_aead_decrypt_done (net/tipc/crypto.c:999)\n   process_one_work (kernel/workqueue.c:3314)\n   worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)\n   kthread (kernel/kthread.c:436)\n   ret_from_fork (arch/x86/kernel/process.c:158)\n   ret_from_fork_asm (arch/x86/entry/entry_64.S:245)\n\n  Allocated by task 169:\n   __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)\n   tipc_crypto_start (net/tipc/crypto.c:1502)\n   tipc_init_net (net/tipc/core.c:72)\n   ops_init (net/core/net_namespace.c:137)\n   setup_net (net/core/net_namespace.c:446)\n   copy_net_ns (net/core/net_namespace.c:579)\n   create_new_namespaces (kernel/nsproxy.c:132)\n   __x64_sys_unshare (kernel/fork.c:3316)\n   do_syscall_64 (arch/x86/entry/syscall_64.c:63)\n   entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)\n\n  Freed by task 8:\n   kfree (mm/slub.c:6566)\n   tipc_exit_net (net/tipc/core.c:119)\n   cleanup_net (net/core/net_namespace.c:704)\n   process_one_work (kernel/workqueue.c:3314)\n   kthread (kernel/kthread.c:436)\n\nThis is the same class of bug that commit e279024617134 ("net/tipc: fix\nslab-use-after-free Read in tipc_aead_encrypt_done") fixed for the encrypt\nside. The encrypt path takes maybe_get_net(aead->crypto->net) before\ncrypto_aead_encrypt() and drops it with put_net() on the synchronous\nreturn paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY\nreturn keeps the reference for the async callback to release. The decrypt\npath was left without the equivalent guard.\n\nMirror the encrypt-side fix on the decrypt path: take a net reference\nbefore crypto_aead_decrypt() (failing with -ENODEV and the matching\nbearer put if it cannot be acquired), keep it across the\n-EINPROGRESS/-EBUSY async return, and drop it with put_net() on the\nsynchronous success/error return and at the end of\ntipc_aead_decrypt_done().\n\nReproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is\nflooded with crafted encrypted frames from an unknown peer (driving the\ncluster-key decrypt path) while the bearer's netns is repeatedly torn\ndown. The completion must run asynchronously to outlive\ntipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts\nsynchronously, so the async path was exercised via cryptd offload. The\nunguarded aead->crypto dereference in tipc_aead_decrypt_done() is the\nunpatched upstream path; tipc_aead_decrypt() still lacks\nmaybe_get_net(aead->crypto->net), so the completion can outlive the free\non any config where crypto_aead_decrypt() goes async.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-63801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check\n\nAn unintended behavior in the TCP conntrack state machine allows a\nconnection to be forced into the CLOSE state using an RST packet with an\ninvalid sequence number.\n\nSpecifically, after a SYN packet is observed, an RST with an invalid SEQ\ncan transition the conntrack entry to TCP_CONNTRACK_CLOSE, regardless of\nwhether the RST corresponds to the expected reply direction. The relevant\ncode path assumes the RST is a response to an outgoing SYN, but does not\nvalidate packet direction or ensure that a matching SYN was actually sent\nin the opposite direction.\n\nAs a result, a crafted packet sequence consisting of a SYN followed by an\ninvalid-sequence RST can prematurely terminate an active NAT entry. This\nmakes connection teardown easier than intended.\n\nSo, tighten the state transition logic to ensure that RST-triggered\nCLOSE transitions only occur when the RST is a valid response to a\npreviously observed SYN in the correct direction.(CVE-2026-63913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: route MIGRATE notifications to caller's netns\n\nxfrm_send_migrate() in net/xfrm/xfrm_user.c and pfkey_send_migrate()\nin net/key/af_key.c both hardcode &init_net for the multicast that\nannounces a successful XFRM_MSG_MIGRATE / SADB_X_MIGRATE.\n\nXFRM_MSG_MIGRATE arrives on a per-netns NETLINK_XFRM socket, and the\nrest of the xfrm/af_key netlink path was made netns-aware in 2008.\nThe other 14 multicast paths in xfrm_user.c route their event using\nxs_net(x), xp_net(xp) or sock_net(skb->sk); only the migrate path\nwas missed.\n\nTwo consequences of the init_net hardcoding:\n\n  1. The notification (selector, old/new endpoint addresses, and the\n     km_address) is delivered to listeners on init_net's\n     XFRMNLGRP_MIGRATE / pfkey BROADCAST_ALL groups rather than on\n     the issuing netns. An IKE daemon running in init_net therefore\n     receives migration notifications originating from any other\n     netns on the host.\n\n  2. An IKE daemon running inside a non-init netns and subscribed\n     to its own XFRMNLGRP_MIGRATE / pfkey groups never receives the\n     notification of its own migration. IKEv2 MOBIKE / address-update\n     handling inside a netns is silently broken.\n\nThread struct net through km_migrate() and the xfrm_mgr.migrate\nfunction pointer, drop the &init_net override in xfrm_send_migrate()\nand pfkey_send_migrate(), and pass the caller's net (already in\nscope in xfrm_migrate() via sock_net(skb->sk)) all the way down.\nstruct xfrm_mgr is in-tree only and not exported as a stable API,\nso the function-pointer signature change is internal.\n\npfkey_broadcast() is already netns-aware via net_generic(net,\npfkey_net_id) since the pernet conversion. The five other\npfkey_broadcast() callers in af_key.c already pass xs_net(x),\nsock_net(sk) or a per-netns net, so this only removes the\n&init_net outlier.(CVE-2026-63914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix race between sctp_wait_for_connect and peeloff\n\nsctp_wait_for_connect() drops and re-acquires the socket lock while\nwaiting for the association to reach ESTABLISHED state. During this\nwindow, another thread can peeloff the association to a new socket via\ngetsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. After\nre-acquiring the old socket lock, sctp_wait_for_connect() returns\nsuccess without noticing the migration — the caller then accesses\nthe association under the wrong lock in sctp_datamsg_from_user().\n\nAdd the same sk != asoc->base.sk check that sctp_wait_for_sndbuf()\nalready has, returning an error if the association was migrated while\nwe slept.(CVE-2026-63971)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: tt: fix negative last_changeset_len\n\nbatadv_piv_tt::last_changeset_len len was declared as s16, but the field is\nnever intended to hold a negative value. When a value greater than 32767 is\nassigned, it wraps to a negative signed integer.\n\nIn batadv_send_my_tt_response(), last_changeset_len is temporarily widened\nto s32. The incorrectly negative s16 value propagates into the s32, causing\nbatadv_tt_prepare_tvlv_local_data() to allocate a full sized buffer but\npopulates only a small portion of it with the collected changeset. All\nremaining bits are kept uninitialized.\n\nUsing an u16 avoids this type confusion and ensures that no (negative) sign\nextension is performed in batadv_send_my_tt_response().(CVE-2026-64089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: bla: avoid double decrement of bla.num_requests\n\nThe bla.num_requests is increased when no request_sent was in progress. And\nit is decremented in various places (announcement was received, backbone is\npurged, periodic work). But the check if the request_sent is actually set\nto a specific state and the atomic_dec/_inc are not safe because they are\nnot atomic (TOCTOU) and multiple such code portions can run concurrently.\n\nAt the same time, it is necessary to modify request_sent (state) and\nbla.num_requests atomically. Otherwise batadv_bla_send_request() might set\nrequest_sent to 1 and is interrupted.  batadv_handle_announce() can then\nset request_sent back to 0 and decrement num_requests before\nbatadv_bla_send_request() incremented it.\n\nThe two operations must therefore be locked. And since state (request_sent)\nand wait_periods are only accessed inside this lock, they can be converted\nto simpler datatypes. And to avoid that the bla.num_requests is touched by\na parallel running context with a valid backbone_gw reference after\nbatadv_bla_purge_backbone_gw() ran, a third state "stopped" is required to\ncorrectly signal that a backbone_gw is in the state of being cleaned up.(CVE-2026-64095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()\n\nrmnet_dellink() removes the endpoint from the hash table with\nhlist_del_init_rcu() and then immediately frees it with kfree(). However,\nRCU readers on the receive path (rmnet_rx_handler ->\n__rmnet_map_ingress_handler) may still hold a reference to the endpoint and\ndereference ep->egress_dev after the memory has been freed. The endpoint is\na kmalloc-32 object, and the stale read at offset 8 corresponds to the\negress_dev pointer.\n\n  BUG: unable to handle page fault for address: ffffffffde942eef\n  Oops: 0002 [#1] SMP NOPTI\n  CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY\n  RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27)\n  Call Trace:\n   <TASK>\n   __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101)\n   rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235)\n   __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096)\n   __netif_receive_skb_one_core (net/core/dev.c:6208)\n   netif_receive_skb (net/core/dev.c:6467)\n   tun_get_user (drivers/net/tun.c:1955)\n   tun_chr_write_iter (drivers/net/tun.c:2003)\n   vfs_write (fs/read_write.c:688)\n   ksys_write (fs/read_write.c:740)\n   </TASK>\n\nAdd an rcu_head field to struct rmnet_endpoint and replace kfree() with\nkfree_rcu() so the endpoint memory remains valid through the RCU grace\nperiod. Also remove the rmnet_vnd_dellink() call and inline only the\nnr_rmnet_devs decrement, since rmnet_vnd_dellink() would set\nep->egress_dev to NULL during the grace period, creating a data race\nwith lockless readers.(CVE-2026-64188)\n\nIn the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks. A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it, but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count, leading to an out-of-bounds read. This could allow an attacker to read beyond the allocated buffer, potentially causing information disclosure or system crash.(CVE-2026-64450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: fix use-after-free on registration failure\n\nMake sure to release the sibling interfaces in case controller\nregistration fails to avoid use-after-free and double-free when they are\neventually disconnected.\n\nThis issue was reported by Sashiko while reviewing a fix for a wakeup\nsource leak in the btusb probe errors paths.(CVE-2026-64471)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: firewire: isight: bound the sample count to the packet payload\n\nisight_packet() takes the frame count from the device iso packet and\nchecks it only against the device claimed iso length.\n\n\tcount = be32_to_cpu(payload->sample_count);\n\tif (likely(count <= (length - 16) / 4))\n\t\tisight_samples(isight, payload->samples, count);\n\nlength is the iso header data_length. It can be up to 0xffff. So the\ngate allows a count up to about 16379. isight_samples() then copies\ncount frames out of payload->samples into the PCM DMA buffer.\n\npayload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The\ndevice multiplexes two samples per frame. A count past\nMAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer\nsize writes past runtime->dma_area. The smallest PCM buffer is larger\nthan MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET\nkeeps both the read and the write in range.\n\nA malicious or faulty Apple iSight on the FireWire bus reaches this\nduring a normal capture.\n\nAdd the MAX_FRAMES_PER_PACKET bound to the gate.(CVE-2026-64483)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: Reject monmaps advertising zero monitors\n\nA message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a\nmonitor to the client. This monmap contains information about the\nexisting monitors in the cluster. Currently, a monmap indicating that\nthere are zero monitors in the cluster is treated as valid. However, it\nis impossible to have zero monitors in the cluster and still receive a\nvalid monmap from a monitor. Therefore, such a monmap must be corrupted\nand should be treated as invalid. Furthermore, a monmap with a monitor\ncount of zero can subsequently crash the client when attempting to open\na session with a monitor in __open_session(). This happens because the\n"BUG_ON(monc->monmap->num_mon < 1)" assertion in pick_new_mon() is\ntriggered.\n\nThis patch extends a check in ceph_monmap_decode() to also reject\narriving mon_maps with num_mon == 0 rather than only with\nnum_mon > CEPH_MAX_MON.\n\n[ idryomov: drop "log output for unusual values of num_mon" part ](CVE-2026-68155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: refresh auth->authorizer_buf{,_len} after authorizer update\n\nceph_x_create_authorizer() caches au->buf->vec.iov_base and\nau->buf->vec.iov_len in struct ceph_auth_handshake.  These\ncached values are then used by the messenger connect code when\nsending the authorizer.\n\nceph_x_update_authorizer() can rebuild the authorizer when a newer\nservice ticket is available.  If the rebuilt authorizer no longer\nfits in the existing buffer, ceph_x_build_authorizer() drops its\nreference to au->buf and allocates a new one.  If this is the final\nreference, ceph_buffer_put() frees the old ceph_buffer and its\nvec.iov_base, but auth->authorizer_buf still points at that freed\nmemory.\n\nA subsequent msgr1 reconnect can therefore queue the stale pointer\nand trigger a KASAN slab-use-after-free in _copy_from_iter() while\ntcp_sendmsg() copies the authorizer.\n\nRefresh auth->authorizer_buf and auth->authorizer_buf_len after a\nsuccessful authorizer rebuild so the messenger sends the current\nbuffer.(CVE-2026-68156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx231xx: fix devres lifetime\n\nUSB drivers bind to USB interfaces and any device managed resources\nshould have their lifetime tied to the interface rather than parent USB\ndevice. This avoids issues like memory leaks when drivers are unbound\nwithout their devices being physically disconnected (e.g. on probe\ndeferral or configuration changes).\n\nFix the driver state lifetime so that it is released on driver unbind.(CVE-2026-68227)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mad: Drop unmatched RMPP responses before reassembly\n\nKernel-handled RMPP receive processing starts reassembly for active\nDATA responses before the response is matched to an outstanding send.\nThe normal match happens later, after ib_process_rmpp_recv_wc() has\neither assembled a complete message or consumed the segment.\n\nThat ordering lets an unsolicited response that routes to a kernel\nRMPP agent by the high TID bits allocate or extend RMPP receive state\nbefore the full TID and source address are checked against a real\nrequest. A reordered burst can therefore reach the receive-side\ninsertion path even though the response would not match any send.\n\nFor kernel-handled RMPP DATA responses, require the existing\nib_find_send_mad() match before entering RMPP reassembly. The matcher\nalready checks the full TID, management class and source address/GID\nagainst the agent wait, backlog and in-flight send lists. If there is\nno match, drop the response without creating RMPP state.\n\nThis leaves the RMPP window behavior unchanged and only rejects\nresponses that have no corresponding request.(CVE-2026-68425)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs: sanitize MFT references returned from ntfs_lookup_inode_by_name()\n\nntfs_lookup_inode_by_name() returns MFT references read from directory\nindex entries on disk. These values are untrusted, but the function can\ncurrently return an error-marked MFT reference to its callers without\nvalidating it.\n\nCallers later decode lookup failures with MREF_ERR(). A crafted NTFS image\ncan set the MREF error bit while leaving the low bits as an arbitrary\nvalue, causing callers to consume a bogus pseudo-errno instead of treating\nthe lookup result as corrupted on-disk metadata.\n\nFix this at the source by normalizing every error-marked MFT reference\nreturned from ntfs_lookup_inode_by_name() to ERR_MREF(-EIO). Apply this to\nall four directory lookup return paths so every caller gets a validated\nresult without needing additional checks or an API change.\n\nThis keeps the sanitization in the common lookup helper, which is cleaner\nthan duplicating validation in each caller.(CVE-2026-72188)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix undefined shift of user RQ WQE size\n\nset_rq_size() computes the RQ WQE size as "1 << rq_wqe_shift" based on\nthe user-provided rq_wqe_shift, which is only checked to be greater than\n32, so shifts of 32 are still accepted. A shift of 31 also overflows a\nsigned integer, leading to undefined behavior.\n\nUse check_shl_overflow() to compute the RQ WQE size and reject any\ninvalid values.(CVE-2026-74297)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix UAF in hci_unregister_dev()\n\nhci_unregister_dev() does not disable cmd_timer and ncmd_timer\nbefore the hci_dev structure is freed. If a timeout fires\nduring device teardown, the callback dereferences freed memory\n(including the hdev->reset function pointer), leading to a\nuse-after-free.\n\nAdd disable_delayed_work_sync() calls alongside the existing\ndisable_work_sync() calls to ensure both timers are fully\nquiesced before teardown proceeds.(CVE-2026-74302)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Copy WQE to local buffer in non-SRQ receive path\n\nFor non-SRQ QPs, the responder reads WQE fields directly from the\nshared queue buffer mapped into userspace. This allows a malicious\nuser to modify fields like num_sge or sge entries while the kernel\nis processing the WQE, leading to out-of-bounds reads in\nrxe_resp_check_length() and copy_data().\n\nIntroduce get_recv_wqe() that validates num_sge and copies the WQE\nto a kernel-local buffer before processing, matching the approach\nalready used for SRQ WQEs in get_srq_wqe(). The srq_wqe buffer is\nreused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srpt: fix integer overflow in immediate data length check\n\nimm_buf->len is a user-controlled uint32_t received from the network.\nAdding it to imm_data_offset without overflow checking allows a\nmalicious initiator to send len=0xFFFFFFFF, causing req_size to wrap\naround to a small value, bypassing the bounds check, and subsequently\npassing a ~4GB length to sg_init_one().\n\nUse check_add_overflow() to detect wrapping before the comparison.(CVE-2026-74394)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix devx subscribe-event unwind NULL dereference\n\nMLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list\nbefore initializing the fields used by the shared error path.\n\nIf eventfd_ctx_fdget() then fails, the unwind path dereferences\nevent_sub->ev_file in uverbs_uobject_put() and calls\nsubscribe_event_xa_dealloc() with an unset xa_key_level1.\n\nsubscribe_event_xa_alloc() creates the XA entry exactly once for a given\nkey_level1, on the first occurrence of that key. The unwind path must\ntherefore call subscribe_event_xa_dealloc() exactly once for it as well.\n\nEnforce that by adding devx_key_in_sub_list() and calling\nsubscribe_event_xa_dealloc() only when the last matching pending entry is\nbeing cleaned up.(CVE-2026-74395)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier\n\nmlx5_ib_alloc_transport_domain() allocates a transport domain and then\nmay fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.\n\nFix this by deallocating the TD when mlx5_ib_enable_lb() returns an\nerror. Also return 0 explicitly in the no-loopback-capability success\nbranch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init().(CVE-2026-74397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()\n\nsnd_usbmidi_akai_output() computes its fill-loop bound\n\n\tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1;\n\nas a signed int, so a small device-advertised bulk-OUT max_transfer\nmakes buf_end negative.  The loop guard then compares the u32\nurb->transfer_buffer_length against that negative int: the usual\narithmetic conversion turns buf_end into a large unsigned value, so the\nguard stays true and each iteration keeps appending SysEx framing and\npayload bytes past the end of the URB transfer buffer, which is only\nmax_transfer bytes long.\n\nA USB device that advertises a tiny bulk-OUT endpoint can therefore\ntrigger an attacker-length- and content-controlled heap out-of-bounds\nwrite when a process writes to the created /dev/snd/midiC*D* node.\n\nReturn early when there is no room for even one SysEx, so the loop is\nnever entered with a bound that would wrap.  The loop is the last\nstatement of the function, so bailing out is equivalent to it not\nrunning.\n\nDiscovered by XBOW, triaged by Baul Lee <(CVE-2026-74499)\n\nIn the Linux kernel, the following vulnerability has been resolved: sctp: keep chunk->transport in step with the list it is queued on. __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport. The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. A SACK that reneges on the TSN clears the flag, and the next SACK reaches inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer().(CVE-2026-74588)\n\nIn the Linux kernel, a deadlock vulnerability has been found in the ceph filesystem. A reader can hang forever in __ceph_get_caps() when the client no longer holds FILE_RD, but local cap state still says that the capability is already wanted (via mds_wanted). One way to trigger this is through MDS cap revocation. If another client performs a conflicting operation, the MDS can revoke FILE_RD from the reader; the next read then has to reacquire FILE_RD. If the cap update that should request FILE_RD never reaches the MDS after cap->mds_wanted was raised, the reader is left holding only non-file caps while local mds_wanted still includes the file read caps, causing the reader to wait indefinitely.(CVE-2026-80527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix OOB read in decode_watchers() via missing bounds check\n\nceph_start_decoding() validates that struct_len bytes remain in the\nbuffer after the encoding header, but accepts struct_len=0 as valid:\nceph_decode_need(p, end, 0, bad) always passes. When a malicious or\ncompromised OSD sends an obj_list_watch_response_t reply with\nstruct_len=0, ceph_start_decoding() returns success with p == end,\nleaving zero bytes guaranteed for subsequent reads.\n\nThe immediately following ceph_decode_32(p) in decode_watchers() has\nno preceding bounds check. With p == end this is a 4-byte read past\nthe validated buffer boundary. The garbage value is then passed\ndirectly to kzalloc_objs() as the watcher count.\n\nThe sibling function decode_watcher() already uses the safe variants\n(ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32)\nafter its own ceph_start_decoding() call. decode_watchers() is the\nonly site that uses the bare variant, confirming an oversight.\n\nFix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end,\n*num_watchers, bad), consistent with the established pattern.\n\nAttacker model: a malicious or compromised OSD in a multi-tenant Ceph\ndeployment (e.g. cloud) can trigger this against any kernel client\nthat calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges\nbeyond OSD session establishment.\n\n[ idryomov: trim changelog ](CVE-2026-80557)","modified":"2026-09-05T15:16:40.900741151Z","published":"2026-09-05T15:04:06Z","upstream":["CVE-2025-40027","CVE-2025-40307","CVE-2026-46208","CVE-2026-52917","CVE-2026-52955","CVE-2026-53199","CVE-2026-53225","CVE-2026-63801","CVE-2026-63913","CVE-2026-63914","CVE-2026-63971","CVE-2026-64089","CVE-2026-64095","CVE-2026-64188","CVE-2026-64450","CVE-2026-64471","CVE-2026-64483","CVE-2026-68155","CVE-2026-68156","CVE-2026-68227","CVE-2026-68425","CVE-2026-72188","CVE-2026-74297","CVE-2026-74302","CVE-2026-74377","CVE-2026-74394","CVE-2026-74395","CVE-2026-74397","CVE-2026-74499","CVE-2026-74588","CVE-2026-80527","CVE-2026-80557"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3702"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40027"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40307"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46208"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52917"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52955"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53199"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53225"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63801"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63913"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63914"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63971"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64089"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64188"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64450"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64471"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64483"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68155"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68156"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68227"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68425"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72188"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74297"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74302"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74377"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74394"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74395"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74397"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74499"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74588"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80527"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80557"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:22.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-331.0.0.232.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","kernel-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","perf-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-331.0.0.232.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-331.0.0.232.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","kernel-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","perf-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-331.0.0.232.oe2203sp4.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3702.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}