| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In JetBrains WebStorm before 2026.2 arbitrary code execution was possible before granting project trust via project-local linter tooling |
| In JetBrains PhpStorm before 2026.2 arbitrary code execution was possible before granting project trust via project tooling |
| In JetBrains IntelliJ IDEA before 2026.2 arbitrary code execution was possible before granting project trust via development container configuration |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: loongson - Remove broken and unused loongson-rng
The loongson-rng rng_alg has several vulnerabilities, including not
providing forward security, and a use-after-free bug due to the use of
wait_for_completion_interruptible().
Meanwhile, the rng_alg framework doesn't really have any purpose in the
first place other than to access the software algorithms crypto/drbg.c
and crypto/jitterentropy.c. Hardware-specific rng_algs have no
in-kernel user, and unlike hwrng there's no feed into the actual Linux
RNG. As such, there's really no point to this code. There are of
course other rng_alg drivers that are similarly unused, but they're
similarly in the process of being phased out, e.g.
https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and
https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org
Given that, there's no point in fixing forward these vulnerabilities,
and it makes much more sense to simply roll back the addition of this
driver. If this platform provides TRNG (not PRNG) functionality, it
could make sense to add a hwrng driver, but it would be quite different. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: iowarrior: fix use-after-free on disconnect race
mutex_unlock() may access the mutex structure after releasing the lock
and therefore cannot be used to manage lifetime of objects directly
(unlike spinlocks and refcounts). [1][2]
Use a kref to release the driver data to avoid use-after-free in
mutex_unlock() when release() races with disconnect().
[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic")
[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most
other sleeping locks, can still use the lock object
after it's unlocked") |
| Uninitialized Use in Skia in Google Chrome on Windows prior to 151.0.7922.72 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low) |
| In the Linux kernel, the following vulnerability has been resolved:
dm vdo: don't refer to dedupe_context after releasing it
Clear the dedupe_context pointer in a data_vio whenever ownership of
the context is lost, so that vdo can't examine it accidentally. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix uninitialized pointer free on read_alloc_one_name() error
The function read_alloc_one_name() does not initialize the name field of
the passed fscrypt_str struct if kmalloc fails to allocate the
corresponding buffer. Thus, it is not guaranteed that
fscrypt_str.name is initialized when freeing it.
This is a follow-up to the linked patch that fixes the remaining
instances of the bug introduced by commit e43eec81c516 ("btrfs: use
struct qstr instead of name and namelen pairs"). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Stop the active perfmon before being destroyed
When running `kmscube` with one or more performance monitors enabled
via `GALLIUM_HUD`, the following kernel panic can occur:
[ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4
[ 55.008368] Mem abort info:
[ 55.008377] ESR = 0x0000000096000005
[ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits
[ 55.008402] SET = 0, FnV = 0
[ 55.008412] EA = 0, S1PTW = 0
[ 55.008421] FSC = 0x05: level 1 translation fault
[ 55.008434] Data abort info:
[ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000
[ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper
gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb
drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight
[ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1
[ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608
[ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608
[ 55.008895] sp : ffffffc080673cf0
[ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28
[ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148
[ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38
[ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000
[ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90
[ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0
[ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04
[ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857
[ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470
[ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470
[ 55.013292] Call trace:
[ 55.013959] __mutex_lock.constprop.0+0x90/0x608
[ 55.014646] __mutex_lock_slowpath+0x1c/0x30
[ 55.015317] mutex_lock+0x50/0x68
[ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d]
[ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d]
[ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched]
[ 55.017921] kthread+0x11c/0x128
[ 55.018554] ret_from_fork+0x10/0x20
[ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401)
[ 55.019776] ---[ end trace 0000000000000000 ]---
[ 55.020411] note: v3d_bin[166] exited with preempt_count 1
This issue arises because, upon closing the file descriptor (which happens
when we interrupt `kmscube`), the active performance monitor is not
stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`,
the active performance monitor's pointer (`v3d->active_perfmon`) is still
retained.
If `kmscube` is run again, the driver will attempt to stop the active
performance monitor using the stale pointer in `v3d->active_perfmon`.
However, this pointer is no longer valid because the previous process has
already terminated, and all performance monitors associated with it have
been destroyed and freed.
To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it. |
| In the Linux kernel, the following vulnerability has been resolved:
um: line: always fill *error_out in setup_one_line()
The pointer isn't initialized by callers, but I have
encountered cases where it's still printed; initialize
it in all possible cases in setup_one_line(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fix error code in drm_client_buffer_vmap_local()
This function accidentally returns zero/success on the failure path.
It leads to locking issues and an uninitialized *map_copy in the
caller. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: xilinx: xdma: Fix data synchronisation in xdma_channel_isr()
Requests the vchan lock before using xdma->stop_request. |
| In the Linux kernel, the following vulnerability has been resolved:
gve: Clear napi->skb before dev_kfree_skb_any()
gve_rx_free_skb incorrectly leaves napi->skb referencing an skb after it
is freed with dev_kfree_skb_any(). This can result in a subsequent call
to napi_get_frags returning a dangling pointer.
Fix this by clearing napi->skb before the skb is freed. |
| In the Linux kernel, the following vulnerability has been resolved:
net: core: reject skb_copy(_expand) for fraglist GSO skbs
SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become
invalid. Return NULL if such an skb is passed to skb_copy or
skb_copy_expand, in order to prevent a crash on a potential later
call to skb_gso_segment. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: keep DMA buffers required for suspend/resume
Nouveau deallocates a few buffers post GPU init which are required for GPU suspend/resume to function correctly.
This is likely not as big an issue on systems where the NVGPU is the only GPU, but on multi-GPU set ups it leads to a regression where the kernel module errors and results in a system-wide rendering freeze.
This commit addresses that regression by moving the two buffers required for suspend and resume to be deallocated at driver unload instead of post init. |
| In the Linux kernel, the following vulnerability has been resolved:
Both cadence-quadspi ->runtime_suspend() and ->runtime_resume()
implementations start with:
struct cqspi_st *cqspi = dev_get_drvdata(dev);
struct spi_controller *host = dev_get_drvdata(dev);
This obviously cannot be correct, unless "struct cqspi_st" is the
first member of " struct spi_controller", or the other way around, but
it is not the case. "struct spi_controller" is allocated by
devm_spi_alloc_host(), which allocates an extra amount of memory for
private data, used to store "struct cqspi_st".
The ->probe() function of the cadence-quadspi driver then sets the
device drvdata to store the address of the "struct cqspi_st"
structure. Therefore:
struct cqspi_st *cqspi = dev_get_drvdata(dev);
is correct, but:
struct spi_controller *host = dev_get_drvdata(dev);
is not, as it makes "host" point not to a "struct spi_controller" but
to the same "struct cqspi_st" structure as above.
This obviously leads to bad things (memory corruption, kernel crashes)
directly during ->probe(), as ->probe() enables the device using PM
runtime, leading the ->runtime_resume() hook being called, which in
turns calls spi_controller_resume() with the wrong pointer.
This has at least been reported [0] to cause a kernel crash, but the
exact behavior will depend on the memory contents.
[0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/
This issue potentially affects all platforms that are currently using
the cadence-quadspi driver. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: Fix uninitialized pointer dmactl
In the case where __lpass_get_dmactl_handle is called and the driver
id dai_id is invalid the pointer dmactl is not being assigned a value,
and dmactl contains a garbage value since it has not been initialized
and so the null check may not work. Fix this to initialize dmactl to
NULL. One could argue that modern compilers will set this to zero, but
it is useful to keep this initialized as per the same way in functions
__lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params.
Cleans up clang scan build warning:
sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition
evaluates to a garbage value [core.uninitialized.Branch] |
| In the Linux kernel, the following vulnerability has been resolved:
tee: amdtee: fix race condition in amdtee_open_session
There is a potential race condition in amdtee_open_session that may
lead to use-after-free. For instance, in amdtee_open_session() after
sess->sess_mask is set, and before setting:
sess->session_info[i] = session_info;
if amdtee_close_session() closes this same session, then 'sess' data
structure will be released, causing kernel panic when 'sess' is
accessed within amdtee_open_session().
The solution is to set the bit sess->sess_mask as the last step in
amdtee_open_session(). |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: fix stuck flows on cleanup due to pending work
To clear the flow table on flow table free, the following sequence
normally happens in order:
1) gc_step work is stopped to disable any further stats/del requests.
2) All flow table entries are set to teardown state.
3) Run gc_step which will queue HW del work for each flow table entry.
4) Waiting for the above del work to finish (flush).
5) Run gc_step again, deleting all entries from the flow table.
6) Flow table is freed.
But if a flow table entry already has pending HW stats or HW add work
step 3 will not queue HW del work (it will be skipped), step 4 will wait
for the pending add/stats to finish, and step 5 will queue HW del work
which might execute after freeing of the flow table.
To fix the above, this patch flushes the pending work, then it sets the
teardown flag to all flows in the flowtable and it forces a garbage
collector run to queue work to remove the flows from hardware, then it
flushes this new pending work and (finally) it forces another garbage
collector run to remove the entry from the software flowtable.
Stack trace:
[47773.882335] BUG: KASAN: use-after-free in down_read+0x99/0x460
[47773.883634] Write of size 8 at addr ffff888103b45aa8 by task kworker/u20:6/543704
[47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 Not tainted 5.12.0-rc7+ #2
[47773.886745] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
[47773.888438] Workqueue: nf_ft_offload_del flow_offload_work_handler [nf_flow_table]
[47773.889727] Call Trace:
[47773.890214] dump_stack+0xbb/0x107
[47773.890818] print_address_description.constprop.0+0x18/0x140
[47773.892990] kasan_report.cold+0x7c/0xd8
[47773.894459] kasan_check_range+0x145/0x1a0
[47773.895174] down_read+0x99/0x460
[47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table]
[47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table]
[47773.913372] process_one_work+0x8ac/0x14e0
[47773.921325]
[47773.921325] Allocated by task 592159:
[47773.922031] kasan_save_stack+0x1b/0x40
[47773.922730] __kasan_kmalloc+0x7a/0x90
[47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct]
[47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct]
[47773.925207] tcf_action_init_1+0x45b/0x700
[47773.925987] tcf_action_init+0x453/0x6b0
[47773.926692] tcf_exts_validate+0x3d0/0x600
[47773.927419] fl_change+0x757/0x4a51 [cls_flower]
[47773.928227] tc_new_tfilter+0x89a/0x2070
[47773.936652]
[47773.936652] Freed by task 543704:
[47773.937303] kasan_save_stack+0x1b/0x40
[47773.938039] kasan_set_track+0x1c/0x30
[47773.938731] kasan_set_free_info+0x20/0x30
[47773.939467] __kasan_slab_free+0xe7/0x120
[47773.940194] slab_free_freelist_hook+0x86/0x190
[47773.941038] kfree+0xce/0x3a0
[47773.941644] tcf_ct_flow_table_cleanup_work
Original patch description and stack trace by Paul Blakey. |
| In the Linux kernel, the following vulnerability has been resolved:
dm btree remove: assign new_root only when removal succeeds
remove_raw() in dm_btree_remove() may fail due to IO read error
(e.g. read the content of origin block fails during shadowing),
and the value of shadow_spine::root is uninitialized, but
the uninitialized value is still assign to new_root in the
end of dm_btree_remove().
For dm-thin, the value of pmd->details_root or pmd->root will become
an uninitialized value, so if trying to read details_info tree again
out-of-bound memory may occur as showed below:
general protection fault, probably for non-canonical address 0x3fdcb14c8d7520
CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6
Hardware name: QEMU Standard PC
RIP: 0010:metadata_ll_load_ie+0x14/0x30
Call Trace:
sm_metadata_count_is_more_than_one+0xb9/0xe0
dm_tm_shadow_block+0x52/0x1c0
shadow_step+0x59/0xf0
remove_raw+0xb2/0x170
dm_btree_remove+0xf4/0x1c0
dm_pool_delete_thin_device+0xc3/0x140
pool_message+0x218/0x2b0
target_message+0x251/0x290
ctl_ioctl+0x1c4/0x4d0
dm_ctl_ioctl+0xe/0x20
__x64_sys_ioctl+0x7b/0xb0
do_syscall_64+0x40/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixing it by only assign new_root when removal succeeds |
