Total
18798 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-26981 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix OOB in nilfs_set_de_type The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob } However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors. | |||||
| CVE-2024-26978 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: serial: max310x: fix NULL pointer dereference in I2C instantiation When trying to instantiate a max14830 device from userspace: echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device we get the following error: Unable to handle kernel NULL pointer dereference at virtual address... ... Call trace: max310x_i2c_probe+0x48/0x170 [max310x] i2c_device_probe+0x150/0x2a0 ... Add check for validity of devtype to prevent the error, and abort probe with a meaningful error message. | |||||
| CVE-2024-26977 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: pci_iounmap(): Fix MMIO mapping leak The #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentally also guards iounmap(), which means MMIO mappings are leaked. Move the guard so we call iounmap() for MMIO mappings. | |||||
| CVE-2024-26975 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix a NULL pointer dereference A NULL pointer dereference is triggered when probing the MMIO RAPL driver on platforms with CPU ID not listed in intel_rapl_common CPU model list. This is because the intel_rapl_common module still probes on such platforms even if 'defaults_msr' is not set after commit 1488ac990ac8 ("powercap: intel_rapl: Allow probing without CPUID match"). Thus the MMIO RAPL rp->priv->defaults is NULL when registering to RAPL framework. Fix the problem by adding sanity check to ensure rp->priv->rapl_defaults is always valid. | |||||
| CVE-2024-26973 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: fat: fix uninitialized field in nostale filehandles When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. | |||||
| CVE-2024-26970 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. | |||||
| CVE-2024-26964 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Add error handling in xhci_map_urb_for_dma Currently xhci_map_urb_for_dma() creates a temporary buffer and copies the SG list to the new linear buffer. But if the kzalloc_node() fails, then the following sg_pcopy_to_buffer() can lead to crash since it tries to memcpy to NULL pointer. So return -ENOMEM if kzalloc returns null pointer. | |||||
| CVE-2024-26963 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: usb: dwc3-am62: fix module unload/reload behavior As runtime PM is enabled, the module can be runtime suspended when .remove() is called. Do a pm_runtime_get_sync() to make sure module is active before doing any register operations. Doing a pm_runtime_put_sync() should disable the refclk so no need to disable it again. Fixes the below warning at module removel. [ 39.705310] ------------[ cut here ]------------ [ 39.710004] clk:162:3 already disabled [ 39.713941] WARNING: CPU: 0 PID: 921 at drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8 We called of_platform_populate() in .probe() so call the cleanup function of_platform_depopulate() in .remove(). Get rid of the now unnnecessary dwc3_ti_remove_core(). Without this, module re-load doesn't work properly. | |||||
| CVE-2024-26962 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang: 1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set; After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang: [root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 This is because reshape can't make progress. For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more: 1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'. However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO. | |||||
| CVE-2024-26959 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Fix btnxpuart_close Fix scheduling while atomic BUG in btnxpuart_close(), properly purge the transmit queue and free the receive skb. [ 10.973809] BUG: scheduling while atomic: kworker/u9:0/80/0x00000002 ... [ 10.980740] CPU: 3 PID: 80 Comm: kworker/u9:0 Not tainted 6.8.0-rc7-0.0.0-devel-00005-g61fdfceacf09 #1 [ 10.980751] Hardware name: Toradex Verdin AM62 WB on Dahlia Board (DT) [ 10.980760] Workqueue: hci0 hci_power_off [bluetooth] [ 10.981169] Call trace: ... [ 10.981363] uart_update_mctrl+0x58/0x78 [ 10.981373] uart_dtr_rts+0x104/0x114 [ 10.981381] tty_port_shutdown+0xd4/0xdc [ 10.981396] tty_port_close+0x40/0xbc [ 10.981407] uart_close+0x34/0x9c [ 10.981414] ttyport_close+0x50/0x94 [ 10.981430] serdev_device_close+0x40/0x50 [ 10.981442] btnxpuart_close+0x24/0x98 [btnxpuart] [ 10.981469] hci_dev_close_sync+0x2d8/0x718 [bluetooth] [ 10.981728] hci_dev_do_close+0x2c/0x70 [bluetooth] [ 10.981862] hci_power_off+0x20/0x64 [bluetooth] | |||||
| CVE-2024-26956 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix failure to detect DAT corruption in btree and direct mappings Patch series "nilfs2: fix kernel bug at submit_bh_wbc()". This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch. The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such. This patch (of 2): Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted. There are two flaws involved in this issue. The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently. The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing. This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer. | |||||
| CVE-2024-26955 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent kernel bug at submit_bh_wbc() Fix a bug where nilfs_get_block() returns a successful status when searching and inserting the specified block both fail inconsistently. If this inconsistent behavior is not due to a previously fixed bug, then an unexpected race is occurring, so return a temporary error -EAGAIN instead. This prevents callers such as __block_write_begin_int() from requesting a read into a buffer that is not mapped, which would cause the BUG_ON check for the BH_Mapped flag in submit_bh_wbc() to fail. | |||||
| CVE-2024-26949 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: Fix NULL pointer dereference when get power limit Because powerplay_table initialization is skipped under sriov case, We check and set default lower and upper OD value if powerplay_table is NULL. | |||||
| CVE-2024-26948 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add a dc_state NULL check in dc_state_release [How] Check wheather state is NULL before releasing it. | |||||
| CVE-2024-26947 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is：0xc0900000, 0x100000 the crash backtrace like: Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception So check if PG_reserved was set to solve this issue. [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/ | |||||
| CVE-2024-26946 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address Read from an unsafe address with copy_from_kernel_nofault() in arch_adjust_kprobe_addr() because this function is used before checking the address is in text or not. Syzcaller bot found a bug and reported the case if user specifies inaccessible data area, arch_adjust_kprobe_addr() will cause a kernel panic. [ mingo: Clarified the comment. ] | |||||
| CVE-2024-26945 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 8.4 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix nr_cpus < nr_iaa case If nr_cpus < nr_iaa, the calculated cpus_per_iaa will be 0, which causes a divide-by-0 in rebalance_wq_table(). Make sure cpus_per_iaa is 1 in that case, and also in the nr_iaa == 0 case, even though cpus_per_iaa is never used if nr_iaa == 0, for paranoia. | |||||
| CVE-2024-26943 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: handle kcalloc() allocation failure The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations. | |||||
| CVE-2024-26942 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: phy: qcom: at803x: fix kernel panic with at8031_probe On reworking and splitting the at803x driver, in splitting function of at803x PHYs it was added a NULL dereference bug where priv is referenced before it's actually allocated and then is tried to write to for the is_1000basex and is_fiber variables in the case of at8031, writing on the wrong address. Fix this by correctly setting priv local variable only after at803x_probe is called and actually allocates priv in the phydev struct. | |||||
| CVE-2024-26941 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/dp: Fix divide-by-zero regression on DP MST unplug with nouveau Fix a regression when using nouveau and unplugging a StarTech MSTDP122DP DisplayPort 1.2 MST hub (the same regression does not appear when using a Cable Matters DisplayPort 1.4 MST hub). Trace: divide error: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744 Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018 RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31 RSP: 0018:ffffb2c5c211fa30 EFLAGS: 00010206 RAX: ffffffffffffffff RBX: 0000000000000000 RCX: 0000000000f59b00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb2c5c211fa48 R08: 0000000000000001 R09: 0000000000000020 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000023b4a R13: ffff91d37d165800 R14: ffff91d36fac6d80 R15: ffff91d34a764010 FS: 00007f4a1ca3fa80(0000) GS:ffff91d6edbc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559491d49000 CR3: 000000011d180002 CR4: 00000000003706f0 Call Trace: <TASK> ? show_regs+0x6d/0x80 ? die+0x37/0xa0 ? do_trap+0xd4/0xf0 ? do_error_trap+0x71/0xb0 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? exc_divide_error+0x3a/0x70 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? asm_exc_divide_error+0x1b/0x20 ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper] nv50_msto_atomic_check+0xda/0x120 [nouveau] drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper] drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper] nv50_disp_atomic_check+0x13f/0x2f0 [nouveau] drm_atomic_check_only+0x668/0xb20 [drm] ? drm_connector_list_iter_next+0x86/0xc0 [drm] drm_atomic_commit+0x58/0xd0 [drm] ? __pfx___drm_printfn_info+0x10/0x10 [drm] drm_atomic_connector_commit_dpms+0xd7/0x100 [drm] drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] drm_connector_property_set_ioctl+0x3b/0x60 [drm] drm_ioctl_kernel+0xb9/0x120 [drm] drm_ioctl+0x2d0/0x550 [drm] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm] nouveau_drm_ioctl+0x61/0xc0 [nouveau] __x64_sys_ioctl+0xa0/0xf0 do_syscall_64+0x76/0x140 ? do_syscall_64+0x85/0x140 ? do_syscall_64+0x85/0x140 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f4a1cd1a94f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 RSP: 002b:00007ffd2f1df520 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd2f1df5b0 RCX: 00007f4a1cd1a94f RDX: 00007ffd2f1df5b0 RSI: 00000000c01064ab RDI: 000000000000000f RBP: 00000000c01064ab R08: 000056347932deb8 R09: 000056347a7d99c0 R10: 0000000000000000 R11: 0000000000000246 R12: 000056347938a220 R13: 000000000000000f R14: 0000563479d9f3f0 R15: 0000000000000000 </TASK> Modules linked in: rfcomm 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 nf_tables nfnetlink br_netfilter bridge stp llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_ ---truncated--- | |||||