| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Uninitialized Use in ANGLE in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: High) |
| Uninitialized Use in ANGLE in Google Chrome prior to 148.0.7778.216 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: High) |
| In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: Fix TX deadlock when using DMA
`dmaengine_terminate_async` does not guarantee that the
`__dma_tx_complete` callback will run. The callback is currently the
only place where `dma->tx_running` gets cleared. If the transaction is
canceled and the callback never runs, then `dma->tx_running` will never
get cleared and we will never schedule new TX DMA transactions again.
This change makes it so we clear `dma->tx_running` after we terminate
the DMA transaction. This is "safe" because `serial8250_tx_dma_flush`
is holding the UART port lock. The first thing the callback does is also
grab the UART port lock, so access to `dma->tx_running` is serialized. |
| In the Linux kernel, the following vulnerability has been resolved:
apparmor: validate DFA start states are in bounds in unpack_pdb
Start states are read from untrusted data and used as indexes into the
DFA state tables. The aa_dfa_next() function call in unpack_pdb() will
access dfa->tables[YYTD_ID_BASE][start], and if the start state exceeds
the number of states in the DFA, this results in an out-of-bound read.
==================================================================
BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360
Read of size 4 at addr ffff88811956fb90 by task su/1097
...
Reject policies with out-of-bounds start states during unpacking
to prevent the issue. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()
l2cap_ecred_reconf_rsp() casts the incoming data to struct
l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with
result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes
with result at offset 0).
This causes two problems:
- The sizeof(*rsp) length check requires 8 bytes instead of the
correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected
with -EPROTO.
- rsp->result reads from offset 6 instead of offset 0, returning
wrong data when the packet is large enough to pass the check.
Fix by using the correct type. Also pass the already byte-swapped
result variable to BT_DBG instead of the raw __le16 field. |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: don't irele after failing to iget in xfs_attri_recover_work
xlog_recovery_iget* never set @ip to a valid pointer if they return
an error, so this irele will walk off a dangling pointer. Fix that. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix not releasing workqueue on .release()
The workqueue associated with an DSA/IAA device is not released when
the object is freed. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: always drain queued discard work in ext4_mb_release()
While reviewing recent ext4 patch[1], Sashiko raised the following
concern[2]:
> If the filesystem is initially mounted with the discard option,
> deleting files will populate sbi->s_discard_list and queue
> s_discard_work. If it is then remounted with nodiscard, the
> EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is
> neither cancelled nor flushed.
[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/
[2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev
The concern was valid, but it had nothing to do with the patch[1].
One of the problems with Sashiko in its current (early) form is that
it will detect pre-existing issues and report it as a problem with the
patch that it is reviewing.
In practice, it would be hard to hit deliberately (unless you are a
malicious syzkaller fuzzer), since it would involve mounting the file
system with -o discard, and then deleting a large number of files,
remounting the file system with -o nodiscard, and then immediately
unmounting the file system before the queued discard work has a change
to drain on its own.
Fix it because it's a real bug, and to avoid Sashiko from raising this
concern when analyzing future patches to mballoc.c. |
| This CVE ID has been rejected by its CVE Numbering Authority (CNA). It was determined that the -p flag behavior is documented in Anthropic's claude -h output with an explicit warning that non-interactive mode should only be used in trusted directories, making this intended and described behavior rather than a vulnerability. |
| This CVE ID has been rejected by its CVE Numbering Authority (CNA). It was determined that the affected code path cannot be triggered through normal usage of Claude Code. |
| This CVE ID has been rejected by the its CVE Numbering Authority (CNA). It was determined that the attack requires an attacker to already control arbitrary environment variables, a level of access they consider functionally equivalent to code execution and outside the threat model of CLI tools. |
| In JetBrains YouTrack before 2026.1.13570 improper access control allowed enumeration of restricted issues and articles on Planning Canvas |
| In JetBrains YouTrack before 2026.1.13570 improper access control allowed low-privileged users to modify service accounts |
| In JetBrains PyCharm before 2025.3.4 stored XSS in Jupyter notebook Markdown cells was possible |
| In JetBrains IntelliJ IDEA before 2026.1 xXE in the UI Designer form parser was possible |
| In JetBrains IntelliJ IDEA before 2026.1 code execution was possible via template injection in the Copyright plugin |
| In JetBrains TeamCity before 2026.1 stored XSS on the SAML login page was possible |
| In JetBrains TeamCity before 2026.1 open redirect in the SAML plugin was possible |
| In JetBrains TeamCity before 2026.1 credentials could be exposed in thread names |
| In JetBrains TeamCity before 2026.1 credentials parameters were exposed via parameter autocompletion |
