| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: mgb4: protect driver against spectre
Frequency range is set from sysfs via frequency_range_store(),
being vulnerable to spectre, as reported by smatch:
drivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r]
drivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set'
Fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: dapm: fix bounds checker error in dapm_widget_list_create
The widgets array in the snd_soc_dapm_widget_list has a __counted_by
attribute attached to it, which points to the num_widgets variable. This
attribute is used in bounds checking, and if it is not set before the
array is filled, then the bounds sanitizer will issue a warning or a
kernel panic if CONFIG_UBSAN_TRAP is set.
This patch sets the size of the widgets list calculated with
list_for_each as the initial value for num_widgets as it is used for
allocating memory for the array. It is updated with the actual number of
added elements after the array is filled. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/damon/core: avoid overflow in damon_feed_loop_next_input()
damon_feed_loop_next_input() is inefficient and fragile to overflows.
Specifically, 'score_goal_diff_bp' calculation can overflow when 'score'
is high. The calculation is actually unnecessary at all because 'goal' is
a constant of value 10,000. Calculation of 'compensation' is again
fragile to overflow. Final calculation of return value for under-achiving
case is again fragile to overflow when the current score is
under-achieving the target.
Add two corner cases handling at the beginning of the function to make the
body easier to read, and rewrite the body of the function to avoid
overflows and the unnecessary bp value calcuation. |
| In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan()
KASAN reported following issue:
BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt]
Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11
CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387
Tainted: [U]=USER
Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt]
Call Trace:
<TASK>
dump_stack_lvl+0x6c/0x90
print_report+0xd1/0x630
kasan_report+0xdb/0x110
__asan_report_load4_noabort+0x14/0x20
tb_retimer_scan+0xffe/0x1550 [thunderbolt]
tb_scan_port+0xa6f/0x2060 [thunderbolt]
tb_handle_hotplug+0x17b1/0x3080 [thunderbolt]
process_one_work+0x626/0x1100
worker_thread+0x6c8/0xfa0
kthread+0x2c8/0x3a0
ret_from_fork+0x3a/0x80
ret_from_fork_asm+0x1a/0x30
This happens because the loop variable still gets incremented by one so
max becomes 3 instead of 2, and this makes the second loop read past the
the array declared on the stack.
Fix this by assigning to max directly in the loop body. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix a UBSAN warning in DML2.1
When programming phantom pipe, since cursor_width is explicity set to 0,
this causes calculation logic to trigger overflow for an unsigned int
triggering the kernel's UBSAN check as below:
[ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34
[ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int'
[ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu
[ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024
[ 40.962856] Call Trace:
[ 40.962857] <TASK>
[ 40.962860] dump_stack_lvl+0x48/0x70
[ 40.962870] dump_stack+0x10/0x20
[ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360
[ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu]
[ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu]
[ 40.963327] ? srso_alias_return_thunk+0x5/0x7f
[ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu]
[ 40.963534] ? srso_alias_return_thunk+0x5/0x7f
[ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu]
[ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]
[ 40.963906] ? srso_alias_return_thunk+0x5/0x7f
[ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]
[ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu]
[ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu]
[ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu]
[ 40.964587] dml21_validate+0x274/0x770 [amdgpu]
[ 40.964761] ? srso_alias_return_thunk+0x5/0x7f
[ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu]
[ 40.964942] dml2_validate+0x504/0x750 [amdgpu]
[ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu]
[ 40.965291] ? srso_alias_return_thunk+0x5/0x7f
[ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu]
[ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu]
[ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu]
[ 40.965845] ? srso_alias_return_thunk+0x5/0x7f
[ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu]
Fix this by adding a guard for checking cursor width before triggering
the size calculation. |
| In the Linux kernel, the following vulnerability has been resolved:
vsock: Update rx_bytes on read_skb()
Make sure virtio_transport_inc_rx_pkt() and virtio_transport_dec_rx_pkt()
calls are balanced (i.e. virtio_vsock_sock::rx_bytes doesn't lie) after
vsock_transport::read_skb().
While here, also inform the peer that we've freed up space and it has more
credit.
Failing to update rx_bytes after packet is dequeued leads to a warning on
SOCK_STREAM recv():
[ 233.396654] rx_queue is empty, but rx_bytes is non-zero
[ 233.396702] WARNING: CPU: 11 PID: 40601 at net/vmw_vsock/virtio_transport_common.c:589 |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Fix out of bound check
Driver exports pacing stats only on GenP5 and P7 adapters. But while
parsing the pacing stats, driver has a check for "rdev->dbr_pacing". This
caused a trace when KASAN is enabled.
BUG: KASAN: slab-out-of-bounds in bnxt_re_get_hw_stats+0x2b6a/0x2e00 [bnxt_re]
Write of size 8 at addr ffff8885942a6340 by task modprobe/4809 |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Add the missing BPF_LINK_TYPE invocation for sockmap
There is an out-of-bounds read in bpf_link_show_fdinfo() for the sockmap
link fd. Fix it by adding the missing BPF_LINK_TYPE invocation for
sockmap link
Also add comments for bpf_link_type to prevent missing updates in the
future. |
| A vulnerability, which was classified as problematic, was found in mruby up to 3.4.0-rc2. Affected is the function scope_new of the file mrbgems/mruby-compiler/core/codegen.c of the component nregs Handler. The manipulation leads to heap-based buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The name of the patch is 1fdd96104180cc0fb5d3cb086b05ab6458911bb9. It is recommended to apply a patch to fix this issue. |
| Mattermost versions 10.8.x <= 10.8.3, 10.5.x <= 10.5.8, 9.11.x <= 9.11.17, 10.10.x <= 10.10.0, 10.9.x <= 10.9.3 fail to validate import data which allows a system admin to crash the server via the bulk import feature. |
| spimsimulator spim v9.1.24 and before is vulnerable to Buffer Overflow in READ_STRING_SYSCALL. |
| In the Linux kernel, the following vulnerability has been resolved:
usbnet: ipheth: fix possible overflow in DPE length check
Originally, it was possible for the DPE length check to overflow if
wDatagramIndex + wDatagramLength > U16_MAX. This could lead to an OoB
read.
Move the wDatagramIndex term to the other side of the inequality.
An existing condition ensures that wDatagramIndex < urb->actual_length. |
| In the Linux kernel, the following vulnerability has been resolved:
usbnet: ipheth: use static NDP16 location in URB
Original code allowed for the start of NDP16 to be anywhere within the
URB based on the `wNdpIndex` value in NTH16. Only the start position of
NDP16 was checked, so it was possible for even the fixed-length part
of NDP16 to extend past the end of URB, leading to an out-of-bounds
read.
On iOS devices, the NDP16 header always directly follows NTH16. Rely on
and check for this specific format.
This, along with NCM-specific minimal URB length check that already
exists, will ensure that the fixed-length part of NDP16 plus a set
amount of DPEs fit within the URB.
Note that this commit alone does not fully address the OoB read.
The limit on the amount of DPEs needs to be enforced separately. |
| In the Linux kernel, the following vulnerability has been resolved:
usbnet: ipheth: fix DPE OoB read
Fix an out-of-bounds DPE read, limit the number of processed DPEs to
the amount that fits into the fixed-size NDP16 header. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7925: fix off by one in mt7925_load_clc()
This comparison should be >= instead of > to prevent an out of bounds
read and write. |
| In the Linux kernel, the following vulnerability has been resolved:
rtc: tps6594: Fix integer overflow on 32bit systems
The problem is this multiply in tps6594_rtc_set_offset()
tmp = offset * TICKS_PER_HOUR;
The "tmp" variable is an s64 but "offset" is a long in the
(-277774)-277774 range. On 32bit systems a long can hold numbers up to
approximately two billion. The number of TICKS_PER_HOUR is really large,
(32768 * 3600) or roughly a hundred million. When you start multiplying
by a hundred million it doesn't take long to overflow the two billion
mark.
Probably the safest way to fix this is to change the type of
TICKS_PER_HOUR to long long because it's such a large number. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information
These four chips:
* W25N512GW
* W25N01GW
* W25N01JW
* W25N02JW
all require a single bit of ECC strength and thus feature an on-die
Hamming-like ECC engine. There is no point in filling a ->get_status()
callback for them because the main ECC status bytes are located in
standard places, and retrieving the number of bitflips in case of
corrected chunk is both useless and unsupported (if there are bitflips,
then there is 1 at most, so no need to query the chip for that).
Without this change, a kernel warning triggers every time a bit flips. |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: fix blksize < PAGE_SIZE for file-backed mounts
Adjust sb->s_blocksize{,_bits} directly for file-backed
mounts when the fs block size is smaller than PAGE_SIZE.
Previously, EROFS used sb_set_blocksize(), which caused
a panic if bdev-backed mounts is not used. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/CPU/AMD: Terminate the erratum_1386_microcode array
The erratum_1386_microcode array requires an empty entry at the end.
Otherwise x86_match_cpu_with_stepping() will continue iterate the array after
it ended.
Add an empty entry to erratum_1386_microcode to its end. |
| In the Linux kernel, the following vulnerability has been resolved:
riscv: kvm: Fix out-of-bounds array access
In kvm_riscv_vcpu_sbi_init() the entry->ext_idx can contain an
out-of-bound index. This is used as a special marker for the base
extensions, that cannot be disabled. However, when traversing the
extensions, that special marker is not checked prior indexing the
array.
Add an out-of-bounds check to the function. |
