Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Use spin_lock_irqsave() in interruptible context<br /> <br /> spin_lock/unlock() functions used in interrupt contexts could<br /> result in a deadlock, as seen in GitLab issue #13399,<br /> which occurs when interrupt comes in while holding a lock.<br /> <br /> Try to remedy the problem by saving irq state before spin lock<br /> acquisition.<br /> <br /> v2: add irqs&amp;#39; state save/restore calls to all locks/unlocks in<br /> signal_irq_work() execution (Maciej)<br /> <br /> v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead<br /> of other lock/unlock calls and add Fixes and Cc tags (Tvrtko);<br /> change title and commit message<br /> <br /> (cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: Fix crash when a namespace is disabled<br /> <br /> The namespace percpu counter protects pending I/O, and we can<br /> only safely diable the namespace once the counter drop to zero.<br /> Otherwise we end up with a crash when running blktests/nvme/058<br /> (eg for loop transport):<br /> <br /> [ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI<br /> [ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> [ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232<br /> [ 2352.930438] [ T53909] Tainted: [W]=WARN<br /> [ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014<br /> [ 2352.930443] [ T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]<br /> [ 2352.930449] [ T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180<br /> <br /> as the queue is already torn down when calling submit_bio();<br /> <br /> So we need to init the percpu counter in nvmet_ns_enable(), and<br /> wait for it to drop to zero in nvmet_ns_disable() to avoid having<br /> I/O pending after the namespace has been disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix softlockup in arena_map_free on 64k page kernel<br /> <br /> On an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y,<br /> arena_htab tests cause a segmentation fault and soft lockup.<br /> The same failure is not observed with 4k pages on aarch64.<br /> <br /> It turns out arena_map_free() is calling<br /> apply_to_existing_page_range() with the address returned by<br /> bpf_arena_get_kern_vm_start(). If this address is not page-aligned<br /> the code ends up calling apply_to_pte_range() with that unaligned<br /> address causing soft lockup.<br /> <br /> Fix it by round up GUARD_SZ to PAGE_SIZE

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Add rx_skb of kfree_skb to raw_tp_null_args[].<br /> <br /> Yan Zhai reported a BPF prog could trigger a null-ptr-deref [0]<br /> in trace_kfree_skb if the prog does not check if rx_sk is NULL.<br /> <br /> Commit c53795d48ee8 ("net: add rx_sk to trace_kfree_skb") added<br /> rx_sk to trace_kfree_skb, but rx_sk is optional and could be NULL.<br /> <br /> Let&amp;#39;s add kfree_skb to raw_tp_null_args[] to let the BPF verifier<br /> validate such a prog and prevent the issue.<br /> <br /> Now we fail to load such a prog:<br /> <br /> libbpf: prog &amp;#39;drop&amp;#39;: -- BEGIN PROG LOAD LOG --<br /> 0: R1=ctx() R10=fp0<br /> ; int BPF_PROG(drop, struct sk_buff *skb, void *location, @ kfree_skb_sk_null.bpf.c:21<br /> 0: (79) r3 = *(u64 *)(r1 +24)<br /> func &amp;#39;kfree_skb&amp;#39; arg3 has btf_id 5253 type STRUCT &amp;#39;sock&amp;#39;<br /> 1: R1=ctx() R3_w=trusted_ptr_or_null_sock(id=1)<br /> ; bpf_printk("sk: %d, %d\n", sk, sk-&gt;__sk_common.skc_family); @ kfree_skb_sk_null.bpf.c:24<br /> 1: (69) r4 = *(u16 *)(r3 +16)<br /> R3 invalid mem access &amp;#39;trusted_ptr_or_null_&amp;#39;<br /> processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0<br /> -- END PROG LOAD LOG --<br /> <br /> Note this fix requires commit 838a10bd2ebf ("bpf: Augment raw_tp<br /> arguments with PTR_MAYBE_NULL").<br /> <br /> [0]:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> PREEMPT SMP<br /> RIP: 0010:bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x60<br /> ? page_fault_oops+0x148/0x420<br /> ? search_bpf_extables+0x5b/0x70<br /> ? fixup_exception+0x27/0x2c0<br /> ? exc_page_fault+0x75/0x170<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d<br /> bpf_trace_run4+0x68/0xd0<br /> ? unix_stream_connect+0x1f4/0x6f0<br /> sk_skb_reason_drop+0x90/0x120<br /> unix_stream_connect+0x1f4/0x6f0<br /> __sys_connect+0x7f/0xb0<br /> __x64_sys_connect+0x14/0x20<br /> do_syscall_64+0x47/0xc30<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()<br /> <br /> Add check for the return value of nfp_app_ctrl_msg_alloc() in<br /> nfp_bpf_cmsg_alloc() to prevent null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix deadlock when freeing cgroup storage<br /> <br /> The following commit<br /> bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]")<br /> first introduced deadlock prevention for fentry/fexit programs attaching<br /> on bpf_task_storage helpers. That commit also employed the logic in map<br /> free path in its v6 version.<br /> <br /> Later bpf_cgrp_storage was first introduced in<br /> c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs")<br /> which faces the same issue as bpf_task_storage, instead of its busy<br /> counter, NULL was passed to bpf_local_storage_map_free() which opened<br /> a window to cause deadlock:<br /> <br /> <br /> (acquiring local_storage-&gt;lock)<br /> _raw_spin_lock_irqsave+0x3d/0x50<br /> bpf_local_storage_update+0xd1/0x460<br /> bpf_cgrp_storage_get+0x109/0x130<br /> bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170<br /> ? __bpf_prog_enter_recur+0x16/0x80<br /> bpf_trampoline_6442485186+0x43/0xa4<br /> cgroup_storage_ptr+0x9/0x20<br /> (holding local_storage-&gt;lock)<br /> bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160<br /> bpf_selem_unlink_storage+0x6f/0x110<br /> bpf_local_storage_map_free+0xa2/0x110<br /> bpf_map_free_deferred+0x5b/0x90<br /> process_one_work+0x17c/0x390<br /> worker_thread+0x251/0x360<br /> kthread+0xd2/0x100<br /> ret_from_fork+0x34/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Progs:<br /> - A: SEC("fentry/cgroup_storage_ptr")<br /> - cgid (BPF_MAP_TYPE_HASH)<br /> Record the id of the cgroup the current task belonging<br /> to in this hash map, using the address of the cgroup<br /> as the map key.<br /> - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE)<br /> If current task is a kworker, lookup the above hash<br /> map using function parameter @owner as the key to get<br /> its corresponding cgroup id which is then used to get<br /> a trusted pointer to the cgroup through<br /> bpf_cgroup_from_id(). This trusted pointer can then<br /> be passed to bpf_cgrp_storage_get() to finally trigger<br /> the deadlock issue.<br /> - B: SEC("tp_btf/sys_enter")<br /> - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE)<br /> The only purpose of this prog is to fill Prog A&amp;#39;s<br /> hash map by calling bpf_cgrp_storage_get() for as<br /> many userspace tasks as possible.<br /> <br /> Steps to reproduce:<br /> - Run A;<br /> - while (true) { Run B; Destroy B; }<br /> <br /> Fix this issue by passing its busy counter to the free procedure so<br /> it can be properly incremented before storage/smap locking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix double accounting race when btrfs_run_delalloc_range() failed<br /> <br /> [BUG]<br /> When running btrfs with block size (4K) smaller than page size (64K,<br /> aarch64), there is a very high chance to crash the kernel at<br /> generic/750, with the following messages:<br /> (before the call traces, there are 3 extra debug messages added)<br /> <br /> BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental<br /> BTRFS info (device dm-3): checking UUID tree<br /> hrtimer: interrupt took 5451385 ns<br /> BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28<br /> BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28<br /> BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs]<br /> CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022<br /> Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]<br /> pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs]<br /> lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs]<br /> Call trace:<br /> can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P)<br /> can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L)<br /> btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs]<br /> extent_writepage+0x10c/0x3b8 [btrfs]<br /> extent_write_cache_pages+0x21c/0x4e8 [btrfs]<br /> btrfs_writepages+0x94/0x160 [btrfs]<br /> do_writepages+0x74/0x190<br /> filemap_fdatawrite_wbc+0x74/0xa0<br /> start_delalloc_inodes+0x17c/0x3b0 [btrfs]<br /> btrfs_start_delalloc_roots+0x17c/0x288 [btrfs]<br /> shrink_delalloc+0x11c/0x280 [btrfs]<br /> flush_space+0x288/0x328 [btrfs]<br /> btrfs_async_reclaim_data_space+0x180/0x228 [btrfs]<br /> process_one_work+0x228/0x680<br /> worker_thread+0x1bc/0x360<br /> kthread+0x100/0x118<br /> ret_from_fork+0x10/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0<br /> BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0<br /> CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89<br /> Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022<br /> Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write)<br /> pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : process_one_work+0x110/0x680<br /> lr : worker_thread+0x1bc/0x360<br /> Call trace:<br /> process_one_work+0x110/0x680 (P)<br /> worker_thread+0x1bc/0x360 (L)<br /> worker_thread+0x1bc/0x360<br /> kthread+0x100/0x118<br /> ret_from_fork+0x10/0x20<br /> Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception<br /> SMP: stopping secondary CPUs<br /> SMP: failed to stop secondary CPUs 2-3<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> Kernel Offset: 0x275bb9540000 from 0xffff800080000000<br /> PHYS_OFFSET: 0xffff8fbba0000000<br /> CPU features: 0x100,00000070,00801250,8201720b<br /> <br /> [CAUSE]<br /> The above warning is triggered immediately after the delalloc range<br /> failure, this happens in the following sequence:<br /> <br /> - Range [1568K, 1636K) is dirty<br /> <br /> 1536K 1568K 1600K 1636K 1664K<br /> | |/////////|////////| |<br /> <br /> Where 1536K, 1600K and 1664K are page boundaries (64K page size)<br /> <br /> - Enter extent_writepage() for page 1536K<br /> <br /> - Enter run_delalloc_nocow() with locke<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: spi-nor: sst: Fix SST write failure<br /> <br /> &amp;#39;commit 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation<br /> to `sst_nor_write_data()`")&amp;#39; introduced a bug where only one byte of data<br /> is written, regardless of the number of bytes passed to<br /> sst_nor_write_data(), causing a kernel crash during the write operation.<br /> Ensure the correct number of bytes are written as passed to<br /> sst_nor_write_data().<br /> <br /> Call trace:<br /> [ 57.400180] ------------[ cut here ]------------<br /> [ 57.404842] While writing 2 byte written 1 bytes<br /> [ 57.409493] WARNING: CPU: 0 PID: 737 at drivers/mtd/spi-nor/sst.c:187 sst_nor_write_data+0x6c/0x74<br /> [ 57.418464] Modules linked in:<br /> [ 57.421517] CPU: 0 UID: 0 PID: 737 Comm: mtd_debug Not tainted 6.12.0-g5ad04afd91f9 #30<br /> [ 57.429517] Hardware name: Xilinx Versal A2197 Processor board revA - x-prc-02 revA (DT)<br /> [ 57.437600] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 57.444557] pc : sst_nor_write_data+0x6c/0x74<br /> [ 57.448911] lr : sst_nor_write_data+0x6c/0x74<br /> [ 57.453264] sp : ffff80008232bb40<br /> [ 57.456570] x29: ffff80008232bb40 x28: 0000000000010000 x27: 0000000000000001<br /> [ 57.463708] x26: 000000000000ffff x25: 0000000000000000 x24: 0000000000000000<br /> [ 57.470843] x23: 0000000000010000 x22: ffff80008232bbf0 x21: ffff000816230000<br /> [ 57.477978] x20: ffff0008056c0080 x19: 0000000000000002 x18: 0000000000000006<br /> [ 57.485112] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008232b580<br /> [ 57.492246] x14: 0000000000000000 x13: ffff8000816d1530 x12: 00000000000004a4<br /> [ 57.499380] x11: 000000000000018c x10: ffff8000816fd530 x9 : ffff8000816d1530<br /> [ 57.506515] x8 : 00000000fffff7ff x7 : ffff8000816fd530 x6 : 0000000000000001<br /> [ 57.513649] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 57.520782] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008049b0000<br /> [ 57.527916] Call trace:<br /> [ 57.530354] sst_nor_write_data+0x6c/0x74<br /> [ 57.534361] sst_nor_write+0xb4/0x18c<br /> [ 57.538019] mtd_write_oob_std+0x7c/0x88<br /> [ 57.541941] mtd_write_oob+0x70/0xbc<br /> [ 57.545511] mtd_write+0x68/0xa8<br /> [ 57.548733] mtdchar_write+0x10c/0x290<br /> [ 57.552477] vfs_write+0xb4/0x3a8<br /> [ 57.555791] ksys_write+0x74/0x10c<br /> [ 57.559189] __arm64_sys_write+0x1c/0x28<br /> [ 57.563109] invoke_syscall+0x54/0x11c<br /> [ 57.566856] el0_svc_common.constprop.0+0xc0/0xe0<br /> [ 57.571557] do_el0_svc+0x1c/0x28<br /> [ 57.574868] el0_svc+0x30/0xcc<br /> [ 57.577921] el0t_64_sync_handler+0x120/0x12c<br /> [ 57.582276] el0t_64_sync+0x190/0x194<br /> [ 57.585933] ---[ end trace 0000000000000000 ]---<br /> <br /> [pratyush@kernel.org: add Cc stable tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Add check for next_buffer in receive_encrypted_standard()<br /> <br /> Add check for the return value of cifs_buf_get() and cifs_small_buf_get()<br /> in receive_encrypted_standard() to prevent null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> acct: perform last write from workqueue<br /> <br /> In [1] it was reported that the acct(2) system call can be used to<br /> trigger NULL deref in cases where it is set to write to a file that<br /> triggers an internal lookup. This can e.g., happen when pointing acc(2)<br /> to /sys/power/resume. At the point the where the write to this file<br /> happens the calling task has already exited and called exit_fs(). A<br /> lookup will thus trigger a NULL-deref when accessing current-&gt;fs.<br /> <br /> Reorganize the code so that the the final write happens from the<br /> workqueue but with the caller&amp;#39;s credentials. This preserves the<br /> (strange) permission model and has almost no regression risk.<br /> <br /> This api should stop to exist though.

The Workreap plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 3.2.5. This is due to the plugin not properly validating a user&amp;#39;s identity prior to (1) performing a social auto-login or (2) updating their profile details (e.g. password). This makes it possible for unauthenticated attackers to (1) login as an arbitrary user if their email address is known or (2) change an arbitrary user&amp;#39;s password, including administrators, and leverage that to gain access to their account. NOTE: This vulnerability was partially fixed in version 3.2.5.

The Page Builder: Pagelayer – Drag and Drop website builder plugin for WordPress is vulnerable to Information Exposure in all versions up to, and including, 1.9.8 via the &amp;#39;pagelayer_builder_posts_shortcode&amp;#39; function due to insufficient restrictions on which posts can be included. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract data from private posts that they should not have access to.