{"schema_version":"1.7.2","id":"OESA-2026-2930","modified":"2026-07-09T12:53:12Z","published":"2026-07-09T12:53:12Z","upstream":["CVE-2026-43052","CVE-2026-43110","CVE-2026-43111","CVE-2026-43206","CVE-2026-45892","CVE-2026-45899","CVE-2026-45912","CVE-2026-52923","CVE-2026-52943","CVE-2026-52963","CVE-2026-52970","CVE-2026-52986","CVE-2026-52991","CVE-2026-52998","CVE-2026-53002","CVE-2026-53049","CVE-2026-53072","CVE-2026-53115","CVE-2026-53194","CVE-2026-53195","CVE-2026-53208","CVE-2026-53236","CVE-2026-53238","CVE-2026-53245","CVE-2026-53249","CVE-2026-53252","CVE-2026-53266","CVE-2026-53268","CVE-2026-53269","CVE-2026-53270","CVE-2026-53275","CVE-2026-53357"],"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\nwifi: mac80211: check tdls flag in ieee80211_tdls_oper\n\nWhen NL80211_TDLS_ENABLE_LINK is called, the code only checks if the\nstation exists but not whether it is actually a TDLS station. This\nallows the operation to proceed for non-TDLS stations, causing\nunintended side effects like modifying channel context and HT\nprotection before failing.\n\nAdd a check for sta->sta.tdls early in the ENABLE_LINK case, before\nany side effects occur, to ensure the operation is only allowed for\nactual TDLS peers.(CVE-2026-43052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: validate bsscfg indices in IF events\n\nbrcmf_fweh_handle_if_event() validates the firmware-provided interface\nindex before it touches drvr->iflist[], but it still uses the raw\nbsscfgidx field as an array index without a matching range check.\n\nReject IF events whose bsscfg index does not fit in drvr->iflist[]\nbefore indexing the interface array.\n\n[add missing wifi prefix](CVE-2026-43110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: roccat: fix use-after-free in roccat_report_event\n\nroccat_report_event() iterates over the device->readers list without\nholding the readers_lock. This allows a concurrent roccat_release() to\nremove and free a reader while it's still being accessed, leading to a\nuse-after-free.\n\nProtect the readers list traversal with the readers_lock mutex.(CVE-2026-43111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix out-of-bounds write in kfd_event_page_set()\n\nThe kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8\nbytes via memset without checking the buffer size parameter. This allows\nunprivileged userspace to trigger an out-of bounds kernel memory write\nby passing a small buffer, leading to  potential privilege\nescalation.(CVE-2026-43206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: drop extent cache after doing PARTIAL_VALID1 zeroout\n\nWhen splitting an unwritten extent in the middle and converting it to\ninitialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and\nEXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent.\n\nAssume we have an unwritten file and buffered write in the middle of it\nwithout dioread_nolock enabled, it will allocate blocks as written\nextent.\n\n       0  A      B  N\n       [UUUUUUUUUUUU] on-disk extent      U: unwritten extent\n       [UUUUUUUUUUUU] extent status tree\n       [--DDDDDDDD--]                     D: valid data\n          |<-  ->| ----> this range needs to be initialized\n\next4_split_extent() first try to split this extent at B with\nEXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but\next4_split_extent_at() failed to split this extent due to temporary lack\nof space. It zeroout B to N and leave the entire extent as unwritten.\n\n       0  A      B  N\n       [UUUUUUUUUUUU] on-disk extent\n       [UUUUUUUUUUUU] extent status tree\n       [--DDDDDDDDZZ]                     Z: zeroed data\n\next4_split_extent() then try to split this extent at A with\nEXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and\nleave an written extent from A to N.\n\n       0  A      B  N\n       [UUWWWWWWWWWW] on-disk extent      W: written extent\n       [UUUUUUUUUUUU] extent status tree\n       [--DDDDDDDDZZ]\n\nFinally ext4_map_create_blocks() only insert extent A to B to the extent\nstatus tree, and leave an stale unwritten extent in the status tree.\n\n       0  A      B  N\n       [UUWWWWWWWWWW] on-disk extent      W: written extent\n       [UUWWWWWWWWUU] extent status tree\n       [--DDDDDDDDZZ]\n\nFix this issue by always cached extent status entry after zeroing out\nthe second part.(CVE-2026-45892)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: drop extent cache when splitting extent fails\n\nWhen the split extent fails, we might leave some extents still being\nprocessed and return an error directly, which will result in stale\nextent entries remaining in the extent status tree. So drop all of the\nremaining potentially stale extents if the splitting fails.(CVE-2026-45899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: don't cache extent during splitting extent\n\nCaching extents during the splitting process is risky, as it may result\nin stale extents remaining in the status tree. Moreover, in most cases,\nthe corresponding extent block entries are likely already cached before\nthe split happens, making caching here not particularly useful.\n\nAssume we have an unwritten extent, and then DIO writes the first half.\n\n  [UUUUUUUUUUUUUUUU] on-disk extent        U: unwritten extent\n  [UUUUUUUUUUUUUUUU] extent status tree\n  |<-   ->| ----> dio write this range\n\nFirst, when ext4_split_extent_at() splits this extent, it truncates the\nexisting extent and then inserts a new one. During this process, this\nextent status entry may be shrunk, and calls to ext4_find_extent() and\next4_cache_extents() may occur, which could potentially insert the\ntruncated range as a hole into the extent status tree. After the split\nis completed, this hole is not replaced with the correct status.\n\n  [UUUUUUU|UUUUUUUU] on-disk extent        U: unwritten extent\n  [UUUUUUU|HHHHHHHH] extent status tree    H: hole\n\nThen, the outer calling functions will not correct this remaining hole\nextent either. Finally, if we perform a delayed buffer write on this\nlatter part, it will re-insert the delayed extent and cause an error in\nspace accounting.\n\nIn adition, if the unwritten extent cache is not shrunk during the\nsplitting, ext4_cache_extents() also conflicts with existing extents\nwhen caching extents. In the future, we will add checks when caching\nextents, which will trigger a warning. Therefore, Do not cache extents\nthat are being split.(CVE-2026-45912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipc: limit next_id allocation to the valid ID range\n\nThe checkpoint/restore sysctl path can request the next SysV IPC id\nthrough ids->next_id.  ipc_idr_alloc() currently forwards that request to\nidr_alloc() with an open-ended upper bound.\n\nIf the valid tail of the SysV IPC id space is full, the allocation can\nspill beyond ipc_mni.  The returned SysV IPC id still uses the normal\nindex encoding, so later lookup and removal can target the wrong slot. \nThis leaves the real IDR entry behind and breaks the IDR state for the\nobject.\n\nThe bug is in ipc_idr_alloc() in the checkpoint/restore path.\n\n1. ids->next_id is passed to:\n\n       idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...)\n\n2. The zero upper bound makes the allocation effectively open-ended.\n   Once the valid SysV IPC tail is occupied, idr_alloc() can spill past\n   ipc_mni and allocate an entry beyond the valid IPC id range.\n\n3. The new object id is still encoded with the narrower SysV IPC index\n   width:\n\n       new->id = (new->seq << ipcmni_seq_shift()) + idx\n\n4. Later removal goes through ipc_rmid(), which uses:\n\n       ipcid_to_idx(ipcp->id)\n\n   That truncates the real IDR index. An object actually stored at a\n   high index can then be removed as if it lived at a low in-range\n   index.\n\n5. For shared memory, shm_destroy() frees the current object anyway, but\n   the real high IDR slot is left behind as a dangling pointer.\n\n6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry\n   and dereferences freed memory.\n\nPrevent this by bounding the requested allocation to ipc_mni so the\ncheckpoint/restore path fails once the valid range is exhausted.(CVE-2026-52923)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skbuff: fix missing zerocopy reference in pskb_carve helpers\n\npskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy\nthe old skb_shared_info header into a new buffer via memcpy(), which\nincludes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs.\nNeither function calls net_zcopy_get() for the new shinfo, creating an\nunaccounted holder: every skb_shared_info with destructor_arg set will\ncall skb_zcopy_clear() once when freed, but the corresponding\nnet_zcopy_get() was never called for the new copy. Repeated calls\ndrive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while\nTX skbs still hold live destructor_arg pointers.\n\nKASAN reports use-after-free on a freed ubuf_info_msgzc:\n\n  BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810\n  Read of size 8 at addr ffff88801574d3e8 by task poc/220\n\n  Call Trace:\n   skb_release_data+0x77b/0x810\n   kfree_skb_list_reason+0x13e/0x610\n   skb_release_data+0x4cd/0x810\n   sk_skb_reason_drop+0xf3/0x340\n   skb_queue_purge_reason+0x282/0x440\n   rds_tcp_inc_free+0x1e/0x30\n   rds_recvmsg+0x354/0x1780\n   __sys_recvmsg+0xdf/0x180\n\n  Allocated by task 219:\n   msg_zerocopy_realloc+0x157/0x7b0\n   tcp_sendmsg_locked+0x2892/0x3ba0\n\n  Freed by task 219:\n   ip_recv_error+0x74a/0xb10\n   tcp_recvmsg+0x475/0x530\n\nThe skb consuming the late access still referenced the same uarg via\nshinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without\na refcount bump. This has been verified to be reliably exploitable: a\nworking proof-of-concept achieves full root privilege escalation from\nan unprivileged local user on a default kernel configuration.\n\nThe fix follows the pattern of pskb_expand_head() which has the same\nmemcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get()\nis placed after skb_orphan_frags() succeeds, so the orphan error path\nneeds no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is\nplaced after all failure points and just before skb_release_data(), so\nno error path needs cleanup at all -- matching pskb_expand_head() more\nclosely and avoiding the need for a balancing net_zcopy_put().(CVE-2026-52943)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Bound MIDI endpoint descriptor scans\n\nsnd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint\ndescriptor size before using baAssocJackID[], but the descriptor walker can\nstill return a class-specific endpoint descriptor whose bLength exceeds the\nremaining bytes in the endpoint-extra scan.\n\nThat leaves later flexible-array reads bounded by bLength, but not by the\nremaining bytes in the endpoint-extra scan.\n\nStop walking when bLength is zero or\nextends past the remaining endpoint-extra scan.(CVE-2026-52963)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: fix missing expect put in obj eval\n\nnft_ct_expect_obj_eval() allocates an expectation and may call\nnf_ct_expect_related(), but never drops its local reference.\n\nAdd nf_ct_expect_put(exp) before return to balance allocation.(CVE-2026-52970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_sip: don't use simple_strtoul\n\nReplace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(),\nand ct_sip_parse_request() with a new sip_parse_port() helper that\nvalidates each digit against the buffer limit, eliminating the use of\nsimple_strtoul() which assumes NUL-terminated strings.\n\nThe previous code dereferenced pointers without bounds checks after\nsip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated\nskb data. A port that reaches the buffer limit without a trailing\ncharacter is also rejected as malformed.\n\nAlso get rid of all simple_strtoul() usage in conntrack, prefer a\nstricter version instead.  There are intentional changes:\n\n- Bail out if number is > UINT_MAX and indicate a failure, same for\n  too long sequences.\n  While we do accept 05535 as port 5535, we will not accept e.g.\n  'sip:10.0.0.1:005060'.  While its syntactically valid under RFC 3261,\n  we should restrict this to not waste cycles when presented with\n  malformed packets with 64k '0' characters.\n\n- Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch\n  'expire=' and 'rports='; both are expected to use base-10.\n\n- In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k\n  range.\n\n- epaddr_len now returns 0 if the port is invalid, as it already does\n  for invalid ip addresses.  This is intentional. nf_conntrack_sip\n  performs lots of guesswork to find the right parts of the message\n  to parse.  Being stricter could break existing setups.\n  Connection tracking helpers are designed to allow traffic to\n  pass, not to block it.\n\nBased on an earlier patch from Jenny Guanni Qu <(CVE-2026-52986)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/psi: fix race between file release and pressure write\n\nA potential race condition exists between pressure write and cgroup file\nrelease regarding the priv member of struct kernfs_open_file, which\ntriggers the uaf reported in [1].\n\nConsider the following scenario involving execution on two separate CPUs:\n\n   CPU0\t\t\t\t\tCPU1\n   ====\t\t\t\t\t====\n\t\t\t\t\tvfs_rmdir()\n\t\t\t\t\tkernfs_iop_rmdir()\n\t\t\t\t\tcgroup_rmdir()\n\t\t\t\t\tcgroup_kn_lock_live()\n\t\t\t\t\tcgroup_destroy_locked()\n\t\t\t\t\tcgroup_addrm_files()\n\t\t\t\t\tcgroup_rm_file()\n\t\t\t\t\tkernfs_remove_by_name()\n\t\t\t\t\tkernfs_remove_by_name_ns()\n vfs_write()\t\t\t\t__kernfs_remove()\n new_sync_write()\t\t\tkernfs_drain()\n kernfs_fop_write_iter()\t\tkernfs_drain_open_files()\n cgroup_file_write()\t\t\tkernfs_release_file()\n pressure_write()\t\t\tcgroup_file_release()\n ctx = of->priv;\n\t\t\t\t\tkfree(ctx);\n \t\t\t\t\tof->priv = NULL;\n\t\t\t\t\tcgroup_kn_unlock()\n cgroup_kn_lock_live()\n cgroup_get(cgrp)\n cgroup_kn_unlock()\n if (ctx->psi.trigger)  // here, trigger uaf for ctx, that is of->priv\n\nThe cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards\nthe memory deallocation of of->priv performed within cgroup_file_release().\nHowever, the operations involving of->priv executed within pressure_write()\nare not entirely covered by the protection of cgroup_mutex. Consequently,\nif the code in pressure_write(), specifically the section handling the\nctx variable executes after cgroup_file_release() has completed, a uaf\nvulnerability involving of->priv is triggered.\n\nTherefore, the issue can be resolved by extending the scope of the\ncgroup_mutex lock within pressure_write() to encompass all code paths\ninvolving of->priv, thereby properly synchronizing the race condition\noccurring between cgroup_file_release() and pressure_write().\n\nAnd, if an live kn lock can be successfully acquired while executing\nthe pressure write operation, it indicates that the cgroup deletion\nprocess has not yet reached its final stage; consequently, the priv\npointer within open_file cannot be NULL. Therefore, the operation to\nretrieve the ctx value must be moved to a point *after* the live kn\nlock has been successfully acquired.\n\nIn another situation, specifically after entering cgroup_kn_lock_live()\nbut before acquiring cgroup_mutex, there exists a different class of\nrace condition:\n\nCPU0: write memory.pressure               CPU1: write cgroup.pressure=0\n===========================\t\t  =============================\n\nkernfs_fop_write_iter()\n kernfs_get_active_of(of)\n pressure_write()\n   cgroup_kn_lock_live(memory.pressure)\n     cgroup_tryget(cgrp)\n     kernfs_break_active_protection(kn)\n     ... blocks on cgroup_mutex\n\n                                     \t  cgroup_pressure_write()\n                                     \t  cgroup_kn_lock_live(cgroup.pressure)\n                                     \t  cgroup_file_show(memory.pressure, false)\n                                     \t    kernfs_show(false)\n                                     \t      kernfs_drain_open_files()\n                                     \t        cgroup_file_release(of)\n                                     \t          kfree(ctx)\n                                     \t            of->priv = NULL\n                                     \t  cgroup_kn_unlock()\n\n   ... acquires cgroup_mutex\n   ctx = of->priv;        // may now be NULL\n   if (ctx->psi.trigger)  // NULL dereference\n\nConsequently, there is a possibility that of->priv is NULL, the pressure\nwrite needs to check for this.\n\nNow that the scope of the cgroup_mutex has been expanded, the original\nexplicit cgroup_get/put operations are no longer necessary, this is\nbecause acquiring/releasing the live kn lock inherently executes a\ncgroup get/put operation.\n\n[1]\nBUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\nCall Trace:\n pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\n cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43\n---truncated---(CVE-2026-52991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_osf: fix potential NULL dereference in ttl check\n\nThe nf_osf_ttl() function accessed skb->dev to perform a local interface\naddress lookup without verifying that the device pointer was valid.\n\nAdditionally, the implementation utilized an in_dev_for_each_ifa_rcu\nloop to match the packet source address against local interface\naddresses. It assumed that packets from the same subnet should not see a\ndecrement on the initial TTL. A packet might appear it is from the same\nsubnet but it actually isn't especially in modern environments with\ncontainers and virtual switching.\n\nRemove the device dereference and interface loop. Replace the logic with\na switch statement that evaluates the TTL according to the ttl_check.(CVE-2026-52998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: remove sprintf usage\n\nReplace it with scnprintf, the buffer sizes are expected to be large enough\nto hold the result, no need for snprintf+overflow check.\n\nIncrease buffer size in mangle_content_len() while at it.\n\nBUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270\nWrite of size 1 at addr [..]\n vsnprintf+0xea5/0x1270\n sprintf+0xb1/0xe0\n mangle_content_len+0x1ac/0x280\n nf_nat_sdp_session+0x1cc/0x240\n process_sdp+0x8f8/0xb80\n process_invite_request+0x108/0x2b0\n process_sip_msg+0x5da/0xf50\n sip_help_tcp+0x45e/0x780\n nf_confirm+0x34d/0x990\n [..](CVE-2026-53002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: add some missing log locking\n\nFunction gfs2_logd() calls the log flushing functions gfs2_ail1_start(),\ngfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock,\nbut these functions require exclusion against concurrent transactions.\n\nTo fix that, add a non-locking __gfs2_log_flush() function.  Then, in\ngfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned log\nflushing functions and __gfs2_log_flush().(CVE-2026-53049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER\n\nWhen protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls\nhci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm()\nassumes it is held, and if conn is deleted concurrently -> UAF.\n\nOnly SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen,\nand HCI_EV_CONN_REQUEST is not generated for ISO.  In the non-deferred\nlistening socket code paths, hci_connect_cfm(conn) is called with\nhdev->lock held.\n\nFix by holding the lock.(CVE-2026-53072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus' match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-53115)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: kl5kusb105: fix bulk-out buffer overflow\n\nklsi_105_prepare_write_buffer() is called by the generic write path\nwith the bulk-out buffer and its size (bulk_out_size, 64 bytes). It\nstores a two-byte length header at the start of the buffer and copies\nthe payload from the write fifo starting at buf + KLSI_HDR_LEN, but\npasses the full buffer size as the number of bytes to copy:\n\n  count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN,\n                           size, &port->lock);\n\nWhen the fifo holds at least size bytes, size bytes are copied starting\ntwo bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its\nend. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for\nthe header as safe_serial already does.\n\nWriting bulk_out_size or more bytes to the tty triggers a slab\nout-of-bounds write, observed with KASAN by emulating the device with\ndummy_hcd and raw-gadget:\n\n  BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0\n  Write of size 64 at addr ffff888112c62202 by task python3\n   kfifo_copy_out\n   klsi_105_prepare_write_buffer [kl5kusb105]\n   usb_serial_generic_write_start [usbserial]\n  Allocated by task 139:\n   usb_serial_probe [usbserial]\n  The buggy address is located 2 bytes inside of allocated 64-byte region\n\nThe out-of-bounds write no longer occurs with this change applied.(CVE-2026-53194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()\n\nbuild_i2c_fw_hdr() allocates a fixed-size buffer of\n(16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then\ncopies le16_to_cpu(img_header->Length) bytes into it without\nvalidating that Length fits within the available space after the\nfirmware record header.\n\nimg_header->Length is a __le16 from the firmware file and can be\nup to 65535. check_fw_sanity() validates the total firmware size\nbut not img_header->Length specifically.\n\nFix by rejecting images where img_header->Length exceeds the\navailable destination space.(CVE-2026-53195)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig\n\nnet/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR\nsignaling packets up to the channel MTU and dispatches each command\nwithout enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer\nwithin radio range can send a fixed-channel CID 0x0001 packet that is\nlarger than MTUsig and contains many L2CAP_ECHO_REQ commands before\npairing. In a real-radio stock-kernel run, one 681-byte signaling\npacket containing 168 zero-length ECHO_REQ commands made the target\ntransmit 168 ECHO_RSP frames over about 220 ms.\n\nImpact: a Bluetooth BR/EDR peer within radio range, before pairing, can\nforce 168 ECHO_RSP frames from one 681-byte fixed-channel signaling\npacket containing packed ECHO_REQ commands.\n\nDefine Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and\nreject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP\ncarrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched.\n\nThe Bluetooth Core spec wording for MTUExceeded says the reject\nidentifier shall match the first request command in the packet, and\nthat packets containing only responses shall be silently discarded.\nLinux intentionally deviates from that prescription: silently\ndiscarding desynchronizes the peer because the remote stack never\nlearns its responses were dropped, and locating the first request\ncommand requires walking command headers past MTUsig, i.e. processing\nbytes from a packet we have already decided is too large to process.\nWe therefore always emit one reject and use the identifier from the\nfirst command header, a single fixed-offset byte read.\n\nThe unrestricted BR/EDR signaling parser and ECHO_REQ response path both\ntrace to the initial git import; no later introducing commit is\navailable for a Fixes tag.(CVE-2026-53208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: restrict SO_ATTACH_FILTER to priv users\n\nThis patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets\nto users with CAP_NET_ADMIN capability.\n\nThis blocks potential side-channel attack where an unprivileged application\nattaches a filter to leak TCP sequence/acknowledgment numbers.(CVE-2026-53236)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlabel: validate unlabeled address and mask attribute lengths\n\nnetlbl_unlabel_addrinfo_get() used the address attribute length to\ndetermine whether the attribute data could be read as an IPv4 or IPv6\naddress, but did not independently validate the corresponding mask\nattribute length.  A crafted Generic Netlink request could therefore\nprovide a valid IPv4/IPv6 address attribute with a shorter mask\nattribute, which would later be read as a full struct in_addr or\nstruct in6_addr.\n\nNLA_BINARY policy lengths are maximum lengths by default, so use\nNLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask\nattributes.  This rejects short attributes during policy validation and\nalso exposes the exact length requirements through policy introspection.(CVE-2026-53238)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr\n\nIn mrp_pdu_parse_vecattr(), vector attribute events are encoded three\nper byte and valen tracks the number of events left to process.\n\nThe parser decrements valen after processing the first and second events\nfrom each event byte, but not after processing the third one. When valen\nis exactly a multiple of three, the loop continues after the last valid\nevent and consumes the next byte as a new event byte, applying a\nspurious event to the MRP applicant state.\n\nAdditionally, when valen is zero the parser unconditionally consumes\nattrlen bytes as FirstValue and advances the offset, even though per\nIEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of\nzero and no FirstValue or Vector fields. This corrupts the offset for\nsubsequent PDU parsing.\n\nAlso, when valen exceeds three the loop crosses byte boundaries but\nthe attribute value is not incremented between the last event of one\nbyte and the first event of the next. This causes the first event of\nthe next byte to use the same attribute value as the third event\nrather than the next consecutive value.\n\nDecrement valen after processing the third event, skip FirstValue\nconsumption when valen is zero, and increment the attribute value at\nthe end of each loop iteration.(CVE-2026-53245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: restrict IPOPT_SSRR and IPOPT_LSRR options\n\nThis patch restricts setting Loose Source and Record Route (LSRR)\nand Strict Source and Record Route (SSRR) IP options to users\nwith CAP_NET_RAW capability.\n\nThis prevents unprivileged applications from forcing packets to route\nthrough attacker-controlled nodes to leak TCP ISN and possibly other\nprotocol information.\n\nWhile LSRR and SSRR are commonly filtered in many network environments,\nthey may still be supported and forwarded along some network paths.\n\nRFC 7126 (Recommendations on Filtering of IPv4 Packets Containing\nIPv4 Options) recommend to drop these options in 4.3 and 4.4.(CVE-2026-53249)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix memory leak in error path of hci_alloc_dev()\n\nEarly failures in Bluetooth HCI UART configuration leak SRCU percpu\nmemory.\n\nWhen device initialization fails before hci_register_dev() completes,\nthe HCI_UNREGISTER flag is never set. As a result, when the device\nreference count reaches zero, bt_host_release() evaluates this flag as\nfalse and falls back to a direct kfree(hdev).\n\nBecause hci_release_dev() is bypassed, the SRCU struct initialized\nearly in hci_alloc_dev() is never cleaned up, resulting in a leak of\npercpu memory.\n\nFix the leak by explicitly calling cleanup_srcu_struct() in the\nfallback (unregistered) branch of bt_host_release() before freeing\nthe device.(CVE-2026-53252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: bridge: make ebt_snat ARP rewrite writable\n\nThe ebtables SNAT target keeps the Ethernet source address rewrite\nbehind skb_ensure_writable(skb, 0).  This is intentional: at the bridge\nebtables hooks the Ethernet header is addressed through\nskb_mac_header()/eth_hdr(), while skb->data points at the Ethernet\npayload.  Asking skb_ensure_writable() for ETH_HLEN bytes would check\nthe payload, not the Ethernet header, and would reintroduce the small\npacket regression fixed by commit 63137bc5882a.\n\nHowever, the optional ARP sender hardware address rewrite is different.\nIt writes through skb_store_bits() at an offset relative to skb->data:\n\n        skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN)\n\nskb_header_pointer() only safely reads the ARP header; it does not make\nthe later sender hardware address range writable.  If that range is\nstill held in a nonlinear skb fragment backed by a splice-imported file\npage, skb_store_bits() maps the frag page and copies the new MAC address\ndirectly into it.\n\nEnsure the ARP SHA range is writable before reading the ARP header and\nbefore calling skb_store_bits().(CVE-2026-53266)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack_irc: fix possible out-of-bounds read\n\nWhen parsing fails after we've matched the command string we\nshould bail out instead of trying to match a different command.\n\nThis helper should be deprecated, given prevalence of TLS I doubt it has\nany relevance in 2026.(CVE-2026-53268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: synproxy: add mutex to guard hook reference counting\n\nAs the synproxy infrastructure register netfilter hooks on-demand when a\nuser adds the first iptables target or nftables expression, if done\nconcurrently they can race each other.\n\nIntroduce a mutex to serialize the refcount control blocks access from\nboth frontends. While a per namespace mutex might be more efficient, it\nis not needed for target/expression like SYNPROXY.(CVE-2026-53269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: clear the svc scheduler ptr early on edit\n\nip_vs_edit_service() while unbinding the old scheduler clears\nthe svc->scheduler ptr after the scheduler module initiates\nRCU callbacks. This can cause packets to use the old\nscheduler at the time when svc->sched_data is already freed\nafter RCU grace period.\n\nFix it by clearing the ptr early in ip_vs_unbind_scheduler(),\nbefore the done_service method schedules any RCU callbacks.\n\nAlso, if the new scheduler fails to initialize when replacing\nthe old scheduler, try to restore the old scheduler while still\nreturning the error code.(CVE-2026-53270)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: Fix use-after-free when processing MLD queries\n\nWhen processing an MLD query, a pointer to the multicast group address\nis retrieved when initially parsing the packet. This pointer is later\ndereferenced without being reloaded despite the fact that the skb header\nmight have been reallocated following the pskb_may_pull() calls, leading\nto a use-after-free [1].\n\nFix by copying the multicast group address when the packet is initially\nparsed.\n\n[1]\nBUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512)\nRead of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118\n\nWorkqueue: mld mld_query_work\nCall Trace:\n<TASK>\ndump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)\nprint_address_description.constprop.0 (mm/kasan/report.c:378)\nprint_report (mm/kasan/report.c:482)\nkasan_report (mm/kasan/report.c:595)\n__mld_query_work (net/ipv6/mcast.c:1512)\nmld_query_work (net/ipv6/mcast.c:1563)\nprocess_one_work (kernel/workqueue.c:3314)\nworker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)\nkthread (kernel/kthread.c:436)\nret_from_fork (arch/x86/kernel/process.c:158)\nret_from_fork_asm (arch/x86/entry/entry_64.S:245)\n</TASK>\n\n[...]\n\nFreed by task 118:\nkasan_save_stack (mm/kasan/common.c:57)\nkasan_save_track (mm/kasan/common.c:78)\nkasan_save_free_info (mm/kasan/generic.c:584)\n__kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)\nkfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)\npskb_expand_head (net/core/skbuff.c:2335)\n__pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4))\n__mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1))\nmld_query_work (net/ipv6/mcast.c:1563)\nprocess_one_work (kernel/workqueue.c:3314)\nworker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)\nkthread (kernel/kthread.c:436)\nret_from_fork (arch/x86/kernel/process.c:158)\nret_from_fork_asm (arch/x86/entry/entry_64.S:245)(CVE-2026-53275)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()\n\nbt_accept_dequeue() unlinks a not-yet-accepted child from the parent\naccept queue and release_sock()s it before returning, so the returned\nsk has no caller reference and is unlocked.\n\nl2cap_sock_cleanup_listen() walks these children on listening-socket\nclose.  A concurrent HCI disconnect drives hci_rx_work ->\nl2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and\nfrees the child sk and its l2cap_chan; cleanup_listen() then uses both:\n\n  BUG: KASAN: slab-use-after-free in l2cap_sock_kill\n    l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close\n  Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill\n\nThis is distinct from the two fixes already in this area: commit\ne83f5e24da741 ("Bluetooth: serialize accept_q access") serialises the\naccept_q list/poll and takes temporary refs inside bt_accept_dequeue(),\nand CVE-2025-39860 serialises the userspace close()/accept() race by\ncalling cleanup_listen() under lock_sock() in l2cap_sock_release().\nNeither covers l2cap_conn_del() running from hci_rx_work, so this UAF\nstill reproduces on current bluetooth/master.\n\nTake the reference at the source: bt_accept_dequeue() does sock_hold()\nwhile sk is still locked, before release_sock(); callers sock_put().\ncleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under\na brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops\nit before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on\nSOCK_DEAD.  conn->lock is not taken here: cleanup_listen() runs under\nthe parent sk lock and that would invert\nconn->lock -> chan->lock -> sk_lock (lockdep).\n\nKASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced\n12 use-after-free reports per run before this change; 0, and no lockdep\nreport, over 1600+ raced iterations after it on bluetooth/master.(CVE-2026-53357)","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-323.0.0.224.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","kernel-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","perf-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-323.0.0.224.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-323.0.0.224.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","kernel-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","perf-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-323.0.0.224.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2930"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43052"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43110"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43111"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43206"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45892"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45912"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52923"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52943"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52963"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52970"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52986"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52991"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52998"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53002"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53049"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53072"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53115"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53194"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53195"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53208"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53236"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53238"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53245"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53249"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53252"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53266"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53268"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53269"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53270"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53275"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53357"}],"database_specific":{"severity":"Critical"}}