{"schema_version":"1.7.2","id":"OESA-2025-1960","modified":"2025-08-13T07:23:00Z","published":"2025-08-08T11:15:38Z","upstream":["CVE-2024-57982","CVE-2025-21682","CVE-2025-21884","CVE-2025-21891","CVE-2025-37957","CVE-2025-37992","CVE-2025-38040","CVE-2025-38048","CVE-2025-38063","CVE-2025-38125","CVE-2025-38135","CVE-2025-38145","CVE-2025-38181","CVE-2025-38207","CVE-2025-38222","CVE-2025-38246","CVE-2025-38265","CVE-2025-38332","CVE-2025-38338","CVE-2025-38345","CVE-2025-38362","CVE-2025-38371","CVE-2025-38380","CVE-2025-38385","CVE-2025-38386","CVE-2025-38387","CVE-2025-38396","CVE-2025-38400","CVE-2025-38415","CVE-2025-38424","CVE-2025-38427","CVE-2025-38430","CVE-2025-38439","CVE-2025-38447","CVE-2025-38466","CVE-2025-38471","CVE-2025-38474","CVE-2025-38496","CVE-2025-38498"],"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\nxfrm: state: fix out-of-bounds read during lookup\n\nlookup and resize can run in parallel.\n\nThe xfrm_state_hash_generation seqlock ensures a retry, but the hash\nfunctions can observe a hmask value that is too large for the new hlist\narray.\n\nrehash does:\n  rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..]\n  net->xfrm.state_hmask = nhashmask;\n\nWhile state lookup does:\n  h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);\n  hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {\n\nThis is only safe in case the update to state_bydst is larger than\nnet->xfrm.xfrm_state_hmask (or if the lookup function gets\nserialized via state spinlock again).\n\nFix this by prefetching state_hmask and the associated pointers.\nThe xfrm_state_hash_generation seqlock retry will ensure that the pointer\nand the hmask will be consistent.\n\nThe existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,\nadd lockdep assertions to document that they are only safe for insert\nside.\n\nxfrm_state_lookup_byaddr() uses the spinlock rather than RCU.\nAFAICS this is an oversight from back when state lookup was converted to\nRCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: always recalculate features after XDP clearing, fix null-deref\n\nRecalculate features when XDP is detached.\n\nBefore:\n  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp\n  # ip li set dev eth0 xdp off\n  # ethtool -k eth0 | grep gro\n  rx-gro-hw: off [requested on]\n\nAfter:\n  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp\n  # ip li set dev eth0 xdp off\n  # ethtool -k eth0 | grep gro\n  rx-gro-hw: on\n\nThe fact that HW-GRO doesn't get re-enabled automatically is just\na minor annoyance. The real issue is that the features will randomly\ncome back during another reconfiguration which just happens to invoke\nnetdev_update_features(). The driver doesn't handle reconfiguring\ntwo things at a time very robustly.\n\nStarting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in\n__bnxt_reserve_rings()") we only reconfigure the RSS hash table\nif the "effective" number of Rx rings has changed. If HW-GRO is\nenabled "effective" number of rings is 2x what user sees.\nSo if we are in the bad state, with HW-GRO re-enablement "pending"\nafter XDP off, and we lower the rings by / 2 - the HW-GRO rings\ndoing 2x and the ethtool -L doing / 2 may cancel each other out,\nand the:\n\n  if (old_rx_rings != bp->hw_resc.resv_rx_rings &&\n\ncondition in __bnxt_reserve_rings() will be false.\nThe RSS map won't get updated, and we'll crash with:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000168\n  RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0\n    bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180\n    __bnxt_setup_vnic_p5+0x58/0x110\n    bnxt_init_nic+0xb72/0xf50\n    __bnxt_open_nic+0x40d/0xab0\n    bnxt_open_nic+0x2b/0x60\n    ethtool_set_channels+0x18c/0x1d0\n\nAs we try to access a freed ring.\n\nThe issue is present since XDP support was added, really, but\nprior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in\n__bnxt_reserve_rings()") it wasn't causing major issues.(CVE-2025-21682)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: better track kernel sockets lifetime\n\nWhile kernel sockets are dismantled during pernet_operations->exit(),\ntheir freeing can be delayed by any tx packets still held in qdisc\nor device queues, due to skb_set_owner_w() prior calls.\n\nThis then trigger the following warning from ref_tracker_dir_exit() [1]\n\nTo fix this, make sure that kernel sockets own a reference on net->passive.\n\nAdd sk_net_refcnt_upgrade() helper, used whenever a kernel socket\nis converted to a refcounted one.\n\n[1]\n\n[  136.263918][   T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at\n[  136.263918][   T35]      sk_alloc+0x2b3/0x370\n[  136.263918][   T35]      inet6_create+0x6ce/0x10f0\n[  136.263918][   T35]      __sock_create+0x4c0/0xa30\n[  136.263918][   T35]      inet_ctl_sock_create+0xc2/0x250\n[  136.263918][   T35]      igmp6_net_init+0x39/0x390\n[  136.263918][   T35]      ops_init+0x31e/0x590\n[  136.263918][   T35]      setup_net+0x287/0x9e0\n[  136.263918][   T35]      copy_net_ns+0x33f/0x570\n[  136.263918][   T35]      create_new_namespaces+0x425/0x7b0\n[  136.263918][   T35]      unshare_nsproxy_namespaces+0x124/0x180\n[  136.263918][   T35]      ksys_unshare+0x57d/0xa70\n[  136.263918][   T35]      __x64_sys_unshare+0x38/0x40\n[  136.263918][   T35]      do_syscall_64+0xf3/0x230\n[  136.263918][   T35]      entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  136.263918][   T35]\n[  136.343488][   T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at\n[  136.343488][   T35]      sk_alloc+0x2b3/0x370\n[  136.343488][   T35]      inet6_create+0x6ce/0x10f0\n[  136.343488][   T35]      __sock_create+0x4c0/0xa30\n[  136.343488][   T35]      inet_ctl_sock_create+0xc2/0x250\n[  136.343488][   T35]      ndisc_net_init+0xa7/0x2b0\n[  136.343488][   T35]      ops_init+0x31e/0x590\n[  136.343488][   T35]      setup_net+0x287/0x9e0\n[  136.343488][   T35]      copy_net_ns+0x33f/0x570\n[  136.343488][   T35]      create_new_namespaces+0x425/0x7b0\n[  136.343488][   T35]      unshare_nsproxy_namespaces+0x124/0x180\n[  136.343488][   T35]      ksys_unshare+0x57d/0xa70\n[  136.343488][   T35]      __x64_sys_unshare+0x38/0x40\n[  136.343488][   T35]      do_syscall_64+0xf3/0x230\n[  136.343488][   T35]      entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-21884)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvlan: ensure network headers are in skb linear part\n\nsyzbot found that ipvlan_process_v6_outbound() was assuming\nthe IPv6 network header isis present in skb->head [1]\n\nAdd the needed pskb_network_may_pull() calls for both\nIPv4 and IPv6 handlers.\n\n[1]\nBUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47\n  __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47\n  ipv6_addr_type include/net/ipv6.h:555 [inline]\n  ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline]\n  ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651\n  ip6_route_output include/net/ip6_route.h:93 [inline]\n  ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476\n  ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline]\n  ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline]\n  ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline]\n  ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671\n  ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223\n  __netdev_start_xmit include/linux/netdevice.h:5150 [inline]\n  netdev_start_xmit include/linux/netdevice.h:5159 [inline]\n  xmit_one net/core/dev.c:3735 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751\n  sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343\n  qdisc_restart net/sched/sch_generic.c:408 [inline]\n  __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416\n  qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127\n  net_tx_action+0x78b/0x940 net/core/dev.c:5484\n  handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561\n  __do_softirq+0x14/0x1a kernel/softirq.c:595\n  do_softirq+0x9a/0x100 kernel/softirq.c:462\n  __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389\n  local_bh_enable include/linux/bottom_half.h:33 [inline]\n  rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]\n  __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611\n  dev_queue_xmit include/linux/netdevice.h:3311 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3132 [inline]\n  packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164\n  sock_sendmsg_nosec net/socket.c:718 [inline](CVE-2025-21891)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception\n\nPreviously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode\non vCPU reset") addressed an issue where a triple fault occurring in\nnested mode could lead to use-after-free scenarios. However, the commit\ndid not handle the analogous situation for System Management Mode (SMM).\n\nThis omission results in triggering a WARN when KVM forces a vCPU INIT\nafter SHUTDOWN interception while the vCPU is in SMM. This situation was\nreprodused using Syzkaller by:\n\n  1) Creating a KVM VM and vCPU\n  2) Sending a KVM_SMI ioctl to explicitly enter SMM\n  3) Executing invalid instructions causing consecutive exceptions and\n     eventually a triple fault\n\nThe issue manifests as follows:\n\n  WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112\n  kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n  Modules linked in:\n  CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted\n  6.1.130-syzkaller-00157-g164fe5dde9b6 #0\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n  BIOS 1.12.0-1 04/01/2014\n  RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n  Call Trace:\n   <TASK>\n   shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136\n   svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395\n   svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457\n   vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline]\n   vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062\n   kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283\n   kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122\n   vfs_ioctl fs/ioctl.c:51 [inline]\n   __do_sys_ioctl fs/ioctl.c:870 [inline]\n   __se_sys_ioctl fs/ioctl.c:856 [inline]\n   __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856\n   do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n   do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n   entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nArchitecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN()\nin kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper\nemulation of INIT.  SHUTDOWN on SVM is a weird edge case where KVM needs to\ndo _something_ sane with the VMCB, since it's technically undefined, and\nINIT is the least awful choice given KVM's ABI.\n\nSo, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of\nSMM to avoid any weirdness (and the WARN).\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.\n\n[sean: massage changelog, make it clear this isn't architectural behavior](CVE-2025-37957)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: Flush gso_skb list too during ->change()\n\nPreviously, when reducing a qdisc's limit via the ->change() operation, only\nthe main skb queue was trimmed, potentially leaving packets in the gso_skb\nlist. This could result in NULL pointer dereference when we only check\nsch->limit against sch->q.qlen.\n\nThis patch introduces a new helper, qdisc_dequeue_internal(), which ensures\nboth the gso_skb list and the main queue are properly flushed when trimming\nexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)\nare updated to use this helper in their ->change() routines.(CVE-2025-37992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: mctrl_gpio: split disable_ms into sync and no_sync APIs\n\nThe following splat has been observed on a SAMA5D27 platform using\natmel_serial:\n\nBUG: sleeping function called from invalid context at kernel/irq/manage.c:738\nin_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0\npreempt_count: 1, expected: 0\nINFO: lockdep is turned off.\nirq event stamp: 0\nhardirqs last  enabled at (0): [<00000000>] 0x0\nhardirqs last disabled at (0): [<c01588f0>] copy_process+0x1c4c/0x7bec\nsoftirqs last  enabled at (0): [<c0158944>] copy_process+0x1ca0/0x7bec\nsoftirqs last disabled at (0): [<00000000>] 0x0\nCPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74\nHardware name: Atmel SAMA5\nWorkqueue: hci0 hci_power_on [bluetooth]\nCall trace:\n  unwind_backtrace from show_stack+0x18/0x1c\n  show_stack from dump_stack_lvl+0x44/0x70\n  dump_stack_lvl from __might_resched+0x38c/0x598\n  __might_resched from disable_irq+0x1c/0x48\n  disable_irq from mctrl_gpio_disable_ms+0x74/0xc0\n  mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4\n  atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8\n  atmel_set_termios from uart_change_line_settings+0x15c/0x994\n  uart_change_line_settings from uart_set_termios+0x2b0/0x668\n  uart_set_termios from tty_set_termios+0x600/0x8ec\n  tty_set_termios from ttyport_set_flow_control+0x188/0x1e0\n  ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc]\n  wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth]\n  hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth]\n  hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth]\n  hci_power_on [bluetooth] from process_one_work+0x998/0x1a38\n  process_one_work from worker_thread+0x6e0/0xfb4\n  worker_thread from kthread+0x3d4/0x484\n  kthread from ret_from_fork+0x14/0x28\n\nThis warning is emitted when trying to toggle, at the highest level,\nsome flow control (with serdev_device_set_flow_control) in a device\ndriver. At the lowest level, the atmel_serial driver is using\nserial_mctrl_gpio lib to enable/disable the corresponding IRQs\naccordingly.  The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to\ndisable_irq (called in mctrl_gpio_disable_ms) being possibly called in\nsome atomic context (some tty drivers perform modem lines configuration\nin regions protected by port lock).\n\nSplit mctrl_gpio_disable_ms into two differents APIs, a non-blocking one\nand a blocking one. Replace mctrl_gpio_disable_ms calls with the\nrelevant version depending on whether the call is protected by some port\nlock.(CVE-2025-38040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_ring: Fix data race by tagging event_triggered as racy for KCSAN\n\nsyzbot reports a data-race when accessing the event_triggered, here is the\nsimplified stack when the issue occurred:\n\n==================================================================\nBUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayed\n\nwrite to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0:\n virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653\n start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264\n __netdev_start_xmit include/linux/netdevice.h:5151 [inline]\n netdev_start_xmit include/linux/netdevice.h:5160 [inline]\n xmit_one net/core/dev.c:3800 [inline]\n\nread to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1:\n virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline]\n virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566\n skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777\n vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715\n __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158\n handle_irq_event_percpu kernel/irq/handle.c:193 [inline]\n\nvalue changed: 0x01 -> 0x00\n==================================================================\n\nWhen the data race occurs, the function virtqueue_enable_cb_delayed() sets\nevent_triggered to false, and virtqueue_disable_cb_split/packed() reads it\nas false due to the race condition. Since event_triggered is an unreliable\nhint used for optimization, this should only cause the driver temporarily\nsuggest that the device not send an interrupt notification when the event\nindex is used.\n\nFix this KCSAN reported data-race issue by explicitly tagging the access as\ndata_racy.(CVE-2025-38048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm: fix unconditional IO throttle caused by REQ_PREFLUSH\n\nWhen a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush()\ngenerates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC,\nwhich causes the flush_bio to be throttled by wbt_wait().\n\nAn example from v5.4, similar problem also exists in upstream:\n\n    crash> bt 2091206\n    PID: 2091206  TASK: ffff2050df92a300  CPU: 109  COMMAND: "kworker/u260:0"\n     #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8\n     #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4\n     #2 [ffff800084a2f880] schedule at ffff800040bfa4b4\n     #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4\n     #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc\n     #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0\n     #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254\n     #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38\n     #8 [ffff800084a2fa60] generic_make_request at ffff800040570138\n     #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4\n    #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs]\n    #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]\n    #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]\n    #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs]\n    #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs]\n    #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]\n    #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08\n    #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc\n    #18 [ffff800084a2fe70] kthread at ffff800040118de4\n\nAfter commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"),\nthe metadata submitted by xlog_write_iclog() should not be throttled.\nBut due to the existence of the dm layer, throttling flush_bio indirectly\ncauses the metadata bio to be throttled.\n\nFix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes\nwbt_should_throttle() return false to avoid wbt_wait().(CVE-2025-38063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: make sure that ptp_rate is not 0 before configuring EST\n\nIf the ptp_rate recorded earlier in the driver happens to be 0, this\nbogus value will propagate up to EST configuration, where it will\ntrigger a division by 0.\n\nPrevent this division by 0 by adding the corresponding check and error\ncode.(CVE-2025-38125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: Fix potential null-ptr-deref in mlb_usio_probe()\n\ndevm_ioremap() can return NULL on error. Currently, mlb_usio_probe()\ndoes not check for this case, which could result in a NULL pointer\ndereference.\n\nAdd NULL check after devm_ioremap() to prevent this issue.(CVE-2025-38135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\naspeed_lpc_enable_snoop() does not check for this case, which results in a\nNULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue.\n\n[arj: Fix Fixes: tag to use subject from 3772e5da4454](CVE-2025-38145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncalipso: Fix null-ptr-deref in calipso_req_{set,del}attr().\n\nsyzkaller reported a null-ptr-deref in sock_omalloc() while allocating\na CALIPSO option.  [0]\n\nThe NULL is of struct sock, which was fetched by sk_to_full_sk() in\ncalipso_req_setattr().\n\nSince commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),\nreqsk->rsk_listener could be NULL when SYN Cookie is returned to its\nclient, as hinted by the leading SYN Cookie log.\n\nHere are 3 options to fix the bug:\n\n  1) Return 0 in calipso_req_setattr()\n  2) Return an error in calipso_req_setattr()\n  3) Alaways set rsk_listener\n\n1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie\nfor CALIPSO.  3) is also no go as there have been many efforts to reduce\natomic ops and make TCP robust against DDoS.  See also commit 3b24d854cb35\n("tcp/dccp: do not touch listener sk_refcnt under synflood").\n\nAs of the blamed commit, SYN Cookie already did not need refcounting,\nand no one has stumbled on the bug for 9 years, so no CALIPSO user will\ncare about SYN Cookie.\n\nLet's return an error in calipso_req_setattr() and calipso_req_delattr()\nin the SYN Cookie case.\n\nThis can be reproduced by [1] on Fedora and now connect() of nc times out.\n\n[0]:\nTCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\nCPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]\nRIP: 0010:sock_net include/net/sock.h:655 [inline]\nRIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806\nCode: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b\nRSP: 0018:ffff88811af89038 EFLAGS: 00010216\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400\nRDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030\nRBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e\nR10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000\nR13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050\nFS:  00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0\nPKRU: 80000000\nCall Trace:\n <IRQ>\n ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288\n calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204\n calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597\n netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249\n selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342\n selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551\n security_inet_conn_request+0x50/0xa0 security/security.c:4945\n tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825\n tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275\n tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328\n tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781\n tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667\n tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904\n ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436\n ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netfilter.h:308 [inline]\n ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491\n dst_input include/net/dst.h:469 [inline]\n ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]\n ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netf\n---truncated---(CVE-2025-38181)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix uprobe pte be overwritten when expanding vma\n\nPatch series "Fix uprobe pte be overwritten when expanding vma".\n\n\nThis patch (of 4):\n\nWe encountered a BUG alert triggered by Syzkaller as follows:\n   BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1\n\nAnd we can reproduce it with the following steps:\n1. register uprobe on file at zero offset\n2. mmap the file at zero offset:\n   addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);\n3. mremap part of vma1 to new vma2:\n   addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);\n4. mremap back to orig addr1:\n   mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);\n\nIn step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2\nwith range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1\nto vma2, then unmap the vma1 range [addr1, addr1 + 4096].\n\nIn step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the\naddr range [addr1, addr1 + 4096].  Since the addr range [addr1 + 4096,\naddr1 + 8192] still maps the file, it will take vma_merge_new_range to\nexpand the range, and then do uprobe_mmap in vma_complete.  Since the\nmerged vma pgoff is also zero offset, it will install uprobe anon page to\nthe merged vma.  However, the upcomming move_page_tables step, which use\nset_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite\nthe newly uprobe pte in the merged vma, and lead that pte to be orphan.\n\nSince the uprobe pte will be remapped to the merged vma, we can remove the\nunnecessary uprobe_mmap upon merged vma.\n\nThis problem was first found in linux-6.6.y and also exists in the\ncommunity syzkaller:\nhttps://lore.kernel.org/all/(CVE-2025-38207)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: inline: fix len overflow in ext4_prepare_inline_data\n\nWhen running the following code on an ext4 filesystem with inline_data\nfeature enabled, it will lead to the bug below.\n\n        fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666);\n        ftruncate(fd, 30);\n        pwrite(fd, "a", 1, (1UL << 40) + 5UL);\n\nThat happens because write_begin will succeed as when\next4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len\nwill be truncated, leading to ext4_prepare_inline_data parameter to be 6\ninstead of 0x10000000006.\n\nThen, later when write_end is called, we hit:\n\n        BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);\n\nat ext4_write_inline_data.\n\nFix it by using a loff_t type for the len parameter in\next4_prepare_inline_data instead of an unsigned int.\n\n[   44.545164] ------------[ cut here ]------------\n[   44.545530] kernel BUG at fs/ext4/inline.c:240!\n[   44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI\n[   44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full)  112853fcebfdb93254270a7959841d2c6aa2c8bb\n[   44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[   44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100\n[   44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49\n[   44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216\n[   44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006\n[   44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738\n[   44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\n[   44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000\n[   44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738\n[   44.546523] FS:  00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000\n[   44.546523] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0\n[   44.546523] PKRU: 55555554\n[   44.546523] Call Trace:\n[   44.546523]  <TASK>\n[   44.546523]  ext4_write_inline_data_end+0x126/0x2d0\n[   44.546523]  generic_perform_write+0x17e/0x270\n[   44.546523]  ext4_buffered_write_iter+0xc8/0x170\n[   44.546523]  vfs_write+0x2be/0x3e0\n[   44.546523]  __x64_sys_pwrite64+0x6d/0xc0\n[   44.546523]  do_syscall_64+0x6a/0xf0\n[   44.546523]  ? __wake_up+0x89/0xb0\n[   44.546523]  ? xas_find+0x72/0x1c0\n[   44.546523]  ? next_uptodate_folio+0x317/0x330\n[   44.546523]  ? set_pte_range+0x1a6/0x270\n[   44.546523]  ? filemap_map_pages+0x6ee/0x840\n[   44.546523]  ? ext4_setattr+0x2fa/0x750\n[   44.546523]  ? do_pte_missing+0x128/0xf70\n[   44.546523]  ? security_inode_post_setattr+0x3e/0xd0\n[   44.546523]  ? ___pte_offset_map+0x19/0x100\n[   44.546523]  ? handle_mm_fault+0x721/0xa10\n[   44.546523]  ? do_user_addr_fault+0x197/0x730\n[   44.546523]  ? do_syscall_64+0x76/0xf0\n[   44.546523]  ? arch_exit_to_user_mode_prepare+0x1e/0x60\n[   44.546523]  ? irqentry_exit_to_user_mode+0x79/0x90\n[   44.546523]  entry_SYSCALL_64_after_hwframe+0x55/0x5d\n[   44.546523] RIP: 0033:0x7f42999c6687\n[   44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff\n[   44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012\n[   44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687\n[   44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003\n[   44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000\n[   44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000\n---truncated---(CVE-2025-38222)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt: properly flush XDP redirect lists\n\nWe encountered following crash when testing a XDP_REDIRECT feature\nin production:\n\n[56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd\n40f30).\n[56251.601413] ------------[ cut here ]------------\n[56251.611357] kernel BUG at lib/list_debug.c:29!\n[56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P           O       6.12.33-cloudflare-2025.6.\n3 #1\n[56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE\n[56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025\n[56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0\n[56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48\n 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89\n[56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246\n[56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000\n[56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80\n[56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18\n[56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000\n[56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40\n[56251.796278] FS:  0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000\n[56251.809133] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0\n[56251.831365] PKRU: 55555554\n[56251.838653] Call Trace:\n[56251.845560]  <IRQ>\n[56251.851943]  cpu_map_enqueue.cold+0x5/0xa\n[56251.860243]  xdp_do_redirect+0x2d9/0x480\n[56251.868388]  bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en]\n[56251.877028]  bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en]\n[56251.885665]  ? cpu_max_write+0x1e/0x100\n[56251.893510]  ? srso_alias_return_thunk+0x5/0xfbef5\n[56251.902276]  __bnxt_poll_work+0x190/0x340 [bnxt_en]\n[56251.911058]  bnxt_poll+0xab/0x1b0 [bnxt_en]\n[56251.919041]  ? srso_alias_return_thunk+0x5/0xfbef5\n[56251.927568]  ? srso_alias_return_thunk+0x5/0xfbef5\n[56251.935958]  ? srso_alias_return_thunk+0x5/0xfbef5\n[56251.944250]  __napi_poll+0x2b/0x160\n[56251.951155]  bpf_trampoline_6442548651+0x79/0x123\n[56251.959262]  __napi_poll+0x5/0x160\n[56251.966037]  net_rx_action+0x3d2/0x880\n[56251.973133]  ? srso_alias_return_thunk+0x5/0xfbef5\n[56251.981265]  ? srso_alias_return_thunk+0x5/0xfbef5\n[56251.989262]  ? __hrtimer_run_queues+0x162/0x2a0\n[56251.996967]  ? srso_alias_return_thunk+0x5/0xfbef5\n[56252.004875]  ? srso_alias_return_thunk+0x5/0xfbef5\n[56252.012673]  ? bnxt_msix+0x62/0x70 [bnxt_en]\n[56252.019903]  handle_softirqs+0xcf/0x270\n[56252.026650]  irq_exit_rcu+0x67/0x90\n[56252.032933]  common_interrupt+0x85/0xa0\n[56252.039498]  </IRQ>\n[56252.044246]  <TASK>\n[56252.048935]  asm_common_interrupt+0x26/0x40\n[56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420\n[56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae\n 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29\n[56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202\n[56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000\n[56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000\n[56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e\n[56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860\n[56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000\n[56252.146667]  ? cpuidle_enter_state+0xab/0x420\n[56252.153909]  cpuidle_enter+0x2d/0x40\n[56252.160360]  do_idle+0x176/0x1c0\n[56252.166456\n---truncated---(CVE-2025-38246)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: jsm: fix NPE during jsm_uart_port_init\n\nNo device was set which caused serial_base_ctrl_add to crash.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000050\n Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1  Debian 6.12.25-1\n RIP: 0010:serial_base_ctrl_add+0x96/0x120\n Call Trace:\n  <TASK>\n  serial_core_register_port+0x1a0/0x580\n  ? __setup_irq+0x39c/0x660\n  ? __kmalloc_cache_noprof+0x111/0x310\n  jsm_uart_port_init+0xe8/0x180 [jsm]\n  jsm_probe_one+0x1f4/0x410 [jsm]\n  local_pci_probe+0x42/0x90\n  pci_device_probe+0x22f/0x270\n  really_probe+0xdb/0x340\n  ? pm_runtime_barrier+0x54/0x90\n  ? __pfx___driver_attach+0x10/0x10\n  __driver_probe_device+0x78/0x110\n  driver_probe_device+0x1f/0xa0\n  __driver_attach+0xba/0x1c0\n  bus_for_each_dev+0x8c/0xe0\n  bus_add_driver+0x112/0x1f0\n  driver_register+0x72/0xd0\n  jsm_init_module+0x36/0xff0 [jsm]\n  ? __pfx_jsm_init_module+0x10/0x10 [jsm]\n  do_one_initcall+0x58/0x310\n  do_init_module+0x60/0x230\n\nTested with Digi Neo PCIe 8 port card.(CVE-2025-38265)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Use memcpy() for BIOS version\n\nThe strlcat() with FORTIFY support is triggering a panic because it\nthinks the target buffer will overflow although the correct target\nbuffer size is passed in.\n\nAnyway, instead of memset() with 0 followed by a strlcat(), just use\nmemcpy() and ensure that the resulting buffer is NULL terminated.\n\nBIOSVersion is only used for the lpfc_printf_log() which expects a\nproperly terminated string.(CVE-2025-38332)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()\n\nSometimes, when a file was read while it was being truncated by\nanother NFS client, the kernel could deadlock because folio_unlock()\nwas called twice, and the second call would XOR back the `PG_locked`\nflag.\n\nMost of the time (depending on the timing of the truncation), nobody\nnotices the problem because folio_unlock() gets called three times,\nwhich flips `PG_locked` back off:\n\n 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,\n    nfs_return_empty_folio\n 2. vfs_read, nfs_read_folio, ... netfs_read_collection,\n    netfs_unlock_abandoned_read_pages\n 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,\n    nfs_return_empty_folio\n\nThe problem is that nfs_read_add_folio() is not supposed to unlock the\nfolio if fscache is enabled, and a nfs_netfs_folio_unlock() check is\nmissing in nfs_return_empty_folio().\n\nRarely this leads to a warning in netfs_read_collection():\n\n ------------[ cut here ]------------\n R=0000031c: folio 10 is not locked\n WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00\n [...]\n Workqueue: events_unbound netfs_read_collection_worker\n RIP: 0010:netfs_read_collection+0x7c0/0xf00\n [...]\n Call Trace:\n  <TASK>\n  netfs_read_collection_worker+0x67/0x80\n  process_one_work+0x12e/0x2c0\n  worker_thread+0x295/0x3a0\n\nMost of the time, however, processes just get stuck forever in\nfolio_wait_bit_common(), waiting for `PG_locked` to disappear, which\nnever happens because nobody is really holding the folio lock.(CVE-2025-38338)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: fix acpi operand cache leak in dswstate.c\n\nACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732\n\nI found an ACPI cache leak in ACPI early termination and boot continuing case.\n\nWhen early termination occurs due to malicious ACPI table, Linux kernel\nterminates ACPI function and continues to boot process. While kernel terminates\nACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.\n\nBoot log of ACPI operand cache leak is as follows:\n>[    0.585957] ACPI: Added _OSI(Module Device)\n>[    0.587218] ACPI: Added _OSI(Processor Device)\n>[    0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)\n>[    0.589790] ACPI: Added _OSI(Processor Aggregator Device)\n>[    0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)\n>[    0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)\n>[    0.597858] ACPI: Unable to start the ACPI Interpreter\n>[    0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)\n>[    0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects\n>[    0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26\n>[    0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006\n>[    0.609177] Call Trace:\n>[    0.610063]  ? dump_stack+0x5c/0x81\n>[    0.611118]  ? kmem_cache_destroy+0x1aa/0x1c0\n>[    0.612632]  ? acpi_sleep_proc_init+0x27/0x27\n>[    0.613906]  ? acpi_os_delete_cache+0xa/0x10\n>[    0.617986]  ? acpi_ut_delete_caches+0x3f/0x7b\n>[    0.619293]  ? acpi_terminate+0xa/0x14\n>[    0.620394]  ? acpi_init+0x2af/0x34f\n>[    0.621616]  ? __class_create+0x4c/0x80\n>[    0.623412]  ? video_setup+0x7f/0x7f\n>[    0.624585]  ? acpi_sleep_proc_init+0x27/0x27\n>[    0.625861]  ? do_one_initcall+0x4e/0x1a0\n>[    0.627513]  ? kernel_init_freeable+0x19e/0x21f\n>[    0.628972]  ? rest_init+0x80/0x80\n>[    0.630043]  ? kernel_init+0xa/0x100\n>[    0.631084]  ? ret_from_fork+0x25/0x30\n>[    0.633343] vgaarb: loaded\n>[    0.635036] EDAC MC: Ver: 3.0.0\n>[    0.638601] PCI: Probing PCI hardware\n>[    0.639833] PCI host bridge to bus 0000:00\n>[    0.641031] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]\n> ... Continue to boot and log is omitted ...\n\nI analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_\ndelete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()\nfunction uses walk_state->operand_index for start position of the top, but\nacpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.\nTherefore, this causes acpi operand memory leak.\n\nThis cache leak causes a security threat because an old kernel (<= 4.9) shows\nmemory locations of kernel functions in stack dump. Some malicious users\ncould use this information to neutralize kernel ASLR.\n\nI made a patch to fix ACPI operand cache leak.(CVE-2025-38345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add null pointer check for get_first_active_display()\n\nThe function mod_hdcp_hdcp1_enable_encryption() calls the function\nget_first_active_display(), but does not check its return value.\nThe return value is a null pointer if the display list is empty.\nThis will lead to a null pointer dereference in\nmod_hdcp_hdcp2_enable_encryption().\n\nAdd a null pointer check for get_first_active_display() and return\nMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.(CVE-2025-38362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Disable interrupts before resetting the GPU\n\nCurrently, an interrupt can be triggered during a GPU reset, which can\nlead to GPU hangs and NULL pointer dereference in an interrupt context\nas shown in the following trace:\n\n [  314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0\n [  314.043822] Mem abort info:\n [  314.046606]   ESR = 0x0000000096000005\n [  314.050347]   EC = 0x25: DABT (current EL), IL = 32 bits\n [  314.055651]   SET = 0, FnV = 0\n [  314.058695]   EA = 0, S1PTW = 0\n [  314.061826]   FSC = 0x05: level 1 translation fault\n [  314.066694] Data abort info:\n [  314.069564]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n [  314.075039]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n [  314.080080]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n [  314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000\n [  314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000\n [  314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP\n [  314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight\n [  314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1  Debian 1:6.12.25-1+rpt1\n [  314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)\n [  314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n [  314.152165] pc : v3d_irq+0xec/0x2e0 [v3d]\n [  314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d]\n [  314.160198] sp : ffffffc080003ea0\n [  314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000\n [  314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0\n [  314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000\n [  314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000\n [  314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000\n [  314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001\n [  314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874\n [  314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180\n [  314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb\n [  314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000\n [  314.234807] Call trace:\n [  314.237243]  v3d_irq+0xec/0x2e0 [v3d]\n [  314.240906]  __handle_irq_event_percpu+0x58/0x218\n [  314.245609]  handle_irq_event+0x54/0xb8\n [  314.249439]  handle_fasteoi_irq+0xac/0x240\n [  314.253527]  handle_irq_desc+0x48/0x68\n [  314.257269]  generic_handle_domain_irq+0x24/0x38\n [  314.261879]  gic_handle_irq+0x48/0xd8\n [  314.265533]  call_on_irq_stack+0x24/0x58\n [  314.269448]  do_interrupt_handler+0x88/0x98\n [  314.273624]  el1_interrupt+0x34/0x68\n [  314.277193]  el1h_64_irq_handler+0x18/0x28\n [  314.281281]  el1h_64_irq+0x64/0x68\n [  314.284673]  default_idle_call+0x3c/0x168\n [  314.288675]  do_idle+0x1fc/0x230\n [  314.291895]  cpu_startup_entry+0x3c/0x50\n [  314.295810]  rest_init+0xe4/0xf0\n [  314.299030]  start_kernel+0x5e8/0x790\n [  314.302684]  __primary_switched+0x80/0x90\n [  314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017)\n [  314.312775] ---[ end trace 0000000000000000 ]---\n [  314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt\n [  314.324249] SMP: stopping secondary CPUs\n [  314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000\n [  314.334076] PHYS_OFFSET: 0x0\n [  314.336946] CPU features: 0x08,00002013,c0200000,0200421b\n [  314.342337] Memory Limit: none\n [  314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---\n\nBefore resetting the G\n---truncated---(CVE-2025-38371)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c/designware: Fix an initialization issue\n\nThe i2c_dw_xfer_init() function requires msgs and msg_write_idx from the\ndev context to be initialized.\n\namd_i2c_dw_xfer_quirk() inits msgs and msgs_num, but not msg_write_idx.\n\nThis could allow an out of bounds access (of msgs).\n\nInitialize msg_write_idx before calling i2c_dw_xfer_init().(CVE-2025-38380)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect\n\nRemove redundant netif_napi_del() call from disconnect path.\n\nA WARN may be triggered in __netif_napi_del_locked() during USB device\ndisconnect:\n\n  WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350\n\nThis happens because netif_napi_del() is called in the disconnect path while\nNAPI is still enabled. However, it is not necessary to call netif_napi_del()\nexplicitly, since unregister_netdev() will handle NAPI teardown automatically\nand safely. Removing the redundant call avoids triggering the warning.\n\nFull trace:\n lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV\n lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV\n lan78xx 1-1:1.0 enu1: Link is Down\n lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350\n Modules linked in: flexcan can_dev fuse\n CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT\n Hardware name: SKOV IMX8MP CPU revC - bd500 (DT)\n Workqueue: usb_hub_wq hub_event\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __netif_napi_del_locked+0x2b4/0x350\n lr : __netif_napi_del_locked+0x7c/0x350\n sp : ffffffc085b673c0\n x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8\n x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb\n x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000\n x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000\n x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028\n x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8\n x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000\n x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001\n x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000\n Call trace:\n  __netif_napi_del_locked+0x2b4/0x350 (P)\n  lan78xx_disconnect+0xf4/0x360\n  usb_unbind_interface+0x158/0x718\n  device_remove+0x100/0x150\n  device_release_driver_internal+0x308/0x478\n  device_release_driver+0x1c/0x30\n  bus_remove_device+0x1a8/0x368\n  device_del+0x2e0/0x7b0\n  usb_disable_device+0x244/0x540\n  usb_disconnect+0x220/0x758\n  hub_event+0x105c/0x35e0\n  process_one_work+0x760/0x17b0\n  worker_thread+0x768/0xce8\n  kthread+0x3bc/0x690\n  ret_from_fork+0x10/0x20\n irq event stamp: 211604\n hardirqs last  enabled at (211603): [<ffffffc0828cc9ec>] _raw_spin_unlock_irqrestore+0x84/0x98\n hardirqs last disabled at (211604): [<ffffffc0828a9a84>] el1_dbg+0x24/0x80\n softirqs last  enabled at (211296): [<ffffffc080095f10>] handle_softirqs+0x820/0xbc8\n softirqs last disabled at (210993): [<ffffffc080010288>] __do_softirq+0x18/0x20\n ---[ end trace 0000000000000000 ]---\n lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0(CVE-2025-38385)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Refuse to evaluate a method if arguments are missing\n\nAs reported in [1], a platform firmware update that increased the number\nof method parameters and forgot to update a least one of its callers,\ncaused ACPICA to crash due to use-after-free.\n\nSince this a result of a clear AML issue that arguably cannot be fixed\nup by the interpreter (it cannot produce missing data out of thin air),\naddress it by making ACPICA refuse to evaluate a method if the caller\nattempts to pass fewer arguments than expected to it.(CVE-2025-38386)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insert\n\nThe obj_event may be loaded immediately after inserted, then if the\nlist_head is not initialized then we may get a poisonous pointer.  This\nfixes the crash below:\n\n mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced)\n mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056\n mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0\n mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps\n IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060\n Mem abort info:\n   ESR = 0x96000006\n   EC = 0x25: DABT (current EL), IL = 32 bits\n   SET = 0, FnV = 0\n   EA = 0, S1PTW = 0\n Data abort info:\n   ISV = 0, ISS = 0x00000006\n   CM = 0, WnR = 0\n user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000\n [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000\n Internal error: Oops: 96000006 [#1] SMP\n Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E)\n  [last unloaded: mst_pci]\n CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G           OE K   5.10.134-13.1.an8.aarch64 #1\n Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023\n pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--)\n pc : dispatch_event_fd+0x68/0x300 [mlx5_ib]\n lr : devx_event_notifier+0xcc/0x228 [mlx5_ib]\n sp : ffff80001005bcf0\n x29: ffff80001005bcf0 x28: 0000000000000001\n x27: ffff244e0740a1d8 x26: ffff244e0740a1d0\n x25: ffffda56beff5ae0 x24: ffffda56bf911618\n x23: ffff244e0596a480 x22: ffff244e0596a480\n x21: ffff244d8312ad90 x20: ffff244e0596a480\n x19: fffffffffffffff0 x18: 0000000000000000\n x17: 0000000000000000 x16: ffffda56be66d620\n x15: 0000000000000000 x14: 0000000000000000\n x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000040 x10: ffffda56bfcafb50\n x9 : ffffda5655c25f2c x8 : 0000000000000010\n x7 : 0000000000000000 x6 : ffff24545a2e24b8\n x5 : 0000000000000003 x4 : ffff80001005bd28\n x3 : 0000000000000000 x2 : 0000000000000000\n x1 : ffff244e0596a480 x0 : ffff244d8312ad90\n Call trace:\n  dispatch_event_fd+0x68/0x300 [mlx5_ib]\n  devx_event_notifier+0xcc/0x228 [mlx5_ib]\n  atomic_notifier_call_chain+0x58/0x80\n  mlx5_eq_async_int+0x148/0x2b0 [mlx5_core]\n  atomic_notifier_call_chain+0x58/0x80\n  irq_int_handler+0x20/0x30 [mlx5_core]\n  __handle_irq_event_percpu+0x60/0x220\n  handle_irq_event_percpu+0x3c/0x90\n  handle_irq_event+0x58/0x158\n  handle_fasteoi_irq+0xfc/0x188\n  generic_handle_irq+0x34/0x48\n  ...(CVE-2025-38387)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass\n\nExport anon_inode_make_secure_inode() to allow KVM guest_memfd to create\nanonymous inodes with proper security context. This replaces the current\npattern of calling alloc_anon_inode() followed by\ninode_init_security_anon() for creating security context manually.\n\nThis change also fixes a security regression in secretmem where the\nS_PRIVATE flag was not cleared after alloc_anon_inode(), causing\nLSM/SELinux checks to be bypassed for secretmem file descriptors.\n\nAs guest_memfd currently resides in the KVM module, we need to export this\nsymbol for use outside the core kernel. In the future, guest_memfd might be\nmoved to core-mm, at which point the symbols no longer would have to be\nexported. When/if that happens is still unclear.(CVE-2025-38396)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.\n\nsyzbot reported a warning below [1] following a fault injection in\nnfs_fs_proc_net_init(). [0]\n\nWhen nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.\n\nLater, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning\nis logged as the directory is not empty.\n\nLet's handle the error of nfs_fs_proc_net_init() properly.\n\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n <TASK>\n  dump_stack_lvl (lib/dump_stack.c:123)\n should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174)\n should_failslab (mm/failslab.c:46)\n kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204)\n __proc_create (fs/proc/generic.c:427)\n proc_create_reg (fs/proc/generic.c:554)\n proc_create_net_data (fs/proc/proc_net.c:120)\n nfs_fs_proc_net_init (fs/nfs/client.c:1409)\n nfs_net_init (fs/nfs/inode.c:2600)\n ops_init (net/core/net_namespace.c:138)\n setup_net (net/core/net_namespace.c:443)\n copy_net_ns (net/core/net_namespace.c:576)\n create_new_namespaces (kernel/nsproxy.c:110)\n unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4))\n ksys_unshare (kernel/fork.c:3123)\n __x64_sys_unshare (kernel/fork.c:3190)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n </TASK>\n\n[1]:\nremove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs'\n WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727\nModules linked in:\nCPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727\nCode: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00\nRSP: 0018:ffffc90003637b08 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8\nRDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001\nRBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00\nR13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000\nFS:  0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n  sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76\n  ops_exit_list net/core/net_namespace.c:200 [inline]\n  ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253\n  setup_net+0x2e1/0x510 net/core/net_namespace.c:457\n  copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574\n  create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110\n  unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218\n  ksys_unshare+0x45b/0xa40 kernel/fork.c:3121\n  __do_sys_unshare kernel/fork.c:3192 [inline]\n  __se_sys_unshare kernel/fork.c:3190 [inline]\n  __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fa1a6b8e929\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 c\n---truncated---(CVE-2025-38400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSquashfs: check return result of sb_min_blocksize\n\nSyzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.\n\nSyzkaller forks multiple processes which after mounting the Squashfs\nfilesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). \nNow if this ioctl occurs at the same time another process is in the\nprocess of mounting a Squashfs filesystem on /dev/loop0, the failure\noccurs.  When this happens the following code in squashfs_fill_super()\nfails.\n\n----\nmsblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);\nmsblk->devblksize_log2 = ffz(~msblk->devblksize);\n----\n\nsb_min_blocksize() returns 0, which means msblk->devblksize is set to 0.\n\nAs a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2\nis set to 64.\n\nThis subsequently causes the\n\nUBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36\nshift exponent 64 is too large for 64-bit type 'u64' (aka\n'unsigned long long')\n\nThis commit adds a check for a 0 return by sb_min_blocksize().(CVE-2025-38415)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix sample vs do_exit()\n\nBaisheng Gao reported an ARM64 crash, which Mark decoded as being a\nsynchronous external abort -- most likely due to trying to access\nMMIO in bad ways.\n\nThe crash further shows perf trying to do a user stack sample while in\nexit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address\nspace it is trying to access.\n\nIt turns out that we stop perf after we tear down the userspace mm; a\nreceipie for disaster, since perf likes to access userspace for\nvarious reasons.\n\nFlip this order by moving up where we stop perf in do_exit().\n\nAdditionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER\nto abort when the current task does not have an mm (exit_mm() makes\nsure to set current->mm = NULL; before commencing with the actual\nteardown). Such that CPU wide events don't trip on this same problem.(CVE-2025-38424)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvideo: screen_info: Relocate framebuffers behind PCI bridges\n\nApply PCI host-bridge window offsets to screen_info framebuffers. Fixes\ninvalid access to I/O memory.\n\nResources behind a PCI host bridge can be relocated by a certain offset\nin the kernel's CPU address range used for I/O. The framebuffer memory\nrange stored in screen_info refers to the CPU addresses as seen during\nboot (where the offset is 0). During boot up, firmware may assign a\ndifferent memory offset to the PCI host bridge and thereby relocating\nthe framebuffer address of the PCI graphics device as seen by the kernel.\nThe information in screen_info must be updated as well.\n\nThe helper pcibios_bus_to_resource() performs the relocation of the\nscreen_info's framebuffer resource (given in PCI bus addresses). The\nresult matches the I/O-memory resource of the PCI graphics device (given\nin CPU addresses). As before, we store away the information necessary to\nlater update the information in screen_info itself.\n\nCommit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated\nEFI framebuffers") added the code for updating screen_info. It is based\non similar functionality that pre-existed in efifb. Efifb uses a pointer\nto the PCI resource, while the newer code does a memcpy of the region.\nHence efifb sees any updates to the PCI resource and avoids the issue.\n\nv3:\n- Only use struct pci_bus_region for PCI bus addresses (Bjorn)\n- Clarify address semantics in commit messages and comments (Bjorn)\nv2:\n- Fixed tags (Takashi, Ivan)\n- Updated information on efifb(CVE-2025-38427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: nfsd4_spo_must_allow() must check this is a v4 compound request\n\nIf the request being processed is not a v4 compound request, then\nexamining the cstate can have undefined results.\n\nThis patch adds a check that the rpc procedure being executed\n(rq_procinfo) is the NFSPROC4_COMPOUND procedure.(CVE-2025-38430)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Set DMA unmap len correctly for XDP_REDIRECT\n\nWhen transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()\nwith the proper length instead of 0.  This bug triggers this warning\non a system with IOMMU enabled:\n\nWARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170\nRIP: 0010:__iommu_dma_unmap+0x159/0x170\nCode: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45\nb8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00\nRSP: 0018:ff22d31181150c88 EFLAGS: 00010206\nRAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000\nR10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000\nR13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00\nFS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0\nPKRU: 55555554\nCall Trace:\n<IRQ>\n? show_regs+0x6d/0x80\n? __warn+0x89/0x160\n? __iommu_dma_unmap+0x159/0x170\n? report_bug+0x17e/0x1b0\n? handle_bug+0x46/0x90\n? exc_invalid_op+0x18/0x80\n? asm_exc_invalid_op+0x1b/0x20\n? __iommu_dma_unmap+0x159/0x170\n? __iommu_dma_unmap+0xb3/0x170\niommu_dma_unmap_page+0x4f/0x100\ndma_unmap_page_attrs+0x52/0x220\n? srso_alias_return_thunk+0x5/0xfbef5\n? xdp_return_frame+0x2e/0xd0\nbnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]\n__bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]\nbnxt_poll+0xd3/0x1e0 [bnxt_en](CVE-2025-38439)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: fix potential out-of-bounds page table access during batched unmap\n\nAs pointed out by David[1], the batched unmap logic in\ntry_to_unmap_one() may read past the end of a PTE table when a large\nfolio's PTE mappings are not fully contained within a single page\ntable.\n\nWhile this scenario might be rare, an issue triggerable from userspace\nmust be fixed regardless of its likelihood.  This patch fixes the\nout-of-bounds access by refactoring the logic into a new helper,\nfolio_unmap_pte_batch().\n\nThe new helper correctly calculates the safe batch size by capping the\nscan at both the VMA and PMD boundaries.  To simplify the code, it also\nsupports partial batching (i.e., any number of pages from 1 up to the\ncalculated safe maximum), as there is no strong reason to special-case\nfor fully mapped folios.(CVE-2025-38447)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Revert to requiring CAP_SYS_ADMIN for uprobes\n\nJann reports that uprobes can be used destructively when used in the\nmiddle of an instruction. The kernel only verifies there is a valid\ninstruction at the requested offset, but due to variable instruction\nlength cannot determine if this is an instruction as seen by the\nintended execution stream.\n\nAdditionally, Mark Rutland notes that on architectures that mix data\nin the text segment (like arm64), a similar things can be done if the\ndata word is 'mistaken' for an instruction.\n\nAs such, require CAP_SYS_ADMIN for uprobes.(CVE-2025-38466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: always refresh the queue when reading sock\n\nAfter recent changes in net-next TCP compacts skbs much more\naggressively. This unearthed a bug in TLS where we may try\nto operate on an old skb when checking if all skbs in the\nqueue have matching decrypt state and geometry.\n\n    BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls]\n    (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544)\n    Read of size 4 at addr ffff888013085750 by task tls/13529\n\n    CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme\n    Call Trace:\n     kasan_report+0xca/0x100\n     tls_strp_check_rcv+0x898/0x9a0 [tls]\n     tls_rx_rec_wait+0x2c9/0x8d0 [tls]\n     tls_sw_recvmsg+0x40f/0x1aa0 [tls]\n     inet_recvmsg+0x1c3/0x1f0\n\nAlways reload the queue, fast path is to have the record in the queue\nwhen we wake, anyway (IOW the path going down "if !strp->stm.full_len").(CVE-2025-38471)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: net: sierra: check for no status endpoint\n\nThe driver checks for having three endpoints and\nhaving bulk in and out endpoints, but not that\nthe third endpoint is interrupt input.\nRectify the omission.(CVE-2025-38474)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-bufio: fix sched in atomic context\n\nIf "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP\nis enabled for dm-bufio. However, when bufio tries to evict buffers, there\nis a chance to trigger scheduling in spin_lock_bh, the following warning\nis hit:\n\nBUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2\npreempt_count: 201, expected: 0\nRCU nest depth: 0, expected: 0\n4 locks held by kworker/2:2/123:\n #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970\n #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970\n #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710\n #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710\nPreemption disabled at:\n[<0000000000000000>] 0x0\nCPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: dm_bufio_cache do_global_cleanup\nCall Trace:\n <TASK>\n dump_stack_lvl+0x53/0x70\n __might_resched+0x360/0x4e0\n do_global_cleanup+0x2f5/0x710\n process_one_work+0x7db/0x1970\n worker_thread+0x518/0xea0\n kthread+0x359/0x690\n ret_from_fork+0xf3/0x1b0\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nThat can be reproduced by:\n\n  veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb\n  SIZE=$(blockdev --getsz /dev/vda)\n  dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 <data_blocks> 1 sha256 <root_hash> <salt> 1 try_verify_in_tasklet"\n  mount /dev/dm-0 /mnt -o ro\n  echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes\n  [read files in /mnt](CVE-2025-38496)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndo_change_type(): refuse to operate on unmounted/not ours mounts\n\nEnsure that propagation settings can only be changed for mounts located\nin the caller's mount namespace. This change aligns permission checking\nwith the rest of mount(2).(CVE-2025-38498)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-104.0.0.107.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","kernel-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","perf-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-104.0.0.107.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-104.0.0.107.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","kernel-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","perf-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-104.0.0.107.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1960"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57982"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21682"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21884"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21891"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37957"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37992"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38040"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38048"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38063"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38125"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38135"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38145"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38181"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38207"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38222"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38246"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38265"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38332"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38338"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38345"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38362"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38371"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38380"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38385"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38386"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38387"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38396"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38400"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38415"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38424"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38427"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38430"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38439"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38447"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38466"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38471"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38474"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38496"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38498"}],"database_specific":{"severity":"High"}}