| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Reliance on a component that is not updateable in Windows Secure Boot allows an authorized attacker to bypass a security feature locally. |
| Use after free in Windows Telephony Service allows an authorized attacker to elevate privileges locally. |
| Integer underflow (wrap or wraparound) in Windows Common Log File System Driver allows an authorized attacker to elevate privileges locally. |
| External control of file name or path in Microsoft Edge (Chromium-based) allows an unauthorized attacker to disclose information over a network. |
| Heap-based buffer overflow in Windows Remote Desktop allows an authorized attacker to elevate privileges locally. |
| Code injection in SQL code generation in Apache Flink 1.15.0 through 1.20.x and 2.0.0 through 2.x allows authenticated users with query submission privileges to execute arbitrary code on TaskManagers via maliciously crafted SQL queries. The vulnerability affects JSON functions (1.15.0+) and LIKE expressions with ESCAPE clauses (1.17.0+). User-controlled strings are interpolated into generated Java code without proper escaping, allowing attackers to break out of string literals and inject arbitrary expressions.
Users are recommended to upgrade to either version 1.20.4, 2.0.2, 2.1.2 or 2.2.1, which fixes this issue. |
| `gh` is GitHub’s official command line tool. From 1.6.0 to before 2.92.0, a security vulnerability has been identified in GitHub CLI that could allow terminal escape sequence injection when users view GitHub Actions workflow logs using gh run view --log or gh run view --log-failed. The vulnerability stems from the way GitHub CLI handles raw Actions log output. The gh run view --log and gh run view --log-failed commands stream workflow log lines to stdout or the configured pager without sanitizing terminal control sequences. An attacker who can influence GitHub Actions log content, for example via a PR triggered workflow, can embed escape sequences that are replayed in the user's terminal when they inspect the run. Depending on the victim's terminal emulator, injected sequences could change the window title, manipulate on screen content, or in some terminal emulators (such as screen) potentially execute arbitrary commands. This vulnerability is fixed in 2.92.0. |
| Stack-based buffer overflow in Windows TCP/IP allows an authorized attacker to elevate privileges locally. |
| Null pointer dereference in Windows TCP/IP allows an unauthorized attacker to deny service locally. |
| Use after free in Windows Hyper-V allows an unauthorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Win32K - GRFX allows an authorized attacker to execute code locally. |
| Null pointer dereference in Windows TCP/IP allows an unauthorized attacker to deny service over a network. |
| Use after free in Windows TCP/IP allows an unauthorized attacker to disclose information over a network. |
| Insufficient validation of untrusted input in SiteIsolation in Google Chrome prior to 148.0.7778.168 allowed a remote attacker who had compromised the renderer process to bypass Site Isolation via a crafted HTML page. (Chromium security severity: High) |
| Improper neutralization of input during web page generation ('cross-site scripting') in Microsoft Exchange Server allows an unauthorized attacker to perform spoofing over a network. |
| Heap-based buffer overflow in Windows Common Log File System Driver allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix potential overflow of shmem scatterlist length
When a scatterlists table of a GEM shmem object of size 4 GB or more is
populated with pages allocated from a folio, unsigned int .length
attribute of a scatterlist may get overflowed if total byte length of
pages allocated to that single scatterlist happens to reach or cross the
4GB limit. As a consequence, users of the object may suffer from hitting
unexpected, premature end of the object's backing pages.
[278.780187] ------------[ cut here ]------------
[278.780377] WARNING: CPU: 1 PID: 2326 at drivers/gpu/drm/i915/i915_mm.c:55 remap_sg+0x199/0x1d0 [i915]
...
[278.780654] CPU: 1 UID: 0 PID: 2326 Comm: gem_mmap_offset Tainted: G S U 6.17.0-rc1-CI_DRM_16981-ged823aaa0607+ #1 PREEMPT(voluntary)
[278.780656] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER
[278.780658] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
[278.780659] RIP: 0010:remap_sg+0x199/0x1d0 [i915]
...
[278.780786] Call Trace:
[278.780787] <TASK>
[278.780788] ? __apply_to_page_range+0x3e6/0x910
[278.780795] ? __pfx_remap_sg+0x10/0x10 [i915]
[278.780906] apply_to_page_range+0x14/0x30
[278.780908] remap_io_sg+0x14d/0x260 [i915]
[278.781013] vm_fault_cpu+0xd2/0x330 [i915]
[278.781137] __do_fault+0x3a/0x1b0
[278.781140] do_fault+0x322/0x640
[278.781143] __handle_mm_fault+0x938/0xfd0
[278.781150] handle_mm_fault+0x12c/0x300
[278.781152] ? lock_mm_and_find_vma+0x4b/0x760
[278.781155] do_user_addr_fault+0x2d6/0x8e0
[278.781160] exc_page_fault+0x96/0x2c0
[278.781165] asm_exc_page_fault+0x27/0x30
...
That issue was apprehended by the author of a change that introduced it,
and potential risk even annotated with a comment, but then never addressed.
When adding folio pages to a scatterlist table, take care of byte length
of any single scatterlist not exceeding max_segment.
(cherry picked from commit 06249b4e691a75694c014a61708c007fb5755f60) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix NULL pointer dereference in device cleanup
When GPU initialization fails due to an unsupported HW block
IP blocks may have a NULL version pointer. During cleanup in
amdgpu_device_fini_hw, the code calls amdgpu_device_set_pg_state and
amdgpu_device_set_cg_state which iterate over all IP blocks and access
adev->ip_blocks[i].version without NULL checks, leading to a kernel
NULL pointer dereference.
Add NULL checks for adev->ip_blocks[i].version in both
amdgpu_device_set_cg_state and amdgpu_device_set_pg_state to prevent
dereferencing NULL pointers during GPU teardown when initialization has
failed.
(cherry picked from commit b7ac77468cda92eecae560b05f62f997a12fe2f2) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix use-after-free race in VM acquire
Replace non-atomic vm->process_info assignment with cmpxchg()
to prevent race when parent/child processes sharing a drm_file
both try to acquire the same VM after fork().
(cherry picked from commit c7c573275ec20db05be769288a3e3bb2250ec618) |
| In the Linux kernel, the following vulnerability has been resolved:
net: macb: Shuffle the tx ring before enabling tx
Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board,
the rootfs may take an extended time to recover after a suspend.
Upon investigation, it was determined that the issue originates from a
problem in the macb driver.
According to the Zynq UltraScale TRM [1], when transmit is disabled,
the transmit buffer queue pointer resets to point to the address
specified by the transmit buffer queue base address register.
In the current implementation, the code merely resets `queue->tx_head`
and `queue->tx_tail` to '0'. This approach presents several issues:
- Packets already queued in the tx ring are silently lost,
leading to memory leaks since the associated skbs cannot be released.
- Concurrent write access to `queue->tx_head` and `queue->tx_tail` may
occur from `macb_tx_poll()` or `macb_start_xmit()` when these values
are reset to '0'.
- The transmission may become stuck on a packet that has already been sent
out, with its 'TX_USED' bit set, but has not yet been processed. However,
due to the manipulation of 'queue->tx_head' and 'queue->tx_tail',
`macb_tx_poll()` incorrectly assumes there are no packets to handle
because `queue->tx_head == queue->tx_tail`. This issue is only resolved
when a new packet is placed at this position. This is the root cause of
the prolonged recovery time observed for the NFS root filesystem.
To resolve this issue, shuffle the tx ring and tx skb array so that
the first unsent packet is positioned at the start of the tx ring.
Additionally, ensure that updates to `queue->tx_head` and
`queue->tx_tail` are properly protected with the appropriate lock.
[1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm |
