Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> char: xillybus: Don&amp;#39;t destroy workqueue from work item running on it<br /> <br /> Triggered by a kref decrement, destroy_workqueue() may be called from<br /> within a work item for destroying its own workqueue. This illegal<br /> situation is averted by adding a module-global workqueue for exclusive<br /> use of the offending work item. Other work items continue to be queued<br /> on per-device workqueues to ensure performance.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: MT - limit max slots<br /> <br /> syzbot is reporting too large allocation at input_mt_init_slots(), for<br /> num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).<br /> <br /> Since nobody knows possible max slots, this patch chose 1024.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: avoid possible NULL dereference in cifs_free_subrequest()<br /> <br /> Clang static checker (scan-build) warning:<br /> cifsglob.h:line 890, column 3<br /> Access to field &amp;#39;ops&amp;#39; results in a dereference of a null pointer.<br /> <br /> Commit 519be989717c ("cifs: Add a tracepoint to track credits involved in<br /> R/W requests") adds a check for &amp;#39;rdata-&gt;server&amp;#39;, and let clang throw this<br /> warning about NULL dereference.<br /> <br /> When &amp;#39;rdata-&gt;credits.value != 0 &amp;&amp; rdata-&gt;server == NULL&amp;#39; happens,<br /> add_credits_and_wake_if() will call rdata-&gt;server-&gt;ops-&gt;add_credits().<br /> This will cause NULL dereference problem. Add a check for &amp;#39;rdata-&gt;server&amp;#39;<br /> to avoid NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Fix out-of-bounds read in `v3d_csd_job_run()`<br /> <br /> When enabling UBSAN on Raspberry Pi 5, we get the following warning:<br /> <br /> [ 387.894977] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/v3d/v3d_sched.c:320:3<br /> [ 387.903868] index 7 is out of range for type &amp;#39;__u32 [7]&amp;#39;<br /> [ 387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G WC 6.10.3-v8-16k-numa #151<br /> [ 387.919166] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)<br /> [ 387.925961] Workqueue: v3d_csd drm_sched_run_job_work [gpu_sched]<br /> [ 387.932525] Call trace:<br /> [ 387.935296] dump_backtrace+0x170/0x1b8<br /> [ 387.939403] show_stack+0x20/0x38<br /> [ 387.942907] dump_stack_lvl+0x90/0xd0<br /> [ 387.946785] dump_stack+0x18/0x28<br /> [ 387.950301] __ubsan_handle_out_of_bounds+0x98/0xd0<br /> [ 387.955383] v3d_csd_job_run+0x3a8/0x438 [v3d]<br /> [ 387.960707] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched]<br /> [ 387.966862] process_one_work+0x62c/0xb48<br /> [ 387.971296] worker_thread+0x468/0x5b0<br /> [ 387.975317] kthread+0x1c4/0x1e0<br /> [ 387.978818] ret_from_fork+0x10/0x20<br /> [ 387.983014] ---[ end trace ]---<br /> <br /> This happens because the UAPI provides only seven configuration<br /> registers and we are reading the eighth position of this u32 array.<br /> <br /> Therefore, fix the out-of-bounds read in `v3d_csd_job_run()` by<br /> accessing only seven positions on the &amp;#39;__u32 [7]&amp;#39; array. The eighth<br /> register exists indeed on V3D 7.1, but it isn&amp;#39;t currently used. That<br /> being so, let&amp;#39;s guarantee that it remains unused and add a note that it<br /> could be set in a future patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Restore lost return in iommu_report_device_fault()<br /> <br /> When iommu_report_device_fault gets called with a partial fault it is<br /> supposed to collect the fault into the group and then return.<br /> <br /> Instead the return was accidently deleted which results in trying to<br /> process the fault and an eventual crash.<br /> <br /> Deleting the return was a typo, put it back.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: fix recursive -&gt;recvmsg calls<br /> <br /> After a vsock socket has been added to a BPF sockmap, its prot-&gt;recvmsg<br /> has been replaced with vsock_bpf_recvmsg(). Thus the following<br /> recursiion could happen:<br /> <br /> vsock_bpf_recvmsg()<br /> -&gt; __vsock_recvmsg()<br /> -&gt; vsock_connectible_recvmsg()<br /> -&gt; prot-&gt;recvmsg()<br /> -&gt; vsock_bpf_recvmsg() again<br /> <br /> We need to fix it by calling the original -&gt;recvmsg() without any BPF<br /> sockmap logic in __vsock_recvmsg().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_wed: fix use-after-free panic in mtk_wed_setup_tc_block_cb()<br /> <br /> When there are multiple ap interfaces on one band and with WED on,<br /> turning the interface down will cause a kernel panic on MT798X.<br /> <br /> Previously, cb_priv was freed in mtk_wed_setup_tc_block() without<br /> marking NULL,and mtk_wed_setup_tc_block_cb() didn&amp;#39;t check the value, too.<br /> <br /> Assign NULL after free cb_priv in mtk_wed_setup_tc_block() and check NULL<br /> in mtk_wed_setup_tc_block_cb().<br /> <br /> ----------<br /> Unable to handle kernel paging request at virtual address 0072460bca32b4f5<br /> Call trace:<br /> mtk_wed_setup_tc_block_cb+0x4/0x38<br /> 0xffffffc0794084bc<br /> tcf_block_playback_offloads+0x70/0x1e8<br /> tcf_block_unbind+0x6c/0xc8<br /> ...<br /> ---------

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: trusted: dcp: fix leak of blob encryption key<br /> <br /> Trusted keys unseal the key blob on load, but keep the sealed payload in<br /> the blob field so that every subsequent read (export) will simply<br /> convert this field to hex and send it to userspace.<br /> <br /> With DCP-based trusted keys, we decrypt the blob encryption key (BEK)<br /> in the Kernel due hardware limitations and then decrypt the blob payload.<br /> BEK decryption is done in-place which means that the trusted key blob<br /> field is modified and it consequently holds the BEK in plain text.<br /> Every subsequent read of that key thus send the plain text BEK instead<br /> of the encrypted BEK to userspace.<br /> <br /> This issue only occurs when importing a trusted DCP-based key and<br /> then exporting it again. This should rarely happen as the common use cases<br /> are to either create a new trusted key and export it, or import a key<br /> blob and then just use it without exporting it again.<br /> <br /> Fix this by performing BEK decryption and encryption in a dedicated<br /> buffer. Further always wipe the plain text BEK buffer to prevent leaking<br /> the key via uninitialized memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: s390: fix validity interception issue when gisa is switched off<br /> <br /> We might run into a SIE validity if gisa has been disabled either via using<br /> kernel parameter "kvm.use_gisa=0" or by setting the related sysfs<br /> attribute to N (echo N &gt;/sys/module/kvm/parameters/use_gisa).<br /> <br /> The validity is caused by an invalid value in the SIE control block&amp;#39;s<br /> gisa designation. That happens because we pass the uninitialized gisa<br /> origin to virt_to_phys() before writing it to the gisa designation.<br /> <br /> To fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0.<br /> kvm_s390_get_gisa_desc() is used to determine which gisa designation to<br /> set in the SIE control block. A value of 0 in the gisa designation disables<br /> gisa usage.<br /> <br /> The issue surfaces in the host kernel with the following kernel message as<br /> soon a new kvm guest start is attemted.<br /> <br /> kvm: unhandled validity intercept 0x1011<br /> WARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]<br /> Modules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci]<br /> CPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6<br /> Hardware name: IBM 3931 A01 701 (LPAR)<br /> Krnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm])<br /> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3<br /> Krnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000<br /> 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff<br /> 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412<br /> 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960<br /> Krnl Code: 000003d93deb0112: c020fffe7259 larl %r2,000003d93de7e5c4<br /> 000003d93deb0118: c0e53fa8beac brasl %r14,000003d9bd3c7e70<br /> #000003d93deb011e: af000000 mc 0,0<br /> &gt;000003d93deb0122: a728ffea lhi %r2,-22<br /> 000003d93deb0126: a7f4fe24 brc 15,000003d93deafd6e<br /> 000003d93deb012a: 9101f0b0 tm 176(%r15),1<br /> 000003d93deb012e: a774fe48 brc 7,000003d93deafdbe<br /> 000003d93deb0132: 40a0f0ae sth %r10,174(%r15)<br /> Call Trace:<br /> [] kvm_handle_sie_intercept+0x432/0x4d0 [kvm]<br /> ([] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm])<br /> [] vcpu_post_run+0x1d0/0x3b0 [kvm]<br /> [] __vcpu_run+0xea/0x2d0 [kvm]<br /> [] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm]<br /> [] kvm_vcpu_ioctl+0x190/0x7c0 [kvm]<br /> [] vfs_ioctl+0x2e/0x70<br /> [] __s390x_sys_ioctl+0xc2/0xd0<br /> [] __do_syscall+0x1f2/0x2e0<br /> [] system_call+0x70/0x98<br /> Last Breaking-Event-Address:<br /> [] __warn_printk+0xe8/0xf0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix RX buf alloc_size alignment and atomic op panic<br /> <br /> The MANA driver&amp;#39;s RX buffer alloc_size is passed into napi_build_skb() to<br /> create SKB. skb_shinfo(skb) is located at the end of skb, and its alignment<br /> is affected by the alloc_size passed into napi_build_skb(). The size needs<br /> to be aligned properly for better performance and atomic operations.<br /> Otherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic<br /> operations may panic on the skb_shinfo(skb)-&gt;dataref due to alignment fault.<br /> <br /> To fix this bug, add proper alignment to the alloc_size calculation.<br /> <br /> Sample panic info:<br /> [ 253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce<br /> [ 253.300900] Mem abort info:<br /> [ 253.301760] ESR = 0x0000000096000021<br /> [ 253.302825] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 253.304268] SET = 0, FnV = 0<br /> [ 253.305172] EA = 0, S1PTW = 0<br /> [ 253.306103] FSC = 0x21: alignment fault<br /> Call trace:<br /> __skb_clone+0xfc/0x198<br /> skb_clone+0x78/0xe0<br /> raw6_local_deliver+0xfc/0x228<br /> ip6_protocol_deliver_rcu+0x80/0x500<br /> ip6_input_finish+0x48/0x80<br /> ip6_input+0x48/0xc0<br /> ip6_sublist_rcv_finish+0x50/0x78<br /> ip6_sublist_rcv+0x1cc/0x2b8<br /> ipv6_list_rcv+0x100/0x150<br /> __netif_receive_skb_list_core+0x180/0x220<br /> netif_receive_skb_list_internal+0x198/0x2a8<br /> __napi_poll+0x138/0x250<br /> net_rx_action+0x148/0x330<br /> handle_softirqs+0x12c/0x3a0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix xfrm real_dev null pointer dereference<br /> <br /> We shouldn&amp;#39;t set real_dev to NULL because packets can be in transit and<br /> xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume<br /> real_dev is set.<br /> <br /> Example trace:<br /> kernel: BUG: unable to handle page fault for address: 0000000000001030<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: #PF: supervisor write access in kernel mode<br /> kernel: #PF: error_code(0x0002) - not-present page<br /> kernel: PGD 0 P4D 0<br /> kernel: Oops: 0002 [#1] PREEMPT SMP<br /> kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12<br /> kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel:<br /> kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60<br /> kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00<br /> kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014<br /> kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000<br /> kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000<br /> kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000<br /> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: Call Trace:<br /> kernel: <br /> kernel: ? __die+0x1f/0x60<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel: ? page_fault_oops+0x142/0x4c0<br /> kernel: ? do_user_addr_fault+0x65/0x670<br /> kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: ? exc_page_fault+0x7b/0x180<br /> kernel: ? asm_exc_page_fault+0x22/0x30<br /> kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim]<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding]<br /> kernel: xfrm_output+0x61/0x3b0<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel: ip_push_pending_frames+0x56/0x80

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix null pointer deref in bond_ipsec_offload_ok<br /> <br /> We must check if there is an active slave before dereferencing the pointer.