Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()<br /> <br /> Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding<br /> the per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock<br /> (through crypto_exit_scomp_ops_async()).<br /> <br /> On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through<br /> crypto_scomp_init_tfm()), and then allocates memory. If the allocation<br /> results in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.<br /> <br /> The above dependencies can cause an ABBA deadlock. For example in the<br /> following scenario:<br /> <br /> (1) Task A running on CPU #1:<br /> crypto_alloc_acomp_node()<br /> Holds scomp_lock<br /> Enters reclaim<br /> Reads per_cpu_ptr(pool-&gt;acomp_ctx, 1)<br /> <br /> (2) Task A is descheduled<br /> <br /> (3) CPU #1 goes offline<br /> zswap_cpu_comp_dead(CPU #1)<br /> Holds per_cpu_ptr(pool-&gt;acomp_ctx, 1))<br /> Calls crypto_free_acomp()<br /> Waits for scomp_lock<br /> <br /> (4) Task A running on CPU #2:<br /> Waits for per_cpu_ptr(pool-&gt;acomp_ctx, 1) // Read on CPU #1<br /> DEADLOCK<br /> <br /> Since there is no requirement to call crypto_free_acomp() with the per-CPU<br /> acomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is<br /> unlocked. Also move the acomp_request_free() and kfree() calls for<br /> consistency and to avoid any potential sublte locking dependencies in the<br /> future.<br /> <br /> With this, only setting acomp_ctx fields to NULL occurs with the mutex<br /> held. This is similar to how zswap_cpu_comp_prepare() only initializes<br /> acomp_ctx fields with the mutex held, after performing all allocations<br /> before holding the mutex.<br /> <br /> Opportunistically, move the NULL check on acomp_ctx so that it takes place<br /> before the mutex dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix management of listener transports<br /> <br /> Currently, when no active threads are running, a root user using nfsdctl<br /> command can try to remove a particular listener from the list of previously<br /> added ones, then start the server by increasing the number of threads,<br /> it leads to the following problem:<br /> <br /> [ 158.835354] refcount_t: addition on 0; use-after-free.<br /> [ 158.835603] WARNING: CPU: 2 PID: 9145 at lib/refcount.c:25 refcount_warn_saturate+0x160/0x1a0<br /> [ 158.836017] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd auth_rpcgss nfs_acl lockd grace overlay isofs uinput snd_seq_dummy snd_hrtimer 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 rfkill ip_set nf_tables qrtr sunrpc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common snd_hda_codec_generic mc e1000e snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore sg loop dm_multipath dm_mod nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs libcrc32c crct10dif_ce ghash_ce vmwgfx sha2_ce sha256_arm64 sr_mod sha1_ce cdrom nvme drm_client_lib drm_ttm_helper ttm nvme_core drm_kms_helper nvme_auth drm fuse<br /> [ 158.840093] CPU: 2 UID: 0 PID: 9145 Comm: nfsd Kdump: loaded Tainted: G B W 6.13.0-rc6+ #7<br /> [ 158.840624] Tainted: [B]=BAD_PAGE, [W]=WARN<br /> [ 158.840802] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024<br /> [ 158.841220] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 158.841563] pc : refcount_warn_saturate+0x160/0x1a0<br /> [ 158.841780] lr : refcount_warn_saturate+0x160/0x1a0<br /> [ 158.842000] sp : ffff800089be7d80<br /> [ 158.842147] x29: ffff800089be7d80 x28: ffff00008e68c148 x27: ffff00008e68c148<br /> [ 158.842492] x26: ffff0002e3b5c000 x25: ffff600011cd1829 x24: ffff00008653c010<br /> [ 158.842832] x23: ffff00008653c000 x22: 1fffe00011cd1829 x21: ffff00008653c028<br /> [ 158.843175] x20: 0000000000000002 x19: ffff00008653c010 x18: 0000000000000000<br /> [ 158.843505] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 158.843836] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600050a26493<br /> [ 158.844143] x11: 1fffe00050a26492 x10: ffff600050a26492 x9 : dfff800000000000<br /> [ 158.844475] x8 : 00009fffaf5d9b6e x7 : ffff000285132493 x6 : 0000000000000001<br /> [ 158.844823] x5 : ffff000285132490 x4 : ffff600050a26493 x3 : ffff8000805e72bc<br /> [ 158.845174] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000098588000<br /> [ 158.845528] Call trace:<br /> [ 158.845658] refcount_warn_saturate+0x160/0x1a0 (P)<br /> [ 158.845894] svc_recv+0x58c/0x680 [sunrpc]<br /> [ 158.846183] nfsd+0x1fc/0x348 [nfsd]<br /> [ 158.846390] kthread+0x274/0x2f8<br /> [ 158.846546] ret_from_fork+0x10/0x20<br /> [ 158.846714] ---[ end trace 0000000000000000 ]---<br /> <br /> nfsd_nl_listener_set_doit() would manipulate the list of transports of<br /> server&amp;#39;s sv_permsocks and close the specified listener but the other<br /> list of transports (server&amp;#39;s sp_xprts list) would not be changed leading<br /> to the problem above.<br /> <br /> Instead, determined if the nfsdctl is trying to remove a listener, in<br /> which case, delete all the existing listener transports and re-create<br /> all-but-the-removed ones.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/bwctrl: Fix NULL pointer dereference on bus number exhaustion<br /> <br /> When BIOS neglects to assign bus numbers to PCI bridges, the kernel<br /> attempts to correct that during PCI device enumeration. If it runs out<br /> of bus numbers, no pci_bus is allocated and the "subordinate" pointer in<br /> the bridge&amp;#39;s pci_dev remains NULL.<br /> <br /> The PCIe bandwidth controller erroneously does not check for a NULL<br /> subordinate pointer and dereferences it on probe.<br /> <br /> Bandwidth control of unusable devices below the bridge is of questionable<br /> utility, so simply error out instead. This mirrors what PCIe hotplug does<br /> since commit 62e4492c3063 ("PCI: Prevent NULL dereference during pciehp<br /> probe").<br /> <br /> The PCI core emits a message with KERN_INFO severity if it has run out of<br /> bus numbers. PCIe hotplug emits an additional message with KERN_ERR<br /> severity to inform the user that hotplug functionality is disabled at the<br /> bridge. A similar message for bandwidth control does not seem merited,<br /> given that its only purpose so far is to expose an up-to-date link speed<br /> in sysfs and throttle the link speed on certain laptops with limited<br /> Thermal Design Power. So error out silently.<br /> <br /> User-visible messages:<br /> <br /> pci 0000:16:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring<br /> [...]<br /> pci_bus 0000:45: busn_res: [bus 45-74] end is updated to 74<br /> pci 0000:16:02.0: devices behind bridge are unusable because [bus 45-74] cannot be assigned for them<br /> [...]<br /> pcieport 0000:16:02.0: pciehp: Hotplug bridge without secondary bus, ignoring<br /> [...]<br /> BUG: kernel NULL pointer dereference<br /> RIP: pcie_update_link_speed<br /> pcie_bwnotif_enable<br /> pcie_bwnotif_probe<br /> pcie_port_probe_service<br /> really_probe

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