{"schema_version":"1.7.2","id":"OESA-2026-3317","modified":"2026-08-13T13:57:18Z","published":"2026-08-13T13:57:18Z","upstream":["CVE-2026-31462","CVE-2026-31576","CVE-2026-31577","CVE-2026-31578","CVE-2026-31716","CVE-2026-43211","CVE-2026-52910","CVE-2026-52989","CVE-2026-53256","CVE-2026-53284","CVE-2026-53369","CVE-2026-53375","CVE-2026-53390","CVE-2026-53399","CVE-2026-63794","CVE-2026-63796","CVE-2026-63807","CVE-2026-63823","CVE-2026-63898","CVE-2026-63940","CVE-2026-64113","CVE-2026-64115","CVE-2026-64178","CVE-2026-64305","CVE-2026-64320","CVE-2026-64322","CVE-2026-64375","CVE-2026-64379","CVE-2026-64380","CVE-2026-64432","CVE-2026-64534","CVE-2026-64539","CVE-2026-64557"],"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\ndrm/amdgpu: prevent immediate PASID reuse case\n\nPASID resue could cause interrupt issue when process\nimmediately runs into hw state left by previous\nprocess exited with the same PASID, it's possible that\npage faults are still pending in the IH ring buffer when\nthe process exits and frees up its PASID. To prevent the\ncase, it uses idr cyclic allocator same as kernel pid's.\n\n(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)(CVE-2026-31462)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: hackrf: fix to not free memory after the device is registered in hackrf_probe()\n\nIn hackrf driver, the following race condition occurs:\n```\n\t\tCPU0\t\t\t\t\t\tCPU1\nhackrf_probe()\n  kzalloc(); // alloc hackrf_dev\n  ....\n  v4l2_device_register();\n  ....\n\t\t\t\t\t\tfd = sys_open("/path/to/dev"); // open hackrf fd\n\t\t\t\t\t\t....\n  v4l2_device_unregister();\n  ....\n  kfree(); // free hackrf_dev\n  ....\n\t\t\t\t\t\tsys_ioctl(fd, ...);\n\t\t\t\t\t\t  v4l2_ioctl();\n\t\t\t\t\t\t    video_is_registered() // UAF!!\n\t\t\t\t\t\t....\n\t\t\t\t\t\tsys_close(fd);\n\t\t\t\t\t\t  v4l2_release() // UAF!!\n\t\t\t\t\t\t    hackrf_video_release()\n\t\t\t\t\t\t      kfree(); // DFB!!\n```\n\nWhen a V4L2 or video device is unregistered, the device node is removed so\nnew open() calls are blocked.\n\nHowever, file descriptors that are already open-and any in-flight I/O-do\nnot terminate immediately; they remain valid until the last reference is\ndropped and the driver's release() is invoked.\n\nTherefore, freeing device memory on the error path after hackrf_probe()\nhas registered dev it will lead to a race to use-after-free vuln, since\nthose already-open handles haven't been released yet.\n\nAnd since release() free memory too, race to use-after-free and\ndouble-free vuln occur.\n\nTo prevent this, if device is registered from probe(), it should be\nmodified to free memory only through release() rather than calling\nkfree() directly.(CVE-2026-31576)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map\n\nThe DAT inode's btree node cache (i_assoc_inode) is initialized lazily\nduring btree operations. However, nilfs_mdt_save_to_shadow_map()\nassumes i_assoc_inode is already initialized when copying dirty pages\nto the shadow map during GC.\n\nIf NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before\nany btree operation has occurred on the DAT inode, i_assoc_inode is\nNULL leading to a general protection fault.\n\nFix this by calling nilfs_attach_btree_node_cache() on the DAT inode\nin nilfs_dat_read() at mount time, ensuring i_assoc_inode is always\ninitialized before any GC operation can use it.(CVE-2026-31577)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: as102: fix to not free memory after the device is registered in as102_usb_probe()\n\nIn as102_usb driver, the following race condition occurs:\n```\n\t\tCPU0\t\t\t\t\t\tCPU1\nas102_usb_probe()\n  kzalloc(); // alloc as102_dev_t\n  ....\n  usb_register_dev();\n\t\t\t\t\t\tfd = sys_open("/path/to/dev"); // open as102 fd\n\t\t\t\t\t\t....\n  usb_deregister_dev();\n  ....\n  kfree(); // free as102_dev_t\n  ....\n\t\t\t\t\t\tsys_close(fd);\n\t\t\t\t\t\t  as102_release() // UAF!!\n\t\t\t\t\t\t    as102_usb_release()\n\t\t\t\t\t\t      kfree(); // DFB!!\n```\n\nWhen a USB character device registered with usb_register_dev() is later\nunregistered (via usb_deregister_dev() or disconnect), the device node is\nremoved so new open() calls fail. However, file descriptors that are\nalready open do not go away immediately: they remain valid until the last\nreference is dropped and the driver's .release() is invoked.\n\nIn as102, as102_usb_probe() calls usb_register_dev() and then, on an\nerror path, does usb_deregister_dev() and frees as102_dev_t right away.\nIf userspace raced a successful open() before the deregistration, that\nopen FD will later hit as102_release() --> as102_usb_release() and access\nor free as102_dev_t again, occur a race to use-after-free and\ndouble-free vuln.\n\nThe fix is to never kfree(as102_dev_t) directly once usb_register_dev()\nhas succeeded. After deregistration, defer freeing memory to .release().\n\nIn other words, let release() perform the last kfree when the final open\nFD is closed.(CVE-2026-31578)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: validate rec->used in journal-replay file record check\n\ncheck_file_record() validates rec->total against the record size but\nnever validates rec->used.  The do_action() journal-replay handlers read\nrec->used from disk and use it to compute memmove lengths:\n\n  DeleteAttribute:    memmove(attr, ..., used - asize - roff)\n  CreateAttribute:    memmove(..., attr, used - roff)\n  change_attr_size:   memmove(..., used - PtrOffset(rec, next))\n\nWhen rec->used is smaller than the offset of a validated attribute, or\nlarger than the record size, these subtractions can underflow allowing\nus to copy huge amounts of memory in to a 4kb buffer, generally\nconsidered a bad idea overall.\n\nThis requires a corrupted filesystem, which isn't a threat model the\nkernel really needs to worry about, but checking for such an obvious\nout-of-bounds value is good to keep things robust, especially on journal\nreplay\n\nFix this up by bounding rec->used correctly.\n\nThis is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds\nread in DeleteIndexEntryRoot") which checked different values in this\nsame switch statement.(CVE-2026-31716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix pci_slot_trylock() error handling\n\nCommit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")\ndelegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in\npci_slot_trylock(), but it forgets to remove the corresponding\npci_dev_unlock() when pci_bus_trylock() fails.\n\nBefore a4e772898f8b, the code did:\n\n  if (!pci_dev_trylock(dev)) /* <- lock bridge device */\n    goto unlock;\n  if (dev->subordinate) {\n    if (!pci_bus_trylock(dev->subordinate)) {\n      pci_dev_unlock(dev);   /* <- unlock bridge device */\n      goto unlock;\n    }\n  }\n\nAfter a4e772898f8b the bridge-device lock is no longer taken, but the\npci_dev_unlock(dev) on the failure path was left in place, leading to the\nbug.\n\nThis yields one of two errors:\n\n  1. A warning that the lock is being unlocked when no one holds it.\n  2. An incorrect unlock of a lock that belongs to another thread.\n\nFix it by removing the now-redundant pci_dev_unlock(dev) on the failure\npath.\n\n[Same patch later posted by Keith at\nhttps://patch.msgid.link/(CVE-2026-43211)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Free reuseport cBPF prog after RCU grace period.\n\nEulgyu Kim reported the splat below with a repro. [0]\n\nThe repro sets up a UDP reuseport group with a cBPF prog and\nreplaces it with a new one while another thread is sending\na UDP packet to the group.\n\nThe reuseport prog is freed by sk_reuseport_prog_free().\nbpf_prog_put() is called for "e"BPF prog to destruct through\nmultiple stages while cBPF prog is freed immediately by\nbpf_release_orig_filter() and bpf_prog_free().\n\nIf a reuseport prog is detached from the setsockopt() path\n(reuseport_attach_prog() or reuseport_detach_prog()),\nsk_reuseport_prog_free() is called without waiting for RCU\nreaders to complete, resulting in various bugs.\n\nLet's defer freeing the reuseport cBPF prog after one RCU\ngrace period.\n\nNote "e"BPF prog is safe as is unless the fast path starts\nto touch fields destroyed in bpf_prog_put_deferred() and\n__bpf_prog_put_noref().\n\n[0]:\nBUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596\nRead of size 4 at addr ffffc9000051e004 by task slowme/10208\nCPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full)\nHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n <IRQ>\n dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596\n udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495\n __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723\n __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752\n __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752\n ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207\n ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241\n NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318\n NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318\n __netif_receive_skb_one_core net/core/dev.c:6181 [inline]\n __netif_receive_skb net/core/dev.c:6294 [inline]\n process_backlog+0xaa4/0x1960 net/core/dev.c:6645\n __napi_poll+0xae/0x340 net/core/dev.c:7709\n napi_poll net/core/dev.c:7772 [inline]\n net_rx_action+0x5d7/0xf50 net/core/dev.c:7929\n handle_softirqs+0x22b/0x870 kernel/softirq.c:622\n do_softirq+0x76/0xd0 kernel/softirq.c:523\n </IRQ>\n <TASK>\n __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline]\n __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890\n neigh_output include/net/neighbour.h:556 [inline]\n ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237\n NF_HOOK_COND include/linux/netfilter.h:307 [inline]\n ip_output+0x29f/0x450 net/ipv4/ip_output.c:438\n ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508\n udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195\n udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg net/socket.c:742 [inline]\n __sys_sendto+0x554/0x680 net/socket.c:2206\n __do_sys_sendto net/socket.c:2213 [inline]\n __se_sys_sendto net/socket.c:2209 [inline]\n __x64_sys_sendto+0xde/0x100 net/socket.c:2209\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x415a2d\nCode: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d\nRDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003\nRBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010\nR10: 0000000000000000 R11: \n---truncated---(CVE-2026-52910)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers\n\nCurrently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds\nPDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue)\nand returns early. However, because the function returns void, the\ncallers are entirely unaware that a fatal error has occurred and\nthat the cmd->recv_msg.msg_iter was left uninitialized.\n\nCallers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly\noverwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA\nConsequently, the socket receiving loop may attempt to read incoming\nnetwork data into the uninitialized iterator.\n\nFix this by shifting the error handling responsibility to the callers.(CVE-2026-52989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()\n\nrfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock,\nbut returns the selected listener after dropping that lock without\ntaking a reference. rfcomm_connect_ind() then locks the listener,\nqueues a child socket on it, and may notify it after unlocking it.\n\nThe buggy scenario involves two paths, with each column showing the\norder within that path:\n\nrfcomm_connect_ind():            listener close:\n  1. Find parent in              1. close() enters\n     rfcomm_get_sock_by_channel()   rfcomm_sock_release().\n  2. Drop rfcomm_sk_list.lock    2. rfcomm_sock_shutdown()\n     without pinning parent.        closes the listener.\n  3. Call lock_sock(parent) and  3. rfcomm_sock_kill()\n     bt_accept_enqueue(parent,      unlinks and puts parent.\n     sk, true).\n  4. Read parent flags and may   4. parent can be freed.\n     call sk_state_change().\n\nIf close wins the race, parent can be freed before\nrfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the\ndeferred-setup callback.\n\nTake a reference on the listener before leaving rfcomm_sk_list.lock.\nAfter lock_sock() succeeds, recheck that it is still in BT_LISTEN\nbefore queueing a child, cache the deferred-setup bit while the parent\nis locked, and drop the reference after the last parent use.\n\nKASAN reported a slab-use-after-free in lock_sock_nested() from\nrfcomm_connect_ind(), with the freeing stack going through\nrfcomm_sock_kill() and rfcomm_sock_release().(CVE-2026-53256)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: only release the dirty pages io tree after successful writes\n\n[WARNING]\nWith extra warning on dirty extent buffers at umount (aka, the next\npatch in the series), test case generic/388 can trigger the following\nwarning about dirty extent buffers at unmount time:\n\n  BTRFS critical (device dm-2 state E): emergency shutdown\n  BTRFS error (device dm-2 state E): error while writing out transaction: -30\n  BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction.\n  BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30)\n  BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem\n  BTRFS info (device dm-2 state EA): forced readonly\n  BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c\n  ------------[ cut here ]------------\n  WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368\n  CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G           OE       7.1.0-rc1-custom+ #372 PREEMPT(full)  2de38db8d1deae71fde295430a0ff3ab98ccf596\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n  RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs]\n  Call Trace:\n   <TASK>\n   close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]\n   generic_shutdown_super+0x89/0x1a0\n   kill_anon_super+0x16/0x40\n   btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]\n   deactivate_locked_super+0x2d/0xb0\n   cleanup_mnt+0xdc/0x140\n   task_work_run+0x5a/0xa0\n   exit_to_user_mode_loop+0x123/0x4b0\n   do_syscall_64+0x243/0x7c0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   </TASK>\n  ---[ end trace 0000000000000000 ]---\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7\n  BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7\n\nI'm using a stripped down version, which seems to trigger the warning\nmore reliably:\n\n  _fsstress_pid=""\n  workload()\n  {\n  \tdmesg -C\n  \tmkfs.btrfs -f -K $dev > /dev/null\n  \techo 1 > /sys/kernel/debug/clear_warn_once\n  \tmount $dev $mnt\n  \t$fsstress -w -n 1024 -p 4 -d $mnt &\n  \t_fsstress_pid=$!\n  \tsleep 0\n  \t$godown $mnt\n  \tpkill --echo -PIPE fsstress > /dev/null\n  \twait $_fsstress_pid\n  \tunset _fsstress_pid\n  \tumount $mnt\n\n  \tif dmesg | grep -q "WARNING"; then\n  \t\tfail\n  \tfi\n  }\n\n  for (( i = 0; i < $runtime; i++ )); do\n  \techo "=== $i/$runtime ==="\n  \tworkload\n  done\n\n[CAUSE]\nInside btrfs_write_and_wait_transaction(), we first try to write all\ndirty ebs, then wait for them to finish.\n\nAfter that we call btrfs_extent_io_tree_release() to free all\nextent states from dirty_pages io tree.\n\nHowever if we hit an error from btrfs_write_marked_extent(), then we\nstill call btrfs_extent_io_tree_release() to clear that dirty_pages io\ntree, which may contain dirty records that we haven't yet submitted.\n\nFurthermore, the later transaction cleanup path will utilize that\ndirty_pages io tree to properly cleanup those dirty ebs, but since it's\nalready empty, no dirty ebs are properly cleaned up, thus will later\ntrigger the warnings inside invalidate_btree_folios().\n---truncated---(CVE-2026-53284)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: reject descriptors with oversized CRC length\n\nudf_read_tagged() skips CRC verification when descCRCLength +\nsizeof(struct tag) exceeds the block size.  A crafted UDF image can\nset descCRCLength to an oversized value to bypass CRC validation\nentirely; the descriptor is then accepted based solely on the 8-bit\ntag checksum, which is trivially recomputable.\n\nReject such descriptors instead of silently accepting them.  A\nlegitimate single-block descriptor should never have a CRC length that\nexceeds the block.(CVE-2026-53369)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/vce: Prevent partial address patches\n\nIn the case that only one of lo/hi is valid, the patching could result\nin a bad address written to in FW.(CVE-2026-53375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix out-of-bounds read in smb_check_perm_dacl()\n\nThe permission-check ACE walk in smb_check_perm_dacl() validates the ACE\nheader size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it\nnever checks that ace->size is actually large enough to contain\nnum_subauth sub-authorities before compare_sids() dereferences them.\n\nCIFS_SID_BASE_SIZE covers the SID header up to but excluding the\nsub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header,\nso the existing guards only guarantee the 8-byte SID base, i.e. zero\nsub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for\ni < min(local_sid->num_subauth, ace->sid.num_subauth). The local\ncomparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid()\nresult) always have at least one sub-authority, and an attacker controls\nthe ACE revision and authority bytes (which lie within the in-bounds SID\nbase), so they can match one of those SIDs and force the sub_auth read.\n\nA crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of\nthe security descriptor therefore causes a heap out-of-bounds read of up\nto SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd\nallocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr()\ninto a buffer sized exactly to the on-disk data (kzalloc(sd_size) in\nndr_decode_v4_ntacl()), so the read lands past the allocation. The\nmalformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL\nis not normalised before being written to the security.NTACL xattr) and\nthe read fires on a subsequent SMB2_CREATE access check, making this\nreachable by an authenticated client on a share that uses ACL xattrs.\n\nAdd the missing num_subauth-versus-ace_size check, mirroring the\nidentical guards already present in the sibling parsers parse_dacl() and\nsmb_inherit_dacl().(CVE-2026-53390)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: release layout stid on setlease failure\n\nnfs4_alloc_stid() publishes the new stid into cl->cl_stateids via\nidr_alloc_cyclic() under cl_lock before returning to\nnfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then\nfails, the error path frees the layout stateid directly with\nkmem_cache_free() without ever calling idr_remove(), leaving the\nIDR slot pointing at freed slab memory. Any subsequent IDR walker\n(states_show, client teardown) dereferences the dangling pointer.\n\nThe correct teardown for an IDR-published stid is nfs4_put_stid(),\nwhich removes the IDR slot under cl_lock, dispatches sc_free\n(nfsd4_free_layout_stateid) to release ls->ls_file via\nnfsd4_close_layout(), and drops the nfs4_file reference in its\ntail.\n\nA second issue blocks that switch: nfsd4_free_layout_stateid()\nunconditionally inspects ls->ls_fence_work via\ndelayed_work_pending() under ls_lock, but\nINIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only\nafter the setlease call. On the setlease-failure path the\ndestructor would touch an uninitialized delayed_work.\n\n    nfsd4_alloc_layout_stateid()\n      nfs4_alloc_stid()           /* idr_alloc_cyclic under cl_lock */\n      nfsd4_layout_setlease()     /* fails */\n        nfs4_put_stid()\n          nfsd4_free_layout_stateid()\n            delayed_work_pending(&ls->ls_fence_work)  /* needs INIT */\n            nfsd4_close_layout()  /* nfsd_file_put(ls->ls_file) */\n          put_nfs4_file()\n\nFix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK\ninitialization above the nfsd4_layout_setlease() call, and replace\nthe manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup\nwith a single nfs4_put_stid(stp).(CVE-2026-53399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path\n\nIn sev_dbg_crypt(), the per-iteration transfer length is bounded by\nthe source page offset (PAGE_SIZE - s_off) but not by the destination\npage offset (PAGE_SIZE - d_off).  When d_off > s_off, the encrypt\npath (__sev_dbg_encrypt_user) performs a read-modify-write using a\nsingle-page intermediate buffer (dst_tpage):\n\n  1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16)\n     before issuing the PSP command.  If len + (d_off & 15) > PAGE_SIZE,\n     the PSP writes beyond the end of the 4096-byte dst_tpage allocation.\n\n  2. The subsequent memcpy()/copy_from_user() into\n     page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows\n     by up to 15 bytes under the same condition.\n\nTrigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE -\nthe PSP is instructed to write round_up(4097, 16) = 4112 bytes to\na 4096-byte buffer.\n\nFix by also bounding len by (PAGE_SIZE - d_off), the same check that\nsev_send_update_data() already performs for its single-page guest\nregion.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd]\n Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214\n\n CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G     U  W           7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY\n Tainted: [U]=USER, [W]=WARN\n Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x54/0x70\n  print_report+0xbc/0x260\n  kasan_report+0xa2/0xd0\n  kasan_check_range+0x25f/0x2c0\n  __asan_memcpy+0x40/0x70\n  sev_dbg_crypt+0x993/0xd10 [kvm_amd]\n  sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd]\n  kvm_vm_ioctl+0x65d/0x6d0 [kvm]\n  __se_sys_ioctl+0xb2/0x100\n  do_syscall_64+0xe8/0x870\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n  </TASK>\n\n The buggy address belongs to the physical page:\n page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb\n memcg:ff11000112827d82\n flags: 0x1400000000000000(node=1|zone=1)\n raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000\n raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n  ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n                    ^\n  ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n  ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ==================================================================\n Disabling lock debugging due to kernel taint\n\n[sean: add sample KASAN splat, Fixes, and stable@](CVE-2026-63794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: reject oversized group bitmap descriptors\n\nocfs2_validate_gd_parent() only bounds bg_bits against the parent\nallocator's chain geometry.  A malicious descriptor can still claim a\nbg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in\nthe group descriptor block, so later bitmap scans and bit updates can run\npast bg_bitmap.\n\nAdd a physical-cap check based on ocfs2_group_bitmap_size() for the parent\nallocator type and reject descriptors whose bg_size or bg_bits exceed that\ncapacity.  Keep the existing chain geometry check so both the on-disk\nbitmap layout and the allocator metadata must agree before the descriptor\nis used.\n\nValidation reproduced this kernel report:\nKASAN use-after-free in _find_next_bit+0x7f/0xc0\nRead of size 8\nCall trace:\n  dump_stack_lvl+0x66/0xa0 (?:?)\n  print_report+0xd0/0x630 (?:?)\n  _find_next_bit+0x7f/0xc0 (?:?)\n  srso_alias_return_thunk+0x5/0xfbef5 (?:?)\n  __virt_addr_valid+0x188/0x2f0 (?:?)\n  kasan_report+0xe4/0x120 (?:?)\n  ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375)\n  ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457)\n  ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86)\n  ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786)\n  ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886)\n  get_page_from_freelist+0x70e/0x2370 (?:?)\n  lock_release+0xc6/0x290 (?:?)\n  do_raw_spin_unlock+0x9a/0x100 (?:?)\n  kasan_unpoison+0x27/0x60 (?:?)\n  __bfs+0x147/0x240 (?:?)\n  get_page_from_freelist+0x83d/0x2370 (?:?)\n  ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96)\n  sched_domains_numa_masks_clear+0x70/0xd0 (?:?)\n  check_irq_usage+0xe8/0xb70 (?:?)\n  __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497)\n  check_path+0x24/0x50 (?:?)\n  rcu_is_watching+0x20/0x50 (?:?)\n  check_prev_add+0xfd/0xd00 (?:?)\n  ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?)\n  __folio_batch_add_and_move+0x1f5/0x3d0 (?:?)\n  ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?)\n  filemap_add_folio+0x105/0x1f0 (?:?)\n  ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043)\n  ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?)\n  down_write+0xf5/0x180 (?:?)\n  ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?)\n  __mark_inode_dirty+0x758/0x9a0 (?:?)\n  inode_to_bdi+0x41/0x90 (?:?)\n  balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?)\n  generic_perform_write+0x252/0x440 (?:?)\n  mnt_put_write_access_file+0x16/0x70 (?:?)\n  file_update_time_flags+0xe4/0x200 (?:?)\n  ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?)\n  lock_acquire+0x184/0x2f0 (?:?)\n  ksys_write+0xd2/0x170 (?:?)\n  apparmor_file_permission+0xf5/0x310 (?:?)\n  read_zero+0x8d/0x140 (?:?)\n  lock_is_held_type+0x8f/0x100 (?:?)(CVE-2026-63796)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level\n\nWhen recovering hugepages in the shadow MMU, verify that the base gfn of\nthe shadow page is actually contained within the target memslot, *before*\nquerying the max mapping level given the shadow page's gfn.  Failure to\npre-check the validity of the gfn can lead to an out-of-bounds access to\nthe slot's lpage_info (which typically manifests as a host #PF because the\nlpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its\nPTEs) that extends "below" the bounds of a memslot.\n\nWhen faulting in memory for a guest, and the size of the guest mapping is\ngreater than KVM's (current) max mapping, then KVM will create a "direct"\nshadow page (direct in that there are no gPTEs to shadow, and so the target\ngfn is a direct calculation given the base gfn of the shadow page).  The\nhugepage recovery flow looks for such direct shadow pages, as forcing 4KiB\nmappings when dirty logging generates the guest > host mapping size case.\nWhen the 4KiB restriction is lifted, then KVM can replace the shadow page\nwith a hugepage.\n\nBut if KVM originally used a smaller mapping than the guest because the\nrange of memory covered by the guest hugepage exceeds the bounds of a\nmemslot, then KVM will link a direct shadow page with a gfn that is outside\nthe bounds of the memslot being used to fault in memory.  The rmap entry\nadded for the leaf mapping is correct and within bounds, but the gfn of the\nleaf SPTE's parent shadow page will be out of bounds.\n\n  BUG: unable to handle page fault for address: ffffc90000806ffc\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0\n  Oops: Oops: 0000 [#1] SMP\n  CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm]\n  Call Trace:\n   <TASK>\n   kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm]\n   kvm_set_memslot+0x1ee/0x590 [kvm]\n   kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm]\n   kvm_vm_ioctl+0x9bf/0x15d0 [kvm]\n   __x64_sys_ioctl+0x8a/0xd0\n   do_syscall_64+0xb7/0xbb0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n  RIP: 0033:0x7f21c0f1a9bf\n   </TASK>\n\nDon't bother pre-checking the bounds of the potential hugepage, i.e. don't\ncheck that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also\nwithin the memslot, as the checks performed by kvm_mmu_max_mapping_level()\nare a superset of the basic bounds checks.  I.e. pre-checking the full\nrange would be a dubious micro-optimization.(CVE-2026-63807)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkeys: Pin request_key_auth payload in instantiate paths\n\nA: request_key()       B: KEYCTL_INSTANTIATE_IOV\n================       =========================\n\ncreate auth key\nstore rka in auth key\nwait for helper\n                       get auth key\n                       load rka from auth key\n                       copy user payload\n                       sleep on #PF\n\nhelper completed\ndetach and free rka\ndestroy auth key\n                       wake up\n                       use rka->target_key\n                       **USE-AFTER-FREE**\n\nGive request_key_auth payloads a refcount.  Take a payload reference while\nauthkey->sem stabilizes the payload and revocation state.  Hold that\nreference across the instantiate and reject paths.  Drop the auth key\nowning reference from revoke and destroy.\n\n[jarkko: Replaced the first two paragraphs of text with an actual\n concurrency scenario.](CVE-2026-63823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: mct_u232: fix memory corruption with small endpoint\n\nThe driver overrides the maximum transfer size for a specific device\nwhich only accepts 16 byte packets for its 32 byte bulk-out endpoint.\n\nMake sure to never increase the maximum transfer size to prevent slab\ncorruption should a malicious device report a smaller endpoint max\npacket size than expected.(CVE-2026-63898)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SEV: Ignore Port I/O requests of length '0'\n\nExplicitly ignore Port I/O requests of length '0' (or count '0'), so that\nsetting up the software scratch area (and other code) doesn't have to\nworry about underflowing the length, and to allow for WARNing on trying\nto configure the scratch area with len==0.(CVE-2026-63940)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix use-after-free in VEPA multicast source pruning\n\nixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's\nown address (VEPA multicast workaround) by freeing the skb and\ncontinuing to the next descriptor:\n\n    dev_kfree_skb_irq(skb);\n    continue;\n\nThe skb pointer is declared outside the while loop and persists across\niterations.  Because the continue skips the "skb = NULL" reset at the\nbottom of the loop, the next iteration enters the "else if (skb)" path\nand calls ixgbevf_add_rx_frag() on the freed skb, dereferencing\nskb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.\n\nThe sibling driver iavf already handles this correctly by nulling the\npointer before continuing.  Apply the same pattern here.\n\nI do not have ixgbevf hardware; the bug was found by static analysis\n(scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool\ncorroboration with the highest score in the scan).  The UAF was confirmed\nunder KASAN by loading a test module that reproduces the exact code\npattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):\n\n  BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000\n  Read of size 8 at addr 000000006163ae78 by task insmod/30\n  freed 208-byte region [000000006163adc0, 000000006163ae90)\n\nQEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF\ndriver does not include the VEPA source pruning path, so a full\nend-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/vmci: fix UAF when peer resets connection during handshake\n\nvmci_transport_recv_connecting_server() returned err = 0 for a peer\nRST in its default switch arm:\n\n\terr = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;\n\nThat made vmci_transport_recv_listen() skip vsock_remove_pending(),\nleaving the pending socket on the listener's pending_links with\nsk_state = TCP_CLOSE while destroy: still dropped the explicit\nreference taken before schedule_delayed_work().\n\nOne second later vsock_pending_work() observed is_pending=true and\nperformed full cleanup: vsock_remove_pending() then the two trailing\nsock_put(sk) calls -- the first reached refcount 0 and __sk_freed\nthe socket, and the second wrote into the freed object:\n\n  BUG: KASAN: slab-use-after-free in refcount_warn_saturate\n  Write of size 4 at addr ffff88800b1cac80 by task kworker\n  Workqueue: events vsock_pending_work\n\nTreat peer RST like any other unexpected packet type (err = -EINVAL).\nAll destroy: arms now return err < 0, so vmci_transport_recv_listen()\nremoves pending from pending_links synchronously and\nvsock_pending_work() takes the is_pending=false / !rejected branch,\ndropping only its own work reference.  This also closes the\nmulti-packet race Sashiko reported on v2: pending is removed from\nthe list before any subsequent packet can find it.\n\nThe pre-existing sk_acceptq_removed() gap on the err < 0 path of\nvmci_transport_recv_listen() that Sashiko also noted is not\nintroduced or changed by this patch.\n\nTested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched.(CVE-2026-64115)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bnep: Fix UAF read of dev->name\n\nbnep_add_connection() needs to keep holding the bnep_session_sem while\nreading dev->name (just like bnep_get_connlist() does); otherwise the\nbnep_session() thread can concurrently free the net_device, which can for\nexample be triggered by a concurrent bnep_del_connection().\n\n(This UAF is fairly uninteresting from a security perspective;\ncalling bnep_add_connection() requires passing a capable(CAP_NET_ADMIN)\ncheck. It also requires completely tearing down a netdev during a fairly\ntight race window.)(CVE-2026-64178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - protect service table iterations with service_lock\n\nThe service_table list is protected by service_lock when entries are\nadded or removed (in adf_service_add() and adf_service_remove()), but\nseveral functions iterate over the list without holding this lock.\n\nA concurrent adf_service_register() or adf_service_unregister() call\ncould modify the list during traversal, leading to list corruption or\na use-after-free.\n\nFix this by holding service_lock across all list_for_each_entry()\niterations of service_table in adf_dev_init(), adf_dev_start(),\nadf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(),\nadf_dev_restarted_notify(), and adf_error_notifier().\n\nThe lock ordering is safe: callers of the static helpers (adf_dev_up()\nand adf_dev_down()) acquire state_lock before service_lock, and no\nevent_hld callback or service_lock holder ever acquires state_lock in\nthe reverse order.(CVE-2026-64305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page\n\nnvmet_execute_disc_get_log_page() validates only the dword alignment\nof the host-supplied Log Page Offset (lpo).  The 64-bit offset is then\nadded to a small kzalloc'd buffer that holds the discovery log page\nand the result is passed straight to nvmet_copy_to_sgl(), which\nmemcpy()s data_len bytes out to the host with no source-side bound\ncheck:\n\n    u64 offset      = nvmet_get_log_page_offset(req->cmd);  /* 64-bit host */\n    size_t data_len = nvmet_get_log_page_len(req->cmd);     /* 32-bit host */\n    ...\n    if (offset & 0x3) { ... }                               /* only check */\n    ...\n    alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);\n    buffer = kzalloc(alloc_len, GFP_KERNEL);\n    ...\n    status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);\n\nThe Discovery controller is unauthenticated -- nvmet_host_allowed()\nreturns true unconditionally for the discovery subsystem -- so the call\nis reachable pre-authentication by any TCP/RDMA/FC peer that can reach\nthe nvmet target.  With a discovery log page of ~1 KiB, an attacker\nrequesting up to 4 KiB starting at offset == alloc_len reads the next\nslab page out and gets its content returned over the fabric (an\nempirical run on a default nvmet-tcp loopback target leaked 81\ncanonical kernel pointers in one Get Log Page response).  Pointing the\noffset at unmapped kernel memory faults the in-kernel memcpy and\ncrashes (or panics, on panic_on_oops=1) the target host instead.\n\nThe attacker-controlled source-side offset pattern\n"nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique\nto nvmet_execute_disc_get_log_page in the entire nvmet codebase: every\nother Get Log Page handler in admin-cmd.c either ignores lpo (and\nsilently starts every response at offset 0) or tracks a local\ndestination offset with a fixed source pointer.\n\nValidate the host-supplied offset against the log page size, cap the\ncopy length to what is actually available, and zero-fill any remainder\nof the host transfer buffer.  The zero-fill matches the existing\nshort-response pattern in nvmet_execute_get_log_changed_ns()\n(admin-cmd.c) and prevents leaking transport SGL contents when the\nhost asks for more bytes than the log page contains.(CVE-2026-64320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: validate sparing table length as an entry count, not a byte count\n\nudf_load_sparable_map() accepts a sparing table when\n\n\tsizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize\n\nis false, i.e. it treats reallocationTableLen as a number of BYTES that\nmust fit in the block.  But the table is walked as an array of 8-byte\nsparingEntry elements:\n\n\tfor (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {\n\t\tstruct sparingEntry *entry = &st->mapEntry[i];\n\t\t... entry->origLocation ...\n\t}\n\nin udf_get_pblock_spar15() and udf_relocate_blocks().  A\nreallocationTableLen of N therefore passes the check whenever\nsizeof(*st) + N <= blocksize, yet the consumers index\nsizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the\nblock.  On a crafted UDF image this is an out-of-bounds read in\nudf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the\nsame length to udf_update_tag(), whose crc_itu_t() reads far past the\nblock, and its memmove() through st->mapEntry[] is an out-of-bounds\nwrite.\n\nValidate reallocationTableLen as the entry count it is, with\nstruct_size().(CVE-2026-64322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nproc: protect ptrace_may_access() with exec_update_lock (FD links)\n\nproc_pid_get_link() and proc_pid_readlink() currently look up the task from\nthe pid once, then do the ptrace access check on that task, then look up\nthe task from the pid a second time to do the actual access.\nThat's racy in several ways.\n\nTo fix it, pass the task to the ->proc_get_link() handler, and instead of\nproc_fd_access_allowed(), introduce a new helper call_proc_get_link() that\nlooks up and locks the task, does the access check, and calls\n->proc_get_link().(CVE-2026-64375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: mask server-provided mode to 07777 in modefromsid\n\nWhen modefromsid is active, parse_dacl() applies the server-provided\nsub_auth[2] value from the NFS mode SID to cf_mode without masking to\n07777. Apply the correct masking, same as in the read path.(CVE-2026-64379)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: harden POSIX SID length parsing\n\nposix_info_sid_size() reads sid[1] to obtain the subauthority count,\nbut its existing boundary check still accepts buffers with only one\nremaining byte. Require two bytes before reading sid[1] so all client\npaths that reuse the helper reject truncated POSIX SIDs safely.(CVE-2026-64380)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns\n\nIn the analysis pass of $LogFile journal replay, log_replay() copies\nLCNs from each action log record into an existing Dirty Page Table\n(DPT) entry without bounding the destination index. A crafted NTFS\nimage with DPT entry lcns_follow=1 and an action log record with\nlcns_follow=2 produces a kernel slab out-of-bounds write at mount\ntime:\n\n  BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60\n  Write of size 8 at addr ffff8880095e1040 by task mount\n\nTwo attacker-controlled fields can drive j+i past the allocated\npage_lcns[] array:\n\n  1. dp->lcns_follow (capacity) can be smaller than lrh->lcns_follow.\n  2. lrh->target_vcn may be smaller than dp->vcn, making the u64\n     subtraction wrap to a huge size_t.\n\nValidate target VCN delta and per-record LCN count against the\nDPT entry capacity, bail via the existing out: cleanup label with\n-EINVAL.\n\nThis mirrors the bounds-check pattern added in commit b2bc7c44ed17\n("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot")\nand commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in\njournal-replay file record check").(CVE-2026-64432)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path\n\nIn nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected,\nnvmet_req_uninit() is called unconditionally. However, if the command\narrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init()\nhad returned false and percpu_ref_tryget_live() was never executed. The\nunconditional percpu_ref_put() inside nvmet_req_uninit() then causes a\nrefcount underflow, leading to a WARNING in\npercpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and\neventually a permanent workqueue deadlock.\n\nCheck cmd->flags & NVMET_TCP_F_INIT_FAILED before calling\nnvmet_req_uninit(), matching the existing pattern in\nnvmet_tcp_execute_request().(CVE-2026-64534)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix stack OOB write when prepending the Flags AD\n\neir_create_adv_data() builds the advertising data into a fixed-size\nbuffer ("size", 31 for the legacy path). It may prepend a 3-byte "Flags"\nAD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies\nthe per-instance data without checking that it still fits:\n\n\tmemcpy(ptr, adv->adv_data, adv->adv_data_len);\n\ntlv_data_max_len() only reserves those 3 bytes when the user-supplied\nflags carry a managed-flags bit, so an instance added with flags == 0 is\naccepted with adv_data_len up to the full buffer. At advertise time the\nflags are still prepended, and the memcpy() writes 3 + adv_data_len\nbytes into the size-byte buffer:\n\n  BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)\n  Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65\n  Workqueue: hci0 hci_cmd_sync_work\n   __asan_memcpy (mm/kasan/shadow.c:106)\n   eir_create_adv_data (net/bluetooth/eir.c:301)\n   hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)\n   hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)\n   hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)\n  This frame has 1 object:\n   [32, 64) 'cp'\n\nThe "Flags" structure is added by the kernel, not requested by\nuserspace, so only prepend it when it fits together with the instance\nadvertising data; when there is no room for both, drop the flags rather\nthan the user-provided data.\n\nReachable by a local user with CAP_NET_ADMIN owning an LE-only\ncontroller on the legacy advertising path.(CVE-2026-64539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()\n\nl2cap_sock_new_connection_cb() returned l2cap_pi(sk)->chan after\nrelease_sock(parent). Once the parent lock is dropped the newly\nenqueued child socket sk is reachable via the accept queue, so another\ntask can accept and free it before the callback dereferences sk,\nresulting in a use-after-free.\n\nRework the ->new_connection() op so the core, rather than the callback,\nowns the child channel's lifetime. The op now receives a pre-allocated\nnew_chan and returns an errno instead of allocating and returning a\nchannel. l2cap_new_connection() allocates the child channel and links\nit into the conn list via __l2cap_chan_add() before invoking the\ncallback, so the conn-list reference keeps the channel alive once\nrelease_sock(parent) exposes the socket to other tasks.\n\nChannel configuration that was duplicated in l2cap_sock_init() and the\nvarious new_connection callbacks is consolidated into\nl2cap_chan_set_defaults(), which now inherits from the parent channel\nwhen one is supplied.(CVE-2026-64557)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-328.0.0.229.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","kernel-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","perf-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-328.0.0.229.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-328.0.0.229.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","kernel-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","perf-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-328.0.0.229.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3317"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31462"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31576"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31577"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31578"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31716"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43211"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52910"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52989"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53256"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53284"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53369"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53375"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53390"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53399"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63794"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63796"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63807"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63823"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63898"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63940"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64113"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64115"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64178"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64305"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64320"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64322"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64375"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64379"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64380"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64432"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64534"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64539"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64557"}],"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}],"database_specific":{"severity":"Critical"}}