| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net: enetc: fix potential divide-by-zero when num_vsi is zero
For i.MX94 series, all the standalone ENETCs do not support SR-IOV, so
pf->caps.num_vsi is zero. This leads to a divide-by-zero in
enetc4_default_rings_allocation() when distributing rings among PF and
VFs.
Division by zero is undefined behavior in C. On ARM64, the UDIV/SDIV
instructions silently return zero rather than raising an exception, so
the issue does not cause a visible crash. However, relying on this
behavior is incorrect and poses a cross-platform compatibility risk.
Add an explicit check for num_vsi == 0 and return early after the PF's
rings have been configured. |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: reclaim forward-allocated memory on RX path errors
After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"),
errors in the receive path prior to queueing skbs into the receive
queue do not trigger forward-allocated memory reclaiming.
Prevent forward memory from growing unboundedly in pathological drop
scenarios by explicitly reclaiming memory when skbs are dropped. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when no RAS DES capability
dwc_pcie_rasdes_debugfs_init() returns success when the controller has no
RAS DES capability, leaving pci->debugfs->rasdes_info unset. The common
debugfs teardown path still calls dwc_pcie_rasdes_debugfs_deinit(), which
dereferences rasdes_info unconditionally.
Return early when no RAS DES state was allocated. In that case no RAS DES
mutex was initialized, so there is nothing to destroy.
[mani: reworded subject] |
| In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: Fix potential NULL pointer dereference
dasd_release_space() checks the implementation of the is_ese()
discipline function before calling it to determine if a given device is
an ESE DASD.
The current usage of the logical AND operator will lead to a NULL
pointer dereference as the function is called even if the function
pointer is NULL.
Fix this by using the logical OR operator. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: use proper context for logging
The same as the rest of the code, get_ss_info_from_atombios() uses
calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is
initialized only later in calc_pll_max_vco_construct(). Therefore, any
output using DC_LOG_SYNC() leads to a NULL pointer deference in
get_ss_info_from_atombios().
According to Sashiko, the very same problem exists in
dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too.
To avoid accessing the NULL context, use clk_src->base.ctx->logger
everywhere. That context in base is initialized earlier in
dce110_clk_src_construct() and dce112_clk_src_construct(). Before
get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions
above are actually called. This is done by redefining DC_LOGGER to
CTX->logger.
Before:
dce110_clk_src_construct() did:
-> sets clk_src->base.ctx = ctx;
-> ss_info_from_atombios_create()
-> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM
-> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx
After:
dce110_clk_src_construct() does:
-> sets clk_src->base.ctx = ctx;
-> ss_info_from_atombios_create()
-> get_ss_info_from_atombios() <- uses clk_src->base.ctx
(cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0) |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain
tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking
rcu_access_pointer(a->goto_chain) and then calling
tcf_action_goto_chain_exec(), which does a second, independent
rcu_dereference_bh(a->goto_chain) read and immediately dereferences
chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact
replace path) can clear a->goto_chain between the two reads, so the second
read returns NULL and tcf_action_goto_chain_exec() dereferences NULL.
Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain
in tcf_action_exec(), checking it once for NULL, and passing the resulting
chain pointer into tcf_action_goto_chain_exec(). This turns the split
check/use into a single check/use on one value. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: Pad trailing CCA or EP11 message with zeros
The both functions xcrb_msg_to_type6cprb_msgx() and
xcrb_msg_to_type6_ep11cprb_msgx() copy the user space message into a
kernel buffer based on the message length. But on further processing
the message is supposed to be 4 byte length adjusted. Thus up to 3
bytes of uninitialized kernel memory are forwarded to further
processing steps and may unwanted expose kernel memory to the crypto
card firmware.
This patch contains code to pad the gap between user space copied
message and message buffer length sent down to further processing of
the CCA or EP11 message to zeros. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: Improve EP11 CPRB domain handling with ASN.1 parsing
The zcrypt_msgtype6_send_ep11_cprb() function uses fragile struct
overlays to access and modify the domain field in the EP11 CPRB
payload, creating maintainability and security concerns:
1. Struct overlay approach (pld_hdr) assumes fixed payload structure
and doesn't validate the actual ASN.1 encoding.
2. Complex length format detection logic is error-prone and doesn't
properly validate bounds at each parsing step.
3. Direct struct member access bypasses proper ASN.1 validation.
Fix by replacing struct overlays with explicit ASN.1 parsing that
validates each field (payload tag/length, function tag/length/value,
optional domain tag/length/value) with proper bounds checking at every
step. Add asn1_int_encode() helper function to safely write integer
values with correct endianness conversion. This makes the code
consistent with the validation pattern introduced with the rework of
the xcrb_msg_to_type6_ep11cprb_msgx() function. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Selectively expand io_mutex
The io_mutex was defined to serialize the io_regions, but then has
also sort of been associated with the I/O themselves because of
the close relationship they share.
With the handful of races that are possible, the choices are either to:
A) expand the scope of io_mutex to close these remaining windows, or
B) reduce the scope of io_mutex to just io_region, and introduce a new
lock mechanism for the remaining I/O resources
This patch implements A, since B brings with it a lot more interactions
that would need to be tracked and kept in a correct hierarchy. It also
takes advantage of the workqueue element for cp_free() that now gets
called out of fsm_notoper(), which could be invoked out of an interrupt
context and thus cannot acquire a mutex itself. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Move cp cleanup out of not operational
The fsm_notoper() routine is called when the device has been
lost, and is (by definition) no longer operational. Since this
can happen asynchronously from the normal behavior of the
driver, the cleanup may happen when holding other locks
in the calling sequence (notably, the cio subchannel lock).
Push the cleanup of the private->cp resources to a workqueue,
where it can be done out from under that lock sequence and
a future patch can safely manage the locking requirements. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: ims-pcu - fix potential infinite loop in CDC union descriptor parsing
The driver parses CDC union descriptors in ims_pcu_get_cdc_union_desc()
by iterating through the extra descriptor data. However, it does not
verify that the bLength of each descriptor is at least 2. A malicious
device could provide a descriptor with bLength = 0, leading to an
infinite loop in the driver.
Add a check to ensure bLength is at least 2 before proceeding with
parsing. |
| In the Linux kernel, the following vulnerability has been resolved:
tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg
Sashiko found that user can cause this WARN_ON_ONCE() easily
with adding a kprobe event based on a raw address with BTF
parameter.
Since this is not an unexpected condition, remove the
WARN_ON_ONCE(). |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: revert ct extension genid infrastructure
This infrastructure is not used anymore after moving ct timeout and
helper to use datapath refcount to track object use.
Revert commit c56716c69ce1 ("netfilter: extensions: introduce extension
genid count") this patch disables all ct extensions (leading to NULL)
for unconfirmed conntracks, when this is only targeted at ct helper and
ct timeout. There is also codebase that dereferences the ct extension
without checking for NULL which could lead to crash. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()
Attempting to access driver data in the platform driver ->remove()
callback may lead to a null pointer dereference since there is no
guaranty that the component ->bind() callback invoking
platform_set_drvdata() was executed.
A common scenario is when Rockchip DRM driver didn't manage to run
component_bind_all() because of an (unrelated) error causing early
return from rockchip_drm_bind().
Drop the unnecessary call to platform_get_drvdata() and, instead,
reference the target device structure via platform_device. |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: ensure valid f_path for page cache sharing
Previously, backing files for page cache sharing were set up with
f_path left as NULL (only f_inode was valid). It worked, but a recent
mincore fix relies on f_path.mnt and crashes (found by "erofs/028" on
7.2-rc4):
BUG: kernel NULL pointer dereference, address: 0000000000000018
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 3 UID: 0 PID: 675528 Comm: fincore Not tainted 7.2.0-rc4-00002-g[]-dirty #1 PREEMPT(lazy)
Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014
RIP: 0010:__do_sys_mincore+0xc0/0x2c0
...
Specify valid paths using valid disconnected dentries together with
erofs_ishare_mnt instead of leaving f_path empty, so they are more
like real backing files in a pseudo filesystem and standard
backing_file_open() can be used directly. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue
Previously, rmi_f54_buffer_queue() waited for the worker thread to
finish but ignored whether it succeeded. If the worker failed (e.g.,
due to a timeout or register read failure), the queue thread would
silently return success, delivering stale or uninitialized memory to
userspace.
Add a 'report_error' field to struct f54_data to store the worker's exit
status. Check this field in rmi_f54_buffer_queue() after the worker
finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error
occurred. |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak
In papr_phy_attest_create_handle(), the params->cmd.length is not
validated before use, which can result in a buffer overlow. Check it and
return -EINVAL if it is either 0 or exceeds sizeof(params->cmd).
Also, params is freed on the success path but not error. Free it on
errors after memory allocation. And free it on negative fd. |
| In the Linux kernel, the following vulnerability has been resolved:
Input: cs40l50-vibra - validate custom data from user space
cs40l50_add() copies the custom data of an FF_PERIODIC/FF_CUSTOM effect
straight from the ff_effect the user passed to EVIOCSFF, without
requiring it to hold anything:
work_data.custom_data = memdup_array_user(periodic->custom_data,
periodic->custom_len,
sizeof(s16));
work_data.custom_len = periodic->custom_len;
The driver then reads two words out of that buffer: custom_data[0] as the
waveform bank in cs40l50_effect_bank_set(), and custom_data[1] as the
index within the bank in cs40l50_effect_index_set(). Neither read is
covered by a length check, and custom_len is fully user controlled:
- custom_len == 0 makes memdup_array_user() call memdup_user() with a
length of zero, which returns ZERO_SIZE_PTR rather than an error, so
custom_data[0] dereferences it.
- custom_len == 1 allocates two bytes. A bank of ROM or RAM keeps
effect->type out of the OWT case, and custom_data[1] is then read one
word past the allocation.
The bank value itself is also mishandled. It is masked with
CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in an s16, so a
custom_data[0] of 0x8000 or above wraps to a negative value that passes
the "bank_type >= CS40L50_WVFRM_BANK_NUM" test.
cs40l50_effect_index_set() indexes vib->dsp.banks[] with it before the
switch statement's default case gets a chance to reject it:
base_index = vib->dsp.banks[effect->type].base_index;
max_index = vib->dsp.banks[effect->type].max_index;
Require the two words the driver reads to be present, and hold the masked
bank in a u32 so the existing upper-bound test covers the whole range.
The da7280 haptic driver already range checks custom_len this way. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: clear fb_info->mode before deleting a videomode
fb_set_var() can delete a mode from info->modelist when userspace
passes FB_ACTIVATE_INV_MODE through FBIOPUT_VSCREENINFO. The code
checks that the mode being deleted is not the current info->var and
that fbcon is not using it, but it does not check fb_info->mode.
fb_info->mode may still point into the modelist entry being deleted.
If the entry is freed, later mode sysfs reads through show_mode() can
dereference a stale pointer.
Clear fb_info->mode before calling fb_delete_videomode() when it
matches the mode being removed. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/shmem_helper: Check VMA boundaries for PMD mappings
In the ->huge_fault handler do not install a PMD huge page
mapping if the huge page exceeds the boundaries of the VMA.
All other ->huge_fault handlers have similar checks and the
resulting mapping will trigger a VM_BUG_ON_VMA() if it ever
reaches copy_pmd_range(). |
