Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix kernel panic due to null pointer dereference<br /> <br /> Address a kernel panic caused by a null pointer dereference in the<br /> `mt792x_rx_get_wcid` function. The issue arises because the `deflink` structure<br /> is not properly initialized with the `sta` context. This patch ensures that the<br /> `deflink` structure is correctly linked to the `sta` context, preventing the<br /> null pointer dereference.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000400<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 UID: 0 PID: 470 Comm: mt76-usb-rx phy Not tainted 6.12.13-gentoo-dist #1<br /> Hardware name: /AMD HUDSON-M1, BIOS 4.6.4 11/15/2011<br /> RIP: 0010:mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib]<br /> RSP: 0018:ffffa147c055fd98 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: ffff8e9ecb652000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e9ecb652000<br /> RBP: 0000000000000685 R08: ffff8e9ec6570000 R09: 0000000000000000<br /> R10: ffff8e9ecd2ca000 R11: ffff8e9f22a217c0 R12: 0000000038010119<br /> R13: 0000000080843801 R14: ffff8e9ec6570000 R15: ffff8e9ecb652000<br /> FS: 0000000000000000(0000) GS:ffff8e9f22a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000400 CR3: 000000000d2ea000 CR4: 00000000000006f0<br /> Call Trace:<br /> <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 /> ? mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib]<br /> mt7921_queue_rx_skb+0x1c6/0xaa0 [mt7921_common]<br /> mt76u_alloc_queues+0x784/0x810 [mt76_usb]<br /> ? __pfx___mt76_worker_fn+0x10/0x10 [mt76]<br /> __mt76_worker_fn+0x4f/0x80 [mt76]<br /> kthread+0xd2/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: put dl_stid if fail to queue dl_recall<br /> <br /> Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we<br /> increment the reference count of dl_stid.<br /> We expect that after the corresponding work_struct is processed, the<br /> reference count of dl_stid will be decremented through the callback<br /> function nfsd4_cb_recall_release.<br /> However, if the call to nfsd4_run_cb fails, the incremented reference<br /> count of dl_stid will not be decremented correspondingly, leading to the<br /> following nfs4_stid leak:<br /> unreferenced object 0xffff88812067b578 (size 344):<br /> comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........<br /> 00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N..<br /> backtrace:<br /> kmem_cache_alloc+0x4b9/0x700<br /> nfsd4_process_open1+0x34/0x300<br /> nfsd4_open+0x2d1/0x9d0<br /> nfsd4_proc_compound+0x7a2/0xe30<br /> nfsd_dispatch+0x241/0x3e0<br /> svc_process_common+0x5d3/0xcc0<br /> svc_process+0x2a3/0x320<br /> nfsd+0x180/0x2e0<br /> kthread+0x199/0x1d0<br /> ret_from_fork+0x30/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> unreferenced object 0xffff8881499f4d28 (size 368):<br /> comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I....<br /> 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... .......<br /> backtrace:<br /> kmem_cache_alloc+0x4b9/0x700<br /> nfs4_alloc_stid+0x29/0x210<br /> alloc_init_deleg+0x92/0x2e0<br /> nfs4_set_delegation+0x284/0xc00<br /> nfs4_open_delegation+0x216/0x3f0<br /> nfsd4_process_open2+0x2b3/0xee0<br /> nfsd4_open+0x770/0x9d0<br /> nfsd4_proc_compound+0x7a2/0xe30<br /> nfsd_dispatch+0x241/0x3e0<br /> svc_process_common+0x5d3/0xcc0<br /> svc_process+0x2a3/0x320<br /> nfsd+0x180/0x2e0<br /> kthread+0x199/0x1d0<br /> ret_from_fork+0x30/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if<br /> fail to queue dl_recall.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: streamzap: fix race between device disconnection and urb callback<br /> <br /> Syzkaller has reported a general protection fault at function<br /> ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer<br /> dereference of dev-&gt;raw pointer, even though it is checked for NULL in<br /> the same function, which means there is a race condition. It occurs due<br /> to the incorrect order of actions in the streamzap_disconnect() function:<br /> rc_unregister_device() is called before usb_kill_urb(). The dev-&gt;raw<br /> pointer is freed and set to NULL in rc_unregister_device(), and only<br /> after that usb_kill_urb() waits for in-progress requests to finish.<br /> <br /> If rc_unregister_device() is called while streamzap_callback() handler is<br /> not finished, this can lead to accessing freed resources. Thus<br /> rc_unregister_device() should be called after usb_kill_urb().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: Don&amp;#39;t call NULL in do_compat_alignment_fixup()<br /> <br /> do_alignment_t32_to_handler() only fixes up alignment faults for<br /> specific instructions; it returns NULL otherwise (e.g. LDREX). When<br /> that&amp;#39;s the case, signal to the caller that it needs to proceed with the<br /> regular alignment fault handling (i.e. SIGBUS). Without this patch, the<br /> kernel panics:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Mem abort info:<br /> ESR = 0x0000000086000006<br /> EC = 0x21: IABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000<br /> [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000<br /> Internal error: Oops: 0000000086000006 [#1] SMP<br /> Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa&gt;<br /> libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c&gt;<br /> CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1<br /> Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : 0x0<br /> lr : do_compat_alignment_fixup+0xd8/0x3dc<br /> sp : ffff80000f973dd0<br /> x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001<br /> x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000<br /> x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001<br /> Call trace:<br /> 0x0<br /> do_alignment_fault+0x40/0x50<br /> do_mem_abort+0x4c/0xa0<br /> el0_da+0x48/0xf0<br /> el0t_32_sync_handler+0x110/0x140<br /> el0t_32_sync+0x190/0x194<br /> Code: bad PC value<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: don&amp;#39;t ignore the return code of svc_proc_register()<br /> <br /> Currently, nfsd_proc_stat_init() ignores the return value of<br /> svc_proc_register(). If the procfile creation fails, then the kernel<br /> will WARN when it tries to remove the entry later.<br /> <br /> Fix nfsd_proc_stat_init() to return the same type of pointer as<br /> svc_proc_register(), and fix up nfsd_net_init() to check that and fail<br /> the nfsd_net construction if it occurs.<br /> <br /> svc_proc_register() can fail if the dentry can&amp;#39;t be allocated, or if an<br /> identical dentry already exists. The second case is pretty unlikely in<br /> the nfsd_net construction codepath, so if this happens, return -ENOMEM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/ASPM: Fix link state exit during switch upstream function removal<br /> <br /> Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to<br /> avoid use-after-free"), we would free the ASPM link only after the last<br /> function on the bus pertaining to the given link was removed.<br /> <br /> That was too late. If function 0 is removed before sibling function,<br /> link-&gt;downstream would point to free&amp;#39;d memory after.<br /> <br /> After above change, we freed the ASPM parent link state upon any function<br /> removal on the bus pertaining to a given link.<br /> <br /> That is too early. If the link is to a PCIe switch with MFD on the upstream<br /> port, then removing functions other than 0 first would free a link which<br /> still remains parent_link to the remaining downstream ports.<br /> <br /> The resulting GPFs are especially frequent during hot-unplug, because<br /> pciehp removes devices on the link bus in reverse order.<br /> <br /> On that switch, function 0 is the virtual P2P bridge to the internal bus.<br /> Free exactly when function 0 is removed -- before the parent link is<br /> obsolete, but after all subordinate links are gone.<br /> <br /> [kwilczynski: commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: add check read-only before truncation in jfs_truncate_nolock()<br /> <br /> Added a check for "read-only" mode in the `jfs_truncate_nolock`<br /> function to avoid errors related to writing to a read-only<br /> filesystem.<br /> <br /> Call stack:<br /> <br /> block_write_begin() {<br /> jfs_write_failed() {<br /> jfs_truncate() {<br /> jfs_truncate_nolock() {<br /> txEnd() {<br /> ...<br /> log = JFS_SBI(tblk-&gt;sb)-&gt;log;<br /> // (log == NULL)<br /> <br /> If the `isReadOnly(ip)` condition is triggered in<br /> `jfs_truncate_nolock`, the function execution will stop, and no<br /> further data modification will occur. Instead, the `xtTruncate`<br /> function will be called with the "COMMIT_WMAP" flag, preventing<br /> modifications in "read-only" mode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: add check read-only before txBeginAnon() call<br /> <br /> Added a read-only check before calling `txBeginAnon` in `extAlloc`<br /> and `extRecord`. This prevents modification attempts on a read-only<br /> mounted filesystem, avoiding potential errors or crashes.<br /> <br /> Call trace:<br /> txBeginAnon+0xac/0x154<br /> extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78<br /> jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248<br /> __block_write_begin_int+0x580/0x166c fs/buffer.c:2128<br /> __block_write_begin fs/buffer.c:2177 [inline]<br /> block_write_begin+0x98/0x11c fs/buffer.c:2236<br /> jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix RCU stall while reaping monitor destination ring<br /> <br /> While processing the monitor destination ring, MSDUs are reaped from the<br /> link descriptor based on the corresponding buf_id.<br /> <br /> However, sometimes the driver cannot obtain a valid buffer corresponding<br /> to the buf_id received from the hardware. This causes an infinite loop<br /> in the destination processing, resulting in a kernel crash.<br /> <br /> kernel log:<br /> ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309<br /> ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed<br /> ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309<br /> ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed<br /> <br /> Fix this by skipping the problematic buf_id and reaping the next entry,<br /> replacing the break with the next MSDU processing.<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30<br /> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: add srng-&gt;lock for ath11k_hal_srng_* in monitor mode<br /> <br /> ath11k_hal_srng_* should be used with srng-&gt;lock to protect srng data.<br /> <br /> For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),<br /> they use ath11k_hal_srng_* for many times but never call srng-&gt;lock.<br /> <br /> So when running (full) monitor mode, warning will occur:<br /> RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]<br /> Call Trace:<br /> ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]<br /> ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]<br /> ? idr_alloc_u32+0x97/0xd0<br /> ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]<br /> ath11k_dp_service_srng+0x289/0x5a0 [ath11k]<br /> ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]<br /> __napi_poll+0x30/0x1f0<br /> net_rx_action+0x198/0x320<br /> __do_softirq+0xdd/0x319<br /> <br /> So add srng-&gt;lock for them to avoid such warnings.<br /> <br /> Inorder to fetch the srng-&gt;lock, should change srng&amp;#39;s definition from<br /> &amp;#39;void&amp;#39; to &amp;#39;struct hal_srng&amp;#39;. And initialize them elsewhere to prevent<br /> one line of code from being too long. This is consistent with other ring<br /> process functions, such as ath11k_dp_process_rx().<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30<br /> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans<br /> <br /> There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and<br /> size. This would make xlate_pos negative.<br /> <br /> [ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000<br /> [ 23.734158] ================================================================================<br /> [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7<br /> [ 23.734418] shift exponent -1 is negative<br /> <br /> Ensuring xlate_pos is a positive or zero before BIT.

A vulnerability was found in SourceCodester Online Eyewear Shop 1.0. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the file /oews/classes/Master.php?f=save_product. The manipulation leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.