Export limit exceeded: 17240 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (17240 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-40273 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 6.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: NFSD: free copynotify stateid in nfs4_free_ol_stateid() Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period. However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd] This patch, instead, frees the associated copynotify stateid here. If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later. [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs | ||||
| CVE-2025-40272 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix use-after-free race in fault handler When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the folio is freed. | ||||
| CVE-2025-40277 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access. | ||||
| CVE-2025-40270 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: mm, swap: fix potential UAF issue for VMA readahead Since commit 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning"), the common helper for allocating and preparing a folio in the swap cache layer no longer tries to get a swap device reference internally, because all callers of __read_swap_cache_async are already holding a swap entry reference. The repeated swap device pinning isn't needed on the same swap device. Caller of VMA readahead is also holding a reference to the target entry's swap device, but VMA readahead walks the page table, so it might encounter swap entries from other devices, and call __read_swap_cache_async on another device without holding a reference to it. So it is possible to cause a UAF when swapoff of device A raced with swapin on device B, and VMA readahead tries to read swap entries from device A. It's not easy to trigger, but in theory, it could cause real issues. Make VMA readahead try to get the device reference first if the swap device is a different one from the target entry. | ||||
| CVE-2025-40316 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix device use-after-free on unbind A recent change fixed device reference leaks when looking up drm platform device driver data during bind() but failed to remove a partial fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix kobject put for component sub-drivers"). This results in a reference imbalance on component bind() failures and on unbind() which could lead to a user-after-free. Make sure to only drop the references after retrieving the driver data by effectively reverting the previous partial fix. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. | ||||
| CVE-2025-40324 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix crash in nfsd4_read_release() When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test. | ||||
| CVE-2025-40318 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and "UAF". Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently. | ||||
| CVE-2025-40317 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: regmap: slimbus: fix bus_context pointer in regmap init calls Commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()") revealed the problem in the slimbus regmap. That commit breaks audio playback, for instance, on sdm845 Thundercomm Dragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19c The __devm_regmap_init_slimbus() started to be used instead of __regmap_init_slimbus() after the commit mentioned above and turns out the incorrect bus_context pointer (3rd argument) was used in __devm_regmap_init_slimbus(). It should be just "slimbus" (which is equal to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or the first user of devm_regmap_init_slimbus() but we should fix it till the point where __devm_regmap_init_slimbus() was introduced therefore two "Fixes" tags. While at this, also correct the same argument in __regmap_init_slimbus(). | ||||
| CVE-2022-50623 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fpga: prevent integer overflow in dfl_feature_ioctl_set_irq() The "hdr.count * sizeof(s32)" multiplication can overflow on 32 bit systems leading to memory corruption. Use array_size() to fix that. | ||||
| CVE-2022-50615 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix reference count leak in snr_uncore_mmio_map() pci_get_device() will increase the reference count for the returned pci_dev, so snr_uncore_get_mc_dev() will return a pci_dev with its reference count increased. We need to call pci_dev_put() to decrease the reference count. Let's add the missing pci_dev_put(). | ||||
| CVE-2022-50617 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/powerplay/psm: Fix memory leak in power state init Commit 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in power state init") made the power state init function return early in case of failure to get an entry from the powerplay table, but it missed to clean up the allocated memory for the current power state before returning. | ||||
| CVE-2022-50618 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mmc: meson-gx: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, it will lead two issues: 1. The memory that allocated in mmc_alloc_host() is leaked. 2. In the remove() path, mmc_remove_host() will be called to delete device, but it's not added yet, it will lead a kernel crash because of null-ptr-deref in device_del(). Fix this by checking the return value and goto error path which will call mmc_free_host(). | ||||
| CVE-2022-50619 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix memory leak in kfd_mem_dmamap_userptr() If the number of pages from the userptr BO differs from the SG BO then the allocated memory for the SG table doesn't get freed before returning -EINVAL, which may lead to a memory leak in some error paths. Fix this by checking the number of pages before allocating memory for the SG table. | ||||
| CVE-2022-50620 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to invalidate dcc->f2fs_issue_discard in error path Syzbot reports a NULL pointer dereference issue as below: __refcount_add include/linux/refcount.h:193 [inline] __refcount_inc include/linux/refcount.h:250 [inline] refcount_inc include/linux/refcount.h:267 [inline] get_task_struct include/linux/sched/task.h:110 [inline] kthread_stop+0x34/0x1c0 kernel/kthread.c:703 f2fs_stop_discard_thread+0x3c/0x5c fs/f2fs/segment.c:1638 kill_f2fs_super+0x5c/0x194 fs/f2fs/super.c:4522 deactivate_locked_super+0x70/0xe8 fs/super.c:332 deactivate_super+0xd0/0xd4 fs/super.c:363 cleanup_mnt+0x1f8/0x234 fs/namespace.c:1186 __cleanup_mnt+0x20/0x30 fs/namespace.c:1193 task_work_run+0xc4/0x14c kernel/task_work.c:177 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x26c/0xbe0 kernel/exit.c:795 do_group_exit+0x60/0xe8 kernel/exit.c:925 __do_sys_exit_group kernel/exit.c:936 [inline] __se_sys_exit_group kernel/exit.c:934 [inline] __wake_up_parent+0x0/0x40 kernel/exit.c:934 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall arch/arm64/kernel/syscall.c:52 [inline] el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206 el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654 el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581 The root cause of this issue is in error path of f2fs_start_discard_thread(), it missed to invalidate dcc->f2fs_issue_discard, later kthread_stop() may access invalid pointer. | ||||
| CVE-2022-50614 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: misc: pci_endpoint_test: Fix pci_endpoint_test_{copy,write,read}() panic The dma_map_single() doesn't permit zero length mapping. It causes a follow panic. A panic was reported on arm64: [ 60.137988] ------------[ cut here ]------------ [ 60.142630] kernel BUG at kernel/dma/swiotlb.c:624! [ 60.147508] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l 2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl [ 60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237 [ 60.193387] Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT) [ 60.201302] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 60.208263] pc : swiotlb_tbl_map_single+0x2c0/0x590 [ 60.213149] lr : swiotlb_map+0x88/0x1f0 [ 60.216982] sp : ffff80000a883bc0 [ 60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000 [ 60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0 [ 60.234567] x23: 0000000000000002 x22: 0001000040000010 x21: 000000007a000000 [ 60.241703] x20: 0000000000200000 x19: 0000000000000000 x18: 0000000000000000 [ 60.248840] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0006ff7b9180 [ 60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000 [ 60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 60.270249] x8 : 0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000 [ 60.277385] x5 : ffff0004c0da2090 x4 : 0000000000000000 x3 : 0000000000000001 [ 60.284521] x2 : 0000000040000000 x1 : 0000000000000000 x0 : 0000000040000010 [ 60.291658] Call trace: [ 60.294100] swiotlb_tbl_map_single+0x2c0/0x590 [ 60.298629] swiotlb_map+0x88/0x1f0 [ 60.302115] dma_map_page_attrs+0x188/0x230 [ 60.306299] pci_endpoint_test_ioctl+0x5e4/0xd90 [pci_endpoint_test] [ 60.312660] __arm64_sys_ioctl+0xa8/0xf0 [ 60.316583] invoke_syscall+0x44/0x108 [ 60.320334] el0_svc_common.constprop.0+0xcc/0xf0 [ 60.325038] do_el0_svc+0x2c/0xb8 [ 60.328351] el0_svc+0x2c/0x88 [ 60.331406] el0t_64_sync_handler+0xb8/0xc0 [ 60.335587] el0t_64_sync+0x18c/0x190 [ 60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000) [ 60.345344] ---[ end trace 0000000000000000 ]--- To fix it, this patch adds a checking the payload length if it is zero. | ||||
| CVE-2022-50630 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: mm: hugetlb: fix UAF in hugetlb_handle_userfault The vma_lock and hugetlb_fault_mutex are dropped before handling userfault and reacquire them again after handle_userfault(), but reacquire the vma_lock could lead to UAF[1,2] due to the following race, hugetlb_fault hugetlb_no_page /*unlock vma_lock */ hugetlb_handle_userfault handle_userfault /* unlock mm->mmap_lock*/ vm_mmap_pgoff do_mmap mmap_region munmap_vma_range /* clean old vma */ /* lock vma_lock again <--- UAF */ /* unlock vma_lock */ Since the vma_lock will unlock immediately after hugetlb_handle_userfault(), let's drop the unneeded lock and unlock in hugetlb_handle_userfault() to fix the issue. [1] https://lore.kernel.org/linux-mm/000000000000d5e00a05e834962e@google.com/ [2] https://lore.kernel.org/linux-mm/20220921014457.1668-1-liuzixian4@huawei.com/ | ||||
| CVE-2022-50621 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: dm: verity-loadpin: Only trust verity targets with enforcement Verity targets can be configured to ignore corrupted data blocks. LoadPin must only trust verity targets that are configured to perform some kind of enforcement when data corruption is detected, like returning an error, restarting the system or triggering a panic. | ||||
| CVE-2022-50629 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: Fix memory leak in rsi_coex_attach() The coex_cb needs to be freed when rsi_create_kthread() failed in rsi_coex_attach(). | ||||
| CVE-2022-50628 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/gud: Fix UBSAN warning UBSAN complains about invalid value for bool: [ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1 [ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device [ 101.213426] usbcore: registered new interface driver gud [ 101.989431] ================================================================================ [ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9 [ 101.989447] load of value 121 is not a valid value for type '_Bool' [ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3 [ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018 [ 101.989459] Workqueue: events_long gud_flush_work [gud] [ 101.989471] Call Trace: [ 101.989474] <TASK> [ 101.989479] dump_stack_lvl+0x49/0x5f [ 101.989488] dump_stack+0x10/0x12 [ 101.989493] ubsan_epilogue+0x9/0x3b [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49 [ 101.989504] dma_buf_vmap.cold+0x38/0x3d [ 101.989511] ? find_busiest_group+0x48/0x300 [ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper] [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper] [ 101.989535] drm_gem_vmap+0x26/0x60 [drm] [ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper] [ 101.989630] gud_prep_flush+0xc1/0x710 [gud] [ 101.989639] ? _raw_spin_lock+0x17/0x40 [ 101.989648] gud_flush_work+0x1e0/0x430 [gud] [ 101.989653] ? __switch_to+0x11d/0x470 [ 101.989664] process_one_work+0x21f/0x3f0 [ 101.989673] worker_thread+0x200/0x3e0 [ 101.989679] ? rescuer_thread+0x390/0x390 [ 101.989684] kthread+0xfd/0x130 [ 101.989690] ? kthread_complete_and_exit+0x20/0x20 [ 101.989696] ret_from_fork+0x22/0x30 [ 101.989706] </TASK> [ 101.989708] ================================================================================ The source of this warning is in iosys_map_clear() called from dma_buf_vmap(). It conditionally sets values based on map->is_iomem. The iosys_map variables are allocated uninitialized on the stack leading to ->is_iomem having all kinds of values and not only 0/1. Fix this by zeroing the iosys_map variables. | ||||
| CVE-2022-50625 | 1 Linux | 1 Linux Kernel | 2025-12-08 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: avoid SBSA UART accessing DMACR register Chapter "B Generic UART" in "ARM Server Base System Architecture" [1] documentation describes a generic UART interface. Such generic UART does not support DMA. In current code, sbsa_uart_pops and amba_pl011_pops share the same stop_rx operation, which will invoke pl011_dma_rx_stop, leading to an access of the DMACR register. This commit adds a using_rx_dma check in pl011_dma_rx_stop to avoid the access to DMACR register for SBSA UARTs which does not support DMA. When the kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", Linux SBSA PL011 driver will access PL011 DMACR register in some functions. For most real SBSA Pl011 hardware implementations, the DMACR write behaviour will be ignored. So these DMACR operations will not cause obvious problems. But for some virtual SBSA PL011 hardware, like Xen virtual SBSA PL011 (vpl011) device, the behaviour might be different. Xen vpl011 emulation will inject a data abort to guest, when guest is accessing an unimplemented UART register. As Xen VPL011 is SBSA compatible, it will not implement DMACR register. So when Linux SBSA PL011 driver access DMACR register, it will get an unhandled data abort fault and the application will get a segmentation fault: Unhandled fault at 0xffffffc00944d048 Mem abort info: ESR = 0x96000000 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x00: ttbr address size fault Data abort info: ISV = 0, ISS = 0x00000000 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000 [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13 Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP ... Call trace: pl011_stop_rx+0x70/0x80 tty_port_shutdown+0x7c/0xb4 tty_port_close+0x60/0xcc uart_close+0x34/0x8c tty_release+0x144/0x4c0 __fput+0x78/0x220 ____fput+0x1c/0x30 task_work_run+0x88/0xc0 do_notify_resume+0x8d0/0x123c el0_svc+0xa8/0xc0 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 Code: b9000083 b901f001 794038a0 8b000042 (b9000041) ---[ end trace 83dd93df15c3216f ]--- note: bootlogd[132] exited with preempt_count 1 /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon This has been discussed in the Xen community, and we think it should fix this in Linux. See [2] for more information. [1] https://developer.arm.com/documentation/den0094/c/?lang=en [2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg00543.html | ||||