{"schema_version":"1.7.2","id":"OESA-2026-3302","modified":"2026-08-07T02:45:03Z","published":"2026-08-07T02:45:03Z","upstream":["CVE-2026-46266","CVE-2026-52920","CVE-2026-52942","CVE-2026-53186","CVE-2026-53246","CVE-2026-53388","CVE-2026-63887","CVE-2026-63888","CVE-2026-64378"],"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\ninet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP\n\nYizhou Zhao reported that simply having one RAW socket on protocol\nIPPROTO_RAW (255) was dangerous.\n\n  socket(AF_INET, SOCK_RAW, 255);\n\nA malicious incoming ICMP packet can set the protocol field to 255\nand match this socket, leading to FNHE cache changes.\n\ninner = IP(src="192.168.2.1", dst="8.8.8.8", proto=255)/Raw("TEST")\npkt = IP(src="192.168.1.1", dst="192.168.2.1")/ICMP(type=3, code=4, nexthopmtu=576)/inner\n\n"man 7 raw" states:\n\n  A protocol of IPPROTO_RAW implies enabled IP_HDRINCL and is able\n  to send any IP protocol that is specified in the passed header.\n  Receiving of all IP protocols via IPPROTO_RAW is not possible\n  using raw sockets.\n\nMake sure we drop these malicious packets.(CVE-2026-46266)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_policy: fix strict mode inbound policy matching\n\nmatch_policy_in() walks sec_path entries from the last transform to the\nfirst one, but strict policy matching needs to consume info->pol[] in\nthe same forward order as the rule layout.\n\nDerive the strict-match policy position from the number of transforms\nalready consumed so that multi-element inbound rules are matched\nconsistently.(CVE-2026-52920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_log: validate MAC header was set before dumping it\n\nThe fallback path of dump_mac_header() guards the MAC header access\nonly with "skb->mac_header != skb->network_header", without checking\nskb_mac_header_was_set(). When the MAC header is unset, mac_header is\n0xffff, so the test passes and skb_mac_header(skb) returns\nskb->head + 0xffff, ~64 KiB past the buffer; the loop then reads\ndev->hard_header_len bytes out of bounds into the kernel log.\n\nThis is reachable via the netdev logger: nf_log_unknown_packet() calls\ndump_mac_header() unconditionally, and an skb sent through AF_PACKET\nwith PACKET_QDISC_BYPASS reaches the egress hook with mac_header still\nunset (__dev_queue_xmit(), which would reset it, is bypassed).\n\nAdd the skb_mac_header_was_set() check the ARPHRD_ETHER path already\nuses, and replace the open-coded MAC header length test with\nskb_mac_header_len(). Only skbs with an unset MAC header are affected;\nvalid ones are dumped as before.\n\n BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831)\n Read of size 1 at addr ffff88800ea49d3f by task exploit/148\n Call Trace:\n  kasan_report (mm/kasan/report.c:595)\n  dump_mac_header (net/netfilter/nf_log_syslog.c:831)\n  nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963)\n  nf_log_packet (net/netfilter/nf_log.c:260)\n  nft_log_eval (net/netfilter/nft_log.c:60)\n  nft_do_chain (net/netfilter/nf_tables_core.c:285)\n  nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307)\n  nf_hook_slow (net/netfilter/core.c:619)\n  nf_hook_direct_egress (net/packet/af_packet.c:257)\n  packet_xmit (net/packet/af_packet.c:280)\n  packet_sendmsg (net/packet/af_packet.c:3114)\n  __sys_sendto (net/socket.c:2265)(CVE-2026-52942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srp: bound SRP_RSP sense copy by the received length\n\nsrp_process_rsp() copies sense data from rsp->data + resp_data_len,\nwhere resp_data_len is the full 32-bit value supplied by the SRP target\nand is never checked against the number of bytes actually received\n(wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so\nat most 96 bytes are copied, but the source offset is not bounded.\n\nA malicious or compromised SRP target on the InfiniBand/RoCE fabric that\nthe initiator has logged into can return an SRP_RSP with\nSRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer\nis allocated at the target-chosen max_ti_iu_len, so the source of the\nsense copy lands past the bytes actually received; with resp_data_len\nnear 0xFFFFFFFF it is gigabytes past the buffer and the read faults.\n\nCopy the sense data only if it has not been truncated, that is, only if\nthe response header, the response data, and the sense region fit within\nthe bytes actually received; otherwise drop the sense and log. The\nin-tree iSER and NVMe-RDMA receive paths already bound their parse by\nwc->byte_len; this brings ib_srp into line with them.(CVE-2026-53186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate cached peer INIT chunk length in COOKIE_ECHO processing\n\nWhen a listening SCTP server processes a COOKIE_ECHO chunk, the cached\npeer INIT chunk embedded after the cookie is parsed and its parameters\nare later walked by sctp_process_init() using sctp_walk_params().\n\nHowever, the chunk header length of this cached INIT chunk was not\nvalidated against the remaining buffer in the COOKIE_ECHO payload. If\nthe length field is inflated, the parameter walk can run beyond the\nactual received data, leading to out-of-bounds reads and potential\nmemory corruption during later parameter handling (e.g. STATE_COOKIE\nprocessing and kmemdup() copies).\n\nAdd a bounds check in sctp_unpack_cookie() to ensure the cached INIT\nchunk length does not exceed the available data in the COOKIE_ECHO\nbuffer before it is used.(CVE-2026-53246)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: re-lock request before replacing page cache folio\n\nfuse_try_move_folio() unlocks the request on entry but does not\nre-lock it on the success path. This means fuse_chan_abort() can end the\nrequest and free the fuse_io_args (eg fuse_readpages_end()) while the\nsubsequent copy chain logic after fuse_try_move_folio() accesses the\nfuse_io_args, leading to use-after-free issues.\n\nFix this by calling lock_request() before replace_page_cache_folio().\nThis ensures the request is locked on the success path which will\nprevent the fuse_io_args from being freed while the later copying logic\nruns, and also ensures that the ap->folios[i]->mapping is never null\nsince ap->folios[i] will always point to the newfolio after\nreplace_page_cache_folio().(CVE-2026-53388)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf\n\niscsi_encode_text_output() concatenates "key=value\\0" records into\nlogin->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer\nallocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call\nsites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check\nthe remaining buffer capacity:\n\n\t*length += sprintf(output_buf, "%s=%s", er->key, er->value);\n\t*length += 1;\n\toutput_buf = textbuf + *length;\n\nThe 8192-byte ceiling at iscsi_target_check_login_request() bounds the\n*input* Login PDU payload, but a single PDU can carry up to 2048 minimal\nfour-byte "a=b\\0" pairs, each unknown key expanding to a 16-byte\n"a=NotUnderstood\\0" output record via iscsi_add_notunderstood_response().\n2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB\nheap overrun in the kmalloc-8k slab.\n\nThe fix introduces a static iscsi_encode_text_record() helper that uses\nsnprintf() with a per-call bounds check against the remaining buffer,\nand threads a u32 textbuf_size parameter through\niscsi_encode_text_output(). Both call sites in\niscsi_target_handle_csg_zero() (PHASE_SECURITY) and\niscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass\nMAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls\niscsi_release_extra_responses() to drop queued records, and returns -1;\nboth caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR /\nISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning,\nso the initiator sees an explicit failed-login response rather than a\nsilent connection drop. (Prior to this patch only the PHASE_OPERATIONAL\ncaller did that; the PHASE_SECURITY caller is converted to the same\nshape.)(CVE-2026-63887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd()\n\nTwo latent bugs in the Text-phase handler, both present since the\noriginal LIO integration in commit e48354ce078c ("iscsi-target: Add\niSCSI fabric support for target v4.1"):\n\n1) DataDigest CRC buffer overread (4 bytes past text_in).\n\n   text_in is kzalloc()'d at ALIGN(payload_length, 4).  rx_size is then\n   incremented by ISCSI_CRC_LEN to make room for the received DataDigest\n   in the iovec, but the same (now-bumped) rx_size is passed as the\n   buffer length to iscsit_crc_buf():\n\n       if (conn->conn_ops->DataDigest) {\n               ...\n               rx_size += ISCSI_CRC_LEN;\n       }\n       ...\n       if (conn->conn_ops->DataDigest) {\n               data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);\n\n   iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so\n   when DataDigest is negotiated it reads 4 bytes past the end of the\n   text_in allocation.  KASAN reproduces this directly on the unpatched\n   mainline tree as slab-out-of-bounds in crc32c() called from the Text\n   PDU path.  The OOB bytes feed crc32c() and are then compared against\n   the initiator-supplied checksum, so the value does not flow back to\n   the attacker, but the kernel does read past the buffer on every Text\n   PDU with DataDigest=CRC32C.\n\n   Fix by passing the actual padded payload length\n   (ALIGN(payload_length, 4)) that was used for the kzalloc().\n\n2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest\n   drop.\n\n   On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler\n   silently drops the PDU and lets the initiator plug the CmdSN gap:\n\n               kfree(text_in);\n               return 0;\n\n   cmd->text_in_ptr still points at the freed buffer.  The next Text\n   Request on the same ITT re-enters iscsit_setup_text_cmd(), which\n   unconditionally does\n\n       kfree(cmd->text_in_ptr);\n       cmd->text_in_ptr = NULL;\n\n   freeing the same pointer a second time.  Session teardown via\n   iscsit_release_cmd() has the same shape and hits the same double-free\n   if the connection is dropped before a second Text Request arrives.\n\n   On an unmodified mainline tree the bug-1 CRC overread fires first on\n   the initial valid Text Request and perturbs the subsequent state, so\n   #4 was isolated by building a kernel with only the bug-1 hunk of this\n   patch applied plus temporary printk() observability around the three\n   relevant kfree() sites.  The observability prints are not part of\n   this patch.  On that build, a three-PDU Text Request sequence after\n   login produces two back-to-back splats:\n\n       BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??\n       BUG: KASAN: double-free in iscsit_release_cmd+0x??\n\n   showing the same pointer freed in the ERL>0 drop path and again in\n   iscsit_setup_text_cmd() (next Text Request on the same ITT) and once\n   more in iscsit_release_cmd() (session teardown).  On distro kernels\n   with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free\n   becomes a remote kernel BUG(); on non-hardened kernels it corrupts\n   the slab freelist.\n\n   Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop\n   path.  With both hunks applied #4 is directly observable on the stock\n   tree without observability printks; fixing bug-1 alone would mask #4\n   less, not more, so the hunks are submitted together.\n\nBoth fixes are one-liners.  The Text PDU state machine is unchanged and\nthe wire protocol is unaffected.(CVE-2026-63888)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwriteback: fix race between cgroup_writeback_umount() and inode_switch_wbs()\n\nWhen a container exits, the following BUG_ON() is occasionally triggered:\n\n==================================================================\n VFS: Busy inodes after unmount of sdb (ext4)\n ------------[ cut here ]------------\n kernel BUG at fs/super.c:695!\n CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1\n pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n pc : generic_shutdown_super+0xf0/0x100\n lr : generic_shutdown_super+0xf0/0x100\n Call trace:\n  generic_shutdown_super+0xf0/0x100\n  kill_block_super+0x20/0x48\n  ext4_kill_sb+0x28/0x60\n  deactivate_locked_super+0x54/0x130\n  deactivate_super+0x84/0xa0\n  cleanup_mnt+0xa4/0x140\n  __cleanup_mnt+0x18/0x28\n  task_work_run+0x78/0xe0\n  do_notify_resume+0x204/0x240\n==================================================================\n\nThe root cause is a race between cgroup_writeback_umount() and\ninode_switch_wbs()/cleanup_offline_cgwb(). There is a window between\ninode_prepare_wbs_switch() returning true and the subsequent\nwb_queue_isw() call. Following is the process that triggers the issue:\n\n      CPU A (umount)           |          CPU B (writeback)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n                                 inode_switch_wbs/cleanup_offline_cgwb\n                                  atomic_inc(&isw_nr_in_flight)\n                                  inode_prepare_wbs_switch\n                                   -> passes SB_ACTIVE check\n                                   __iget(inode)\n generic_shutdown_super\n  sb->s_flags &= ~SB_ACTIVE\n  cgroup_writeback_umount(sb)\n   smp_mb()\n   atomic_read(&isw_nr_in_flight)\n   rcu_barrier()\n    -> no pending RCU callbacks\n   flush_workqueue(isw_wq)\n    -> nothing queued, returns\n  evict_inodes(sb)\n   -> Inode skipped as isw still holds a ref.\n  sop->put_super(sb)\n   /* destroys percpu counters */\n  -> VFS: Busy inodes after unmount!\n                                  wb_queue_isw()\n                                   queue_work(isw_wq, ...)\n                                  /* later in work function */\n                                  inode_switch_wbs_work_fn\n                                   process_inode_switch_wbs\n                                    iput() -> evict\n                                     percpu_counter_dec() // UAF!\n\nFix this by extending the RCU read-side critical section in\ninode_switch_wbs() and cleanup_offline_cgwb() to cover from\ninode_prepare_wbs_switch() through wb_queue_isw().  Since there is\nno sleep in this window, rcu_read_lock() can be used.  Then add a\nsynchronize_rcu() in cgroup_writeback_umount() before the existing\nrcu_barrier(), so that all in-flight switchers that have passed the\nSB_ACTIVE check have completed queue_work() before flush_workqueue()\nis called.\n\nThe existing rcu_barrier() is intentionally retained so this fix can\nbe backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that\nstill queue switches via queue_rcu_work(). It is a no-op on current\nmainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on\nwb->list_lock when switching inodes")) and is removed in a follow-up\npatch.(CVE-2026-64378)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2608.2.0.0384.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","kernel-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","perf-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2608.2.0.0384.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","kernel-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","perf-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2608.2.0.0384.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3302"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46266"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52920"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52942"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53186"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53246"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53388"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63887"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63888"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64378"}],"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"}}