Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: account for current allocated stack depth in widen_imprecise_scalars()<br /> <br /> The usage pattern for widen_imprecise_scalars() looks as follows:<br /> <br /> prev_st = find_prev_entry(env, ...);<br /> queued_st = push_stack(...);<br /> widen_imprecise_scalars(env, prev_st, queued_st);<br /> <br /> Where prev_st is an ancestor of the queued_st in the explored states<br /> tree. This ancestor is not guaranteed to have same allocated stack<br /> depth as queued_st. E.g. in the following case:<br /> <br /> def main():<br /> for i in 1..2:<br /> foo(i) // same callsite, differnt param<br /> <br /> def foo(i):<br /> if i == 1:<br /> use 128 bytes of stack<br /> iterator based loop<br /> <br /> Here, for a second &amp;#39;foo&amp;#39; call prev_st-&gt;allocated_stack is 128,<br /> while queued_st-&gt;allocated_stack is much smaller.<br /> widen_imprecise_scalars() needs to take this into account and avoid<br /> accessing bpf_verifier_state-&gt;frame[*]-&gt;stack out of bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlx5: Fix default values in create CQ<br /> <br /> Currently, CQs without a completion function are assigned the<br /> mlx5_add_cq_to_tasklet function by default. This is problematic since<br /> only user CQs created through the mlx5_ib driver are intended to use<br /> this function.<br /> <br /> Additionally, all CQs that will use doorbells instead of polling for<br /> completions must call mlx5_cq_arm. However, the default CQ creation flow<br /> leaves a valid value in the CQ&amp;#39;s arm_db field, allowing FW to send<br /> interrupts to polling-only CQs in certain corner cases.<br /> <br /> These two factors would allow a polling-only kernel CQ to be triggered<br /> by an EQ interrupt and call a completion function intended only for user<br /> CQs, causing a null pointer exception.<br /> <br /> Some areas in the driver have prevented this issue with one-off fixes<br /> but did not address the root cause.<br /> <br /> This patch fixes the described issue by adding defaults to the create CQ<br /> flow. It adds a default dummy completion function to protect against<br /> null pointer exceptions, and it sets an invalid command sequence number<br /> by default in kernel CQs to prevent the FW from sending an interrupt to<br /> the CQ until it is armed. User CQs are responsible for their own<br /> initialization values.<br /> <br /> Callers of mlx5_core_create_cq are responsible for changing the<br /> completion function and arming the CQ per their needs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: avoid infinite loop due to incomplete zstd-compressed data<br /> <br /> Currently, the decompression logic incorrectly spins if compressed<br /> data is truncated in crafted (deliberately corrupted) images.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc: Add devm release action to safely tear down CT<br /> <br /> When a buffer object (BO) is allocated with the XE_BO_FLAG_GGTT_INVALIDATE<br /> flag, the driver initiates TLB invalidation requests via the CTB mechanism<br /> while releasing the BO. However a premature release of the CTB BO can lead<br /> to system crashes, as observed in:<br /> <br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> RIP: 0010:h2g_write+0x2f3/0x7c0 [xe]<br /> Call Trace:<br /> guc_ct_send_locked+0x8b/0x670 [xe]<br /> xe_guc_ct_send_locked+0x19/0x60 [xe]<br /> send_tlb_invalidation+0xb4/0x460 [xe]<br /> xe_gt_tlb_invalidation_ggtt+0x15e/0x2e0 [xe]<br /> ggtt_invalidate_gt_tlb.part.0+0x16/0x90 [xe]<br /> ggtt_node_remove+0x110/0x140 [xe]<br /> xe_ggtt_node_remove+0x40/0xa0 [xe]<br /> xe_ggtt_remove_bo+0x87/0x250 [xe]<br /> <br /> Introduce a devm-managed release action during xe_guc_ct_init() and<br /> xe_guc_ct_init_post_hwconfig() to ensure proper CTB disablement before<br /> resource deallocation, preventing the use-after-free scenario.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imon: make send_packet() more robust<br /> <br /> syzbot is reporting that imon has three problems which result in<br /> hung tasks due to forever holding device lock [1].<br /> <br /> First problem is that when usb_rx_callback_intf0() once got -EPROTO error<br /> after ictx-&gt;dev_present_intf0 became true, usb_rx_callback_intf0()<br /> resubmits urb after printk(), and resubmitted urb causes<br /> usb_rx_callback_intf0() to again get -EPROTO error. This results in<br /> printk() flooding (RCU stalls).<br /> <br /> Alan Stern commented [2] that<br /> <br /> In theory it&amp;#39;s okay to resubmit _if_ the driver has a robust<br /> error-recovery scheme (such as giving up after some fixed limit on the<br /> number of errors or after some fixed time has elapsed, perhaps with a<br /> time delay to prevent a flood of errors). Most drivers don&amp;#39;t bother to<br /> do this; they simply give up right away. This makes them more<br /> vulnerable to short-term noise interference during USB transfers, but in<br /> reality such interference is quite rare. There&amp;#39;s nothing really wrong<br /> with giving up right away.<br /> <br /> but imon has a poor error-recovery scheme which just retries forever;<br /> this behavior should be fixed.<br /> <br /> Since I&amp;#39;m not sure whether it is safe for imon users to give up upon any<br /> error code, this patch takes care of only union of error codes chosen from<br /> modules in drivers/media/rc/ directory which handle -EPROTO error (i.e.<br /> ir_toy, mceusb and igorplugusb).<br /> <br /> Second problem is that when usb_rx_callback_intf0() once got -EPROTO error<br /> before ictx-&gt;dev_present_intf0 becomes true, usb_rx_callback_intf0() always<br /> resubmits urb due to commit 8791d63af0cf ("[media] imon: don&amp;#39;t wedge<br /> hardware after early callbacks"). Move the ictx-&gt;dev_present_intf0 test<br /> introduced by commit 6f6b90c9231a ("[media] imon: don&amp;#39;t parse scancodes<br /> until intf configured") to immediately before imon_incoming_packet(), or<br /> the first problem explained above happens without printk() flooding (i.e.<br /> hung task).<br /> <br /> Third problem is that when usb_rx_callback_intf0() is not called for some<br /> reason (e.g. flaky hardware; the reproducer for this problem sometimes<br /> prevents usb_rx_callback_intf0() from being called),<br /> wait_for_completion_interruptible() in send_packet() never returns (i.e.<br /> hung task). As a workaround for such situation, change send_packet() to<br /> wait for completion with timeout of 10 seconds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcode<br /> <br /> Running x86_match_min_microcode_rev() on a Zen5 CPU trips up KASAN for an out<br /> of bounds access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Cache streams targeting link when performing LT automation<br /> <br /> [WHY]<br /> Last LT automation update can cause crash by referencing current_state and<br /> calling into dc_update_planes_and_stream which may clobber current_state.<br /> <br /> [HOW]<br /> Cache relevant stream pointers and iterate through them instead of relying<br /> on the current_state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix null pointer dereference in bnxt_bs_trace_check_wrap()<br /> <br /> With older FW, we may get the ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER<br /> for FW trace data type that has not been initialized. This will result<br /> in a crash in bnxt_bs_trace_type_wrap(). Add a guard to check for a<br /> valid magic_byte pointer before proceeding.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crash: fix crashkernel resource shrink<br /> <br /> When crashkernel is configured with a high reservation, shrinking its<br /> value below the low crashkernel reservation causes two issues:<br /> <br /> 1. Invalid crashkernel resource objects<br /> 2. Kernel crash if crashkernel shrinking is done twice<br /> <br /> For example, with crashkernel=200M,high, the kernel reserves 200MB of high<br /> memory and some default low memory (say 256MB). The reservation appears<br /> as:<br /> <br /> cat /proc/iomem | grep -i crash<br /> af000000-beffffff : Crash kernel<br /> 433000000-43f7fffff : Crash kernel<br /> <br /> If crashkernel is then shrunk to 50MB (echo 52428800 &gt;<br /> /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved:<br /> af000000-beffffff : Crash kernel<br /> <br /> Instead, it should show 50MB:<br /> af000000-b21fffff : Crash kernel<br /> <br /> Further shrinking crashkernel to 40MB causes a kernel crash with the<br /> following trace (x86):<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000038<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> <br /> Call Trace: <br /> ? __die_body.cold+0x19/0x27<br /> ? page_fault_oops+0x15a/0x2f0<br /> ? search_module_extables+0x19/0x60<br /> ? search_bpf_extables+0x5f/0x80<br /> ? exc_page_fault+0x7e/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? __release_resource+0xd/0xb0<br /> release_resource+0x26/0x40<br /> __crash_shrink_memory+0xe5/0x110<br /> crash_shrink_memory+0x12a/0x190<br /> kexec_crash_size_store+0x41/0x80<br /> kernfs_fop_write_iter+0x141/0x1f0<br /> vfs_write+0x294/0x460<br /> ksys_write+0x6d/0xf0<br /> <br /> <br /> This happens because __crash_shrink_memory()/kernel/crash_core.c<br /> incorrectly updates the crashk_res resource object even when<br /> crashk_low_res should be updated.<br /> <br /> Fix this by ensuring the correct crashkernel resource object is updated<br /> when shrinking crashkernel memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext<br /> <br /> When alloc_slab_obj_exts() fails and then later succeeds in allocating a<br /> slab extension vector, it calls handle_failed_objexts_alloc() to mark all<br /> objects in the vector as empty. As a result all objects in this slab<br /> (slabA) will have their extensions set to CODETAG_EMPTY.<br /> <br /> Later on if this slabA is used to allocate a slabobj_ext vector for<br /> another slab (slabB), we end up with the slabB-&gt;obj_exts pointing to a<br /> slabobj_ext vector that itself has a non-NULL slabobj_ext equal to<br /> CODETAG_EMPTY. When slabB gets freed, free_slab_obj_exts() is called to<br /> free slabB-&gt;obj_exts vector. <br /> <br /> free_slab_obj_exts() calls mark_objexts_empty(slabB-&gt;obj_exts) which will<br /> generate a warning because it expects slabobj_ext vectors to have a NULL<br /> obj_ext, not CODETAG_EMPTY.<br /> <br /> Modify mark_objexts_empty() to skip the warning and setting the obj_ext<br /> value if it&amp;#39;s already set to CODETAG_EMPTY.<br /> <br /> <br /> To quickly detect this WARN, I modified the code from<br /> WARN_ON(slab_exts[offs].ref.ct) to BUG_ON(slab_exts[offs].ref.ct == 1);<br /> <br /> We then obtained this message:<br /> <br /> [21630.898561] ------------[ cut here ]------------<br /> [21630.898596] kernel BUG at mm/slub.c:2050!<br /> [21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1 <br /> vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap <br /> vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace <br /> netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs <br /> blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel <br /> udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib <br /> nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct <br /> nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 <br /> nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink <br /> virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper <br /> drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi <br /> net_failover virtio_console failover virtio_mmio dm_mirror <br /> dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci <br /> virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 <br /> aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject]<br /> [21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump: <br /> loaded Tainted: G        W           6.18.0-rc1+ #74 PREEMPT(voluntary)<br /> [21630.910495] Tainted: [W]=WARN<br /> [21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown <br /> 2/2/2022<br /> [21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS <br /> BTYPE=--)<br /> [21630.912392] pc : __free_slab+0x228/0x250<br /> [21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp : <br /> ffff8000a02f73e0<br /> [21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27: <br /> ffff0000c0011c40<br /> [21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24: <br /> ffff000102199b40<br /> [21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21: <br /> ffff0000c0011c40<br /> [21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18: <br /> 0000000000000000<br /> [21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15: <br /> 0000000000000000<br /> [21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12: <br /> ffff70001405ee66<br /> [21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 : <br /> ffff800080a295dc<br /> [21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 : <br /> 0000000000003000<br /> [21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 : <br /> 0000000000000007<br /> [21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 : <br /> 0000000000000001<br /> [21630.921810] Call trace:<br /> [21630.922130]  __free_slab+0x228/0x250 (P)<br /> [21630.922669]  free_slab+0x38/0x118<br /> [21630.923079]  free_to_partial_list+0x1d4/0x340<br /> [21630.923591]  __slab_free+0x24c/0x348<br /> [21630.924024]  ___cache_free+0xf0/0x110<br /> [21630.924468]  qlist_free_all+0x78/0x130<br /> [21630.924922]  kasan_quarantine_reduce+0x11<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add bpf_prog_run_data_pointers()<br /> <br /> syzbot found that cls_bpf_classify() is able to change<br /> tc_skb_cb(skb)-&gt;drop_reason triggering a warning in sk_skb_reason_drop().<br /> <br /> WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]<br /> WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214<br /> <br /> struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched:<br /> Extend qdisc control block with tc control block"), which added a wrong<br /> interaction with db58ba459202 ("bpf: wire in data and data_end for<br /> cls_act_bpf").<br /> <br /> drop_reason was added later.<br /> <br /> Add bpf_prog_run_data_pointers() helper to save/restore the net_sched<br /> storage colliding with BPF data_meta/data_end.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: remove two invalid BUG_ON()s<br /> <br /> Those can be triggered trivially by userspace.