| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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:
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:
io_uring: check for overflows in io_pin_pages
WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144
CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0
Call Trace:
<TASK>
__io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183
io_rings_map io_uring/io_uring.c:2611 [inline]
io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470
io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692
io_uring_setup io_uring/io_uring.c:3781 [inline]
...
</TASK>
io_pin_pages()'s uaddr parameter came directly from the user and can be
garbage. Don't just add size to it as it can overflow. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()
The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32
values that come from the user via the submit_lookup_cmds() function.
This addition could lead to an integer wrapping bug so use size_add()
to prevent that.
Patchwork: https://patchwork.freedesktop.org/patch/624696/ |
| In the Linux kernel, the following vulnerability has been resolved:
drm: zynqmp_dp: Fix integer overflow in zynqmp_dp_rate_get()
This patch fixes a potential integer overflow in the zynqmp_dp_rate_get()
The issue comes up when the expression
drm_dp_bw_code_to_link_rate(dp->test.bw_code) * 10000 is evaluated using 32-bit
Now the constant is a compatible 64-bit type.
Resolves coverity issues: CID 1636340 and CID 1635811 |
| In the Linux kernel, the following vulnerability has been resolved:
ima: Fix a potential integer overflow in ima_appraise_measurement
When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be
negative, which may cause the integer overflow problem. |
| In the Linux kernel, the following vulnerability has been resolved:
gpio: gpio-xilinx: Fix integer overflow
Current implementation is not able to configure more than 32 pins
due to incorrect data type. So type casting with unsigned long
to avoid it. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - add param check for RSA
Reject requests with a source buffer that is bigger than the size of the
key. This is to prevent a possible integer underflow that might happen
when copying the source scatterlist into a linear buffer. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix list protocols enumeration in the base protocol
While enumerating protocols implemented by the SCMI platform using
BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is
currently validated in an improper way since the check employs a sum
between unsigned integers that could overflow and cause the check itself
to be silently bypassed if the returned value 'loop_num_ret' is big
enough.
Fix the validation avoiding the addition. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Fix potential integer multiplication overflow errors
When multiplying of different types, an overflow is possible even when
storing the result in a larger type. This is because the conversion is
done after the multiplication. So arithmetic overflow and thus in
incorrect value is possible.
Correct an instance of this in the inter packet delay calculation. Fix by
ensuring one of the operands is u64 which will promote the other to u64 as
well ensuring no overflow. |
| In the Linux kernel, the following vulnerability has been resolved:
watchdog: rzg2l_wdt: Fix 32bit overflow issue
The value of timer_cycle_us can be 0 due to 32bit overflow.
For eg:- If we assign the counter value "0xfff" for computing
maxval.
This patch fixes this issue by appending ULL to 1024, so that
it is promoted to 64bit.
This patch also fixes the warning message, 'watchdog: Invalid min and
max timeout values, resetting to 0!'. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq()
The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds
access. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Prevent some integer underflows
My static checker complains that:
drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init()
warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'?
It appears that "info->dev->hmc_fpm_misc.max_ceqs" comes from the firmware
in irdma_sc_parse_fpm_query_buf() so, yes, there is a chance that it could
be zero. Even if we trust the firmware, it's easy enough to change the
condition just as a hardenning measure. |
| In the Linux kernel, the following vulnerability has been resolved:
udp: Fix multiple wraparounds of sk->sk_rmem_alloc.
__udp_enqueue_schedule_skb() has the following condition:
if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)
goto drop;
sk->sk_rcvbuf is initialised by net.core.rmem_default and later can
be configured by SO_RCVBUF, which is limited by net.core.rmem_max,
or SO_RCVBUFFORCE.
If we set INT_MAX to sk->sk_rcvbuf, the condition is always false
as sk->sk_rmem_alloc is also signed int.
Then, the size of the incoming skb is added to sk->sk_rmem_alloc
unconditionally.
This results in integer overflow (possibly multiple times) on
sk->sk_rmem_alloc and allows a single socket to have skb up to
net.core.udp_mem[1].
For example, if we set a large value to udp_mem[1] and INT_MAX to
sk->sk_rcvbuf and flood packets to the socket, we can see multiple
overflows:
# cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15
^- PAGE_SHIFT
# ss -uam
State Recv-Q ...
UNCONN -1757018048 ... <-- flipping the sign repeatedly
skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0)
Previously, we had a boundary check for INT_MAX, which was removed by
commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").
A complete fix would be to revert it and cap the right operand by
INT_MAX:
rmem = atomic_add_return(size, &sk->sk_rmem_alloc);
if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX))
goto uncharge_drop;
but we do not want to add the expensive atomic_add_return() back just
for the corner case.
Casting rmem to unsigned int prevents multiple wraparounds, but we still
allow a single wraparound.
# cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> 12
# ss -uam
State Recv-Q ...
UNCONN -2147482816 ... <-- INT_MAX + 831 bytes
skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947)
So, let's define rmem and rcvbuf as unsigned int and check skb->truesize
only when rcvbuf is large enough to lower the overflow possibility.
Note that we still have a small chance to see overflow if multiple skbs
to the same socket are processed on different core at the same time and
each size does not exceed the limit but the total size does.
Note also that we must ignore skb->truesize for a small buffer as
explained in commit 363dc73acacb ("udp: be less conservative with
sock rmem accounting"). |
| In the Linux kernel, the following vulnerability has been resolved:
cpufreq: CPPC: Add u64 casts to avoid overflowing
The fields of the _CPC object are unsigned 32-bits values.
To avoid overflows while using _CPC's values, add 'u64' casts. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: designware: use casting of u64 in clock multiplication to avoid overflow
In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow
by depending on the values of the given parameters including the ic_clk.
For example in our use case where ic_clk is larger than one million,
multiplication of ic_clk * 4700 will result in 32 bit overflow.
Add cast of u64 to the calculation to avoid multiplication overflow, and
use the corresponding define for divide. |
| In the Linux kernel, the following vulnerability has been resolved:
perf/x86/amd: fix potential integer overflow on shift of a int
The left shift of int 32 bit integer constant 1 is evaluated using 32 bit
arithmetic and then passed as a 64 bit function argument. In the case where
i is 32 or more this can lead to an overflow. Avoid this by shifting
using the BIT_ULL macro instead. |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: BPF: Fix off-by-one error in build_prologue()
Vincent reported that running BPF progs with tailcalls on LoongArch
causes kernel hard lockup. Debugging the issues shows that the JITed
image missing a jirl instruction at the end of the epilogue.
There are two passes in JIT compiling, the first pass set the flags and
the second pass generates JIT code based on those flags. With BPF progs
mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the
first pass and then generates N+1 insns in the second pass. This makes
epilogue_offset off by one and we will jump to some unexpected insn and
cause lockup. Fix this by inserting a nop insn. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Prevent integer overflow in hdr_first_de()
The "de_off" and "used" variables come from the disk so they both need to
check. The problem is that on 32bit systems if they're both greater than
UINT_MAX - 16 then the check does work as intended because of an integer
overflow. |
