Total
5035 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-50353 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mmc: wmt-sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, clk_disable_unprepare() also needs be called. | ||||
| CVE-2022-50347 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, besides, led_classdev_unregister() and pm_runtime_disable() also need be called. | ||||
| CVE-2022-50344 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix null-ptr-deref in ext4_write_info I caught a null-ptr-deref bug as follows: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339 RIP: 0010:ext4_write_info+0x53/0x1b0 [...] Call Trace: dquot_writeback_dquots+0x341/0x9a0 ext4_sync_fs+0x19e/0x800 __sync_filesystem+0x83/0x100 sync_filesystem+0x89/0xf0 generic_shutdown_super+0x79/0x3e0 kill_block_super+0xa1/0x110 deactivate_locked_super+0xac/0x130 deactivate_super+0xb6/0xd0 cleanup_mnt+0x289/0x400 __cleanup_mnt+0x16/0x20 task_work_run+0x11c/0x1c0 exit_to_user_mode_prepare+0x203/0x210 syscall_exit_to_user_mode+0x5b/0x3a0 do_syscall_64+0x59/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ================================================================== Above issue may happen as follows: ------------------------------------- exit_to_user_mode_prepare task_work_run __cleanup_mnt cleanup_mnt deactivate_super deactivate_locked_super kill_block_super generic_shutdown_super shrink_dcache_for_umount dentry = sb->s_root sb->s_root = NULL <--- Here set NULL sync_filesystem __sync_filesystem sb->s_op->sync_fs > ext4_sync_fs dquot_writeback_dquots sb->dq_op->write_info > ext4_write_info ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2) d_inode(sb->s_root) s_root->d_inode <--- Null pointer dereference To solve this problem, we use ext4_journal_start_sb directly to avoid s_root being used. | ||||
| CVE-2026-21300 | 1 Adobe | 1 Substance 3d Modeler | 2026-01-14 | 5.5 Medium |
| Substance3D - Modeler versions 1.22.4 and earlier are affected by a NULL Pointer Dereference vulnerability that could lead to application denial-of-service. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-21485 | 2 Color, Internationalcolorconsortium | 2 Iccdev, Iccdev | 2026-01-14 | 8.8 High |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Versions 2.3.1.1 and below are prone to have Undefined Behavior (UB) and Out of Memory errors. This issue is fixed in version 2.3.1.2. | ||||
| CVE-2023-53260 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ovl: fix null pointer dereference in ovl_permission() Following process: P1 P2 path_lookupat link_path_walk inode_permission ovl_permission ovl_i_path_real(inode, &realpath) path->dentry = ovl_i_dentry_upper(inode) drop_cache __dentry_kill(ovl_dentry) iput(ovl_inode) ovl_destroy_inode(ovl_inode) dput(oi->__upperdentry) dentry_kill(upperdentry) dentry_unlink_inode upperdentry->d_inode = NULL realinode = d_inode(realpath.dentry) // return NULL inode_permission(realinode) inode->i_sb // NULL pointer dereference , will trigger an null pointer dereference at realinode: [ 335.664979] BUG: kernel NULL pointer dereference, address: 0000000000000002 [ 335.668032] CPU: 0 PID: 2592 Comm: ls Not tainted 6.3.0 [ 335.669956] RIP: 0010:inode_permission+0x33/0x2c0 [ 335.678939] Call Trace: [ 335.679165] <TASK> [ 335.679371] ovl_permission+0xde/0x320 [ 335.679723] inode_permission+0x15e/0x2c0 [ 335.680090] link_path_walk+0x115/0x550 [ 335.680771] path_lookupat.isra.0+0xb2/0x200 [ 335.681170] filename_lookup+0xda/0x240 [ 335.681922] vfs_statx+0xa6/0x1f0 [ 335.682233] vfs_fstatat+0x7b/0xb0 Fetch a reproducer in [Link]. Use the helper ovl_i_path_realinode() to get realinode and then do non-nullptr checking. | ||||
| CVE-2023-53251 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: pcie: fix NULL pointer dereference in iwl_pcie_irq_rx_msix_handler() rxq can be NULL only when trans_pcie->rxq is NULL and entry->entry is zero. For the case when entry->entry is not equal to 0, rxq won't be NULL even if trans_pcie->rxq is NULL. Modify checker to check for trans_pcie->rxq. | ||||
| CVE-2023-53250 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 1373 Comm: modprobe Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:dmi_sysfs_entry_release ... Call Trace: <TASK> kobject_put dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs dmi_decode_table (drivers/firmware/dmi_scan.c:133) dmi_walk (drivers/firmware/dmi_scan.c:1115) dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs do_one_initcall (init/main.c:1296) ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x4000000 from 0xffffffff81000000 ---[ end Kernel panic - not syncing: Fatal exception ]--- It is because previous patch added kobject_put() to release the memory which will call dmi_sysfs_entry_release() and list_del(). However, list_add_tail(entry->list) is called after the error block, so the list_head is uninitialized and cannot be deleted. Move error handling to after list_add_tail to fix this. | ||||
| CVE-2023-53248 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: install stub fence into potential unused fence pointers When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them. | ||||
| CVE-2023-53245 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix handling of virtual Fibre Channel timeouts Hyper-V provides the ability to connect Fibre Channel LUNs to the host system and present them in a guest VM as a SCSI device. I/O to the vFC device is handled by the storvsc driver. The storvsc driver includes a partial integration with the FC transport implemented in the generic portion of the Linux SCSI subsystem so that FC attributes can be displayed in /sys. However, the partial integration means that some aspects of vFC don't work properly. Unfortunately, a full and correct integration isn't practical because of limitations in what Hyper-V provides to the guest. In particular, in the context of Hyper-V storvsc, the FC transport timeout function fc_eh_timed_out() causes a kernel panic because it can't find the rport and dereferences a NULL pointer. The original patch that added the call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this regard. In many cases a timeout is due to a transient condition, so the situation can be improved by just continuing to wait like with other I/O requests issued by storvsc, and avoiding the guaranteed panic. For a permanent failure, continuing to wait may result in a hung thread instead of a panic, which again may be better. So fix the panic by removing the storvsc call to fc_eh_timed_out(). This allows storvsc to keep waiting for a response. The change has been tested by users who experienced a panic in fc_eh_timed_out() due to transient timeouts, and it solves their problem. In the future we may want to deprecate the vFC functionality in storvsc since it can't be fully fixed. But it has current users for whom it is working well enough, so it should probably stay for a while longer. | ||||
| CVE-2023-53244 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: pci: tw68: Fix null-ptr-deref bug in buf prepare and finish When the driver calls tw68_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer buf->cpu. Later when we free the buffer or access the buffer, null ptr deref is triggered. This bug is similar to the following one: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamically triggered from user side. Similarly, we fix this by checking the return value of tw68_risc_buffer() and the value of buf->cpu before buffer free. | ||||
| CVE-2023-53240 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xsk: check IFF_UP earlier in Tx path Xsk Tx can be triggered via either sendmsg() or poll() syscalls. These two paths share a call to common function xsk_xmit() which has two sanity checks within. A pseudo code example to show the two paths: __xsk_sendmsg() : xsk_poll(): if (unlikely(!xsk_is_bound(xs))) if (unlikely(!xsk_is_bound(xs))) return -ENXIO; return mask; if (unlikely(need_wait)) (...) return -EOPNOTSUPP; xsk_xmit() mark napi id (...) xsk_xmit() xsk_xmit(): if (unlikely(!(xs->dev->flags & IFF_UP))) return -ENETDOWN; if (unlikely(!xs->tx)) return -ENOBUFS; As it can be observed above, in sendmsg() napi id can be marked on interface that was not brought up and this causes a NULL ptr dereference: [31757.505631] BUG: kernel NULL pointer dereference, address: 0000000000000018 [31757.512710] #PF: supervisor read access in kernel mode [31757.517936] #PF: error_code(0x0000) - not-present page [31757.523149] PGD 0 P4D 0 [31757.525726] Oops: 0000 [#1] PREEMPT SMP NOPTI [31757.530154] CPU: 26 PID: 95641 Comm: xdpsock Not tainted 6.2.0-rc5+ #40 [31757.536871] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [31757.547457] RIP: 0010:xsk_sendmsg+0xde/0x180 [31757.551799] Code: 00 75 a2 48 8b 00 a8 04 75 9b 84 d2 74 69 8b 85 14 01 00 00 85 c0 75 1b 48 8b 85 28 03 00 00 48 8b 80 98 00 00 00 48 8b 40 20 <8b> 40 18 89 85 14 01 00 00 8b bd 14 01 00 00 81 ff 00 01 00 00 0f [31757.570840] RSP: 0018:ffffc90034f27dc0 EFLAGS: 00010246 [31757.576143] RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000 [31757.583389] RDX: 0000000000000001 RSI: ffffc90034f27e18 RDI: ffff88984cf3c100 [31757.590631] RBP: ffff88984714a800 R08: ffff88984714a800 R09: 0000000000000000 [31757.597877] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000fffffffa [31757.605123] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000000 [31757.612364] FS: 00007fb4c5931180(0000) GS:ffff88afdfa00000(0000) knlGS:0000000000000000 [31757.620571] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [31757.626406] CR2: 0000000000000018 CR3: 000000184b41c003 CR4: 00000000007706e0 [31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [31757.640894] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [31757.648139] PKRU: 55555554 [31757.650894] Call Trace: [31757.653385] <TASK> [31757.655524] sock_sendmsg+0x8f/0xa0 [31757.659077] ? sockfd_lookup_light+0x12/0x70 [31757.663416] __sys_sendto+0xfc/0x170 [31757.667051] ? do_sched_setscheduler+0xdb/0x1b0 [31757.671658] __x64_sys_sendto+0x20/0x30 [31757.675557] do_syscall_64+0x38/0x90 [31757.679197] entry_SYSCALL_64_after_hwframe+0x72/0xdc [31757.687969] Code: 8e f6 ff 44 8b 4c 24 2c 4c 8b 44 24 20 41 89 c4 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 3a 44 89 e7 48 89 44 24 08 e8 b5 8e f6 ff 48 [31757.707007] RSP: 002b:00007ffd49c73c70 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [31757.714694] RAX: ffffffffffffffda RBX: 000055a996565380 RCX: 00007fb4c5727c16 [31757.721939] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 [31757.729184] RBP: 0000000000000040 R08: 0000000000000000 R09: 0000000000000000 [31757.736429] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000 [31757.743673] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [31757.754940] </TASK> To fix this, let's make xsk_xmit a function that will be responsible for generic Tx, where RCU is handled accordingly and pull out sanity checks and xs->zc handling. Populate sanity checks to __xsk_sendmsg() and xsk_poll(). | ||||
| CVE-2023-53239 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Add check for kzalloc As kzalloc may fail and return NULL pointer, it should be better to check the return value in order to avoid the NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/514154/ | ||||
| CVE-2023-53228 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: drop redundant sched job cleanup when cs is aborted Once command submission failed due to userptr invalidation in amdgpu_cs_submit, legacy code will perform cleanup of scheduler job. However, it's not needed at all, as former commit has integrated job cleanup stuff into amdgpu_job_free. Otherwise, because of double free, a NULL pointer dereference will occur in such scenario. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457 | ||||
| CVE-2023-53223 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Add missing check for alloc_ordered_workqueue Add check for the return value of alloc_ordered_workqueue as it may return NULL pointer and cause NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/517646/ | ||||
| CVE-2023-53220 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: az6007: Fix null-ptr-deref in az6007_i2c_xfer() In az6007_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach az6007_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()") | ||||
| CVE-2023-53210 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: md/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid() r5l_flush_stripe_to_raid() will check if the list 'flushing_ios' is empty, and then submit 'flush_bio', however, r5l_log_flush_endio() is clearing the list first and then clear the bio, which will cause null-ptr-deref: T1: submit flush io raid5d handle_active_stripes r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init submit_bio // io1 T2: io1 is done r5l_log_flush_endio list_splice_tail_init // clear the list T3: submit new flush io ... r5l_flush_stripe_to_raid // list is empty // add 'io_end_ios' to the list bio_init bio_uninit // clear bio->bi_blkg submit_bio // null-ptr-deref Fix this problem by clearing bio before clearing the list in r5l_log_flush_endio(). | ||||
| CVE-2023-53209 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: Fix possible NULL dereference In a call to mac80211_hwsim_select_tx_link() the sta pointer might be NULL, thus need to check that it is not NULL before accessing it. | ||||
| CVE-2026-21301 | 1 Adobe | 1 Substance 3d Modeler | 2026-01-14 | 5.5 Medium |
| Substance3D - Modeler versions 1.22.4 and earlier are affected by a NULL Pointer Dereference vulnerability that could lead to application denial-of-service. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2025-53477 | 1 Apache | 1 Nimble | 2026-01-14 | 7.5 High |
| NULL Pointer Dereference vulnerability in Apache Nimble. Missing validation of HCI connection complete or HCI command TX buffer could lead to NULL pointer dereference. This issue requires disabled asserts and broken or bogus Bluetooth controller and thus severity is considered low. This issue affects Apache NimBLE: through 1.8.0. Users are recommended to upgrade to version 1.9.0, which fixes the issue. | ||||