| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
tty: skip cdev_del() when no cdev is registered
TTY device registration can fail before a cdev is allocated.
Serial core keeps the port so setserial can still use it, and later
removal passes the NULL cdev slot to cdev_del(), causing a NULL-pointer
dereference.
Only delete the cdev when the slot is not NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
Runtime PM must be enabled before creating the PHY, since phy_create()
only enables runtime PM on the PHY device if it is already enabled on
this parent device. However, the runtime PM callbacks dereference the
hsphy instance, which is not yet ready, leaving a window where a suspend
callback may trigger a NULL pointer dereference.
Take a runtime PM usage reference with pm_runtime_get_noresume() before
enabling runtime PM and release it once the PHY has been created, so that
no runtime suspend can run before the PHY is ready. This also prevents a
short window where an unnecessary runtime suspend can occur.
Use the devres-managed version to ensure PM runtime is symmetrically
disabled during driver removal for proper cleanup. |
| In the Linux kernel, the following vulnerability has been resolved:
md: recheck spare changes before starting sync
remove_spares() and remove_and_add_spares() modify the array's rdev
configuration. These operations are only safe after the array has been
suspended.
md_start_sync() checks whether spare configuration changes are needed
before taking reconfig_mutex. However, the rdev state can change before
the mutex is acquired, so the initial check can become stale. In that
case, md_choose_sync_action() may remove or replace rdevs while normal
I/O is still accessing them.
The race can occur as follows:
raid10d Worker Normal IO
____________ _______________________ ______________________
raid10_write_request()
wait_blocked_dev()
set Blocked
set Faulty
Skip Faulty rdev
rrdev->nr_pending++
.repl_bio = bio
removeable_rdev = false .
array not suspended .
lock mddev goto err_handle
lock mddev (wait)
.
update sb .
clear Blocked .
.
unlock mddev .
lock mddev (acquires)
remove_spares()
removeable_rdev = true
raid10_remove_disk()
rdev = replacement
replacement = NULL
rdev_dec_pending(NULL)
unlock mddev (NULL)->nr_pending--
In this case, rdev_dec_pending() is called with a NULL pointer,
resulting in a NULL pointer dereference when attempting to decrement
nr_pending.
Fix this by suspending the array when spare configuration changes are
needed, including for non-read-write arrays, and checking again after
taking reconfig_mutex. If the array was not already suspended and a
change is now needed, release the mutex, suspend the array, and
reacquire the mutex before continuing. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor: Unregister cpufreq notifier on init failure
acpi_processor_driver_init() registers the cpufreq policy notifier before
registering the ACPI processor driver and setting up CPU hotplug state.
If driver_register() or cpuhp_setup_state() fails, the error path only
unregisters the ACPI processor driver and the idle driver. The cpufreq
notifier remains registered even though initialization failed.
Mirror the module exit path on the init failure path and unregister the
cpufreq notifier when it has been registered. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_uac1_legacy: remove broken string configfs attributes
The UAC1_STR_ATTRIBUTE macro defines configfs show/store handlers for
the fn_play, fn_cap, and fn_cntl string options. The store function
contains an inverted null check on the kstrndup() return value.
This means every write attempt returns -ENOMEM on success and
dereferences a NULL pointer on allocation failure. The attributes
have been broken and unused for many years.
Remove the UAC1_STR_ATTRIBUTE macro and the three attributes it
generated. The internal defaults (FILE_PCM_PLAYBACK, FILE_PCM_CAPTURE,
FILE_CONTROL) set in f_audio_alloc_inst() are unaffected. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: Avoid NULL CQE dereference when reporting invalid tags
The single-doorbell completion path can call ufshcd_compl_one_cqe() with a
NULL CQE. If no command is associated with the completion tag, the warning
message dereferences the CQE while reporting the error. Avoid that
dereference and include the invalid tag in the warning. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized
tegra241_vintf_init_lvcmdq() stores the freshly allocated vcmdq pointer to
the vintf->lvcmdqs[] array, before tegra241_vcmdq_alloc_smmu_cmdq() builds
the vcmdq->cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ
error (e.g. one inherited across a kexec) firing in this window would make
tegra241_vintf0_handle_error() pass the still-zeroed arm_smmu_cmdq down to
__arm_smmu_cmdq_skip_err(), dereferencing NULL queue register pointers.
Drop the store from tegra241_vintf_init_lvcmdq() and publish the vcmdq at
the end of the allocation instead, with an smp_store_release() that pairs
with an smp_load_acquire() in the ISR, which can see a fully built LVCMDQ
or NULL.
The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq
once tegra241_vcmdq_hw_init_user() succeeds, using a plain store since a
user VINTF's lvcmdqs[] has no lockless reader -- the error ISR only walks
the VINTF0 array. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: use fsdata to track inline data write state and fix race
Instead of checking the live inode state (ext4_has_inline_data(inode)
and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the
write_end handlers, use the fsdata parameter of the address space
operations to explicitly pass down the state in which write_begin
prepared the write.
A concurrent thread (such as ext4_page_mkwrite()) can convert the
inline data to an extent between write_begin and write_end. If this
happens, the write_end handlers would previously miss the inline
write_end path and fall through to extent-based write_end logic.
However, since block buffers were never allocated in write_begin,
this resulted in NULL pointer dereferences or data loss because
folio_buffers(folio) was NULL.
Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating
fsdata as bitwise flags rather than mutually exclusive enums to keep
states of the write path independent. Communicate this state via
fsdata:
1) ext4_write_begin() and ext4_da_write_begin() set the
EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline
write is successfully prepared.
2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit
to safely handle VFS retries (where generic_perform_write() bypasses
the fsdata initialization on its retry jump).
3) The write_end handlers perform a bitwise AND to check if the
EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end
helper accordingly.
Furthermore, during a buffered write, ext4_write_inline_data_end()
acquires the xattr lock after preparing the write. If a concurrent
page fault (ext4_page_mkwrite()) converts the inline data to an extent
after the write_end handlers check the state but before
ext4_write_inline_data_end() acquires the xattr write lock, the
subsequent check will trigger a kernel panic via
BUG_ON(!ext4_has_inline_data(inode)).
To keep git history working and bisectability clean, replace the
BUG_ON check in ext4_write_inline_data_end() with a graceful error-
handling retry path in this same commit. If the inline data is cleared
after locking the xattr, we safely release all resources (releasing
iloc.bh, unlocking/putting the folio, stopping the active journal
transaction handle) and return 0 (VFS retry) to let the generic write
path retry the operation safely. |
| In the Linux kernel, the following vulnerability has been resolved:
cxl/features: Reject Set Features output buffer smaller than the header
cxlctl_set_feature() sizes its output buffer from the user's
fwctl_rpc.out_len but never checks it is large enough to hold even the
fwctl_rpc_cxl_out header. With out_len == 0 , kvzalloc() returns
ZERO_SIZE_PTR, which passes the !rpc_out check, the subsequent
rpc_out->size = 0 then writes through the poison pointer.
Reject requests whose output buffer can't hold the response header,
before allocating. The Set Feature reply carries no payload, so the
header is all that is required. |
| DBI versions before 1.653 for Perl load arbitrary modules via unvalidated dbm_type and dbm_mldbm attributes in DBD::DBM.
DBD::DBM passes the dbm_type and dbm_mldbm connect attributes to require without checking that the value names a module. require treats a path-shaped string as a literal filename and does not consult @INC, so the attribute chooses the file that Perl loads and runs.
The MLDBM::Serializer:: prefix that DBD::DBM prepends to dbm_mldbm is not a boundary: only the :: separators are rewritten to /, so a value containing / traverses out of the serializer directory. The value is also assigned to $MLDBM::Serializer, which MLDBM requires the same way when it ties the table.
A caller that lets an untrusted party influence either attribute, for example through a DSN fragment or a parameter that selects a storage backend, runs the file-scope code of whatever module the value names.
For example,
my $dsn = "dbi:DBM:f_dir=/var/db;dbm_type=../../Untrusted.pm"
my $dbh = DBI->connect( $dsn );
Note that DBD::Gofer forwards connect attributes to the server side, and DBI::ProxyServer checks only that a DSN starts with a driver prefix. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix undefined behavior in devid_write debugfs function
When for_each_pci_segment() loop completes without finding a matching
segment, the pci_seg pointer is not NULL but points to an invalid memory
location (the list head). Accessing pci_seg->id after the loop causes
undefined behavior.
Fix this by handling the successful case inside the loop and returning
-EINVAL after the loop if no matching segment is found. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to
acpi_device_hid(), which dereferences it, so force-binding the driver to
a device without an ACPI companion leads to a NULL pointer dereference.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
mlxbf-pmc driver and return -ENODEV when the companion is missing. |
| In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/rcar: Fix error checking in probe()
This code accidentally calls thermal_zone_device_enable() before checking
whether thermal_zone_device_register_with_trips() failed. Move the call
until later to avoid an error pointer dereference of "priv->zone".
The driver works differently depending on if we are using OF thermal or
not. We use thermal_add_hwmon_sysfs() if we are using OF thermal and
call thermal_zone_device_enable() if not. We can share same error check
for if either of these fail.
Moving the thermal_zone_device_enable() call is a bit cleaner as well.
The original code used a three step process to cleanup:
1. Call thermal_zone_device_unregister() to cleanup.
2. Set priv->zone to an error pointer to preserve the error code.
3. Set priv->zone to NULL to avoid a second call to
thermal_zone_device_unregister() in the rcar_thermal_remove()
function.
Now we can just do a direct goto error_unregister and rcar_thermal_remove()
handles the cleanup properly. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug
We miss a failed allocation check for pgdat->per_cpu_nodestats, which
results in a NULL deref when we offset into the per-cpu area.
Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing
at boot_nodestats so a later online can retry the allocation.
hotadd_init_pgdat() returns NULL on failure, which __try_online_node()
already maps to -ENOMEM.
On failure nothing needs to be unwound:
- the node is never marked online
- per_cpu_nodestats is left pointing at boot_nodestats
- __add_memory_resource() cleans up pending memblock resources
- later online attempts retry the per_cpu_nodestats allocation |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: asus-wireless: Fail probe when there is no ACPI match
Every platform driver can be forced to match a device that does not match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device ACPI companion
object need to verify its presence.
asus_wireless_probe() returns success when acpi_match_acpi_device()
finds no match, leaving behind an input device that never reports
anything because the notify handler is not installed. Worse, when the
driver is force-bound to a device without an ACPI companion, probe
still succeeds and stores a NULL companion pointer, which
asus_wireless_remove() later passes to acpi_dev_remove_notify_handler(),
leading to a NULL pointer dereference on unbind.
Return -ENODEV when the device does not match the ID table. This also
covers the missing-companion case, because acpi_match_acpi_device()
rejects a NULL device. Perform the check before allocating any driver
state, instead of after the input device has already been registered. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211_hwsim: avoid NULL skb in stop queue drain
mac80211_hwsim_stop() drops any frames left in data->pending. The loop
currently checks skb_queue_empty() and then dequeues separately.
That split is racy with TX status handling, which can remove a pending
frame under the queue lock. If the last entry is removed after the empty
check, skb_dequeue() returns NULL and the stop path passes that NULL skb
to ieee80211_free_txskb().
Use skb_dequeue() as the loop condition instead. The dequeue result is the
object that stop owns and frees, and a concurrent status completion that
empties the queue simply makes the loop terminate. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Publish channel state before callbacks
Transport setup can enable callbacks before the setup routine returns.
mailbox_chan_setup() registers the mailbox client with
mbox_request_channel(), and the mailbox controller startup path can enable
interrupt delivery before SCMI mailbox channel state has been published.
Similarly, smc_chan_setup() requests the optional A2P completion IRQ before
the SMC transport has made its cinfo pointer visible.
If a pending or spurious callback fires in those windows, the transport RX
callback can dereference a NULL transport cinfo pointer. Publishing only
the transport-private pointer is not sufficient either: an early callback
can enter the SCMI core before scmi_chan_setup() has assigned
cinfo->handle.
The core derives scmi_info from cinfo->handle in the RX path, so a NULL
handle can still fault even when the transport-private cinfo is valid.
Assign cinfo->handle before invoking the transport setup callback. Publish
the mailbox and SMC transport-private channel state before requesting the
mailbox channels or IRQ, and clear the early-published pointers again on
setup failure. Also unwind mailbox setup devres resources on failure so an
optional RX setup error that is ignored by the core does not leave stale
transport state behind. |
| In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-async: Unregister sub-device if asc_list is empty
When my em28xx USB device that uses the i2c tvp5150 driver is
disconnected, it crashes.
The cause is that the tvp5150 i2c module uses v4l2_async, but
the em28xx driver does not since it predates v4l2_async.
In that corner case sd->asc_list is empty, so
v4l2_async_unregister_subdev() never calls v4l2_device_unregister_subdev().
Modify the code so that, if sd->asc_list is empty,
v4l2_device_unregister_subdev() is still called. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Avoid reprocessing the current packet after the QP enters the error state
When do_complete() finds the QP in the error state it returns
RESPST_CHK_RESOURCE. Before commit 49dc9c1f0c7e ("RDMA/rxe: Cleanup
reset state handling in rxe_resp.c") this was the flush loop:
check_resource() had an error-state branch that fetched each remaining
recv WQE and completed it with IB_WC_WR_FLUSH_ERR, without touching
the current packet. That commit removed the error-state branch from
check_resource() (draining is now done at rxe_receiver() entry) but
kept the do_complete() error-state return.
As a result, when a QP moves to the error state while a packet is
being completed - e.g. an rdma_cm disconnect racing with receive
processing - the responder state machine loops back into the request
processing chain with the already-completed packet still in hand:
check_resource() fetches a fresh recv WQE, execute()/send_data_in()
copies the same packet payload again, do_complete() posts another
IB_WC_SUCCESS CQE (qp->resp.status is still 0), and control returns
to the error-state check. The loop re-executes the same packet once
per posted recv WQE (observed: ~1000 duplicate IB_WC_SUCCESS
completions of one SEND, one per ~8us, matching the RQ occupancy)
until the RQ is exhausted, after which qp->resp.wqe is NULL and
send_data_in() dereferences it:
BUG: kernel NULL pointer dereference, address: 0000000000000014
Workqueue: rxe_wq do_work
RIP: copy_data+0x29/0x1f0
Call Trace:
send_data_in+0x25/0x50
rxe_receiver+0xf36/0x1dd0
The duplicate completions are indistinguishable from real receives to
the ULP. During an rds stress test, the message was accepted as new and
delivered the same datagram to user space hundreds of times, corrupting
the stream; any ULP that relies on RC exactly-once delivery is affected.
A live packet reaching the error-state check in do_complete() has
been executed and completed exactly once and must be consumed, not
re-processed. Return RESPST_CLEANUP for it (dequeue and free); keep
returning RESPST_CHK_RESOURCE for the pkt == NULL case. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Fix NPD issue on partial unmap of an evicted BO
This commit fixes the NULL pointer dereference issue that would have
happened on the split of GPU mapping due to partial unmap of an evicted
BO. There is a logic to handle the partial unmap of huge pages when the
GPU mapping is split. That logic was not being completely skipped for
the VMA of an evicted BO and that resulted in a NPD possibility for the
'bo->backing.pages' pointer, which is set to NULL when pages of a
BO are released on eviction.
Following dump was seen when a partial unmap was exercised for an
evicted BO.
Unable to handle kernel paging request at virtual address 0000000000002000
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=00000008842e8000
[0000000000002000] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] SMP
<snip>
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : iova_mapped_as_huge_page+0x20/0x68 [panthor]
lr : panthor_gpuva_sm_step_remap+0x39c/0x498 [panthor]
sp : ffff800086193920
x29: ffff800086193920 x28: ffff800086193a18 x27: ffff800086193b80
x26: 0000000000400000 x25: 0000000000810000 x24: 0000000000400000
x23: ffff000808af1800 x22: 0000000000a00000 x21: ffff800086193a00
x20: ffff000806fd3f00 x19: 0000000000410000 x18: 00000000ffffffff
x17: 0000000000000000 x16: 0000000000000000 x15: ffff800083ce2d83
x14: 0000000000000000 x13: 3120646574636976 x12: 6520303030303138
x11: 2d30303030313420 x10: ffff8000836e6c80 x9 : ffff80007bfc889c
x8 : 3fffffffffffefff x7 : ffff8000836e6c80 x6 : 0000000000000000
x5 : ffff00097ef19088 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000010000 x1 : 0000000000000400 x0 : 0000000000000000
Call trace:
iova_mapped_as_huge_page+0x20/0x68 [panthor] (P)
op_remap_cb.isra.0+0x70/0xb0
__drm_gpuvm_sm_unmap+0xf8/0x1c0
drm_gpuvm_sm_unmap+0x40/0x60
panthor_vm_exec_op+0xa0/0x168 [panthor]
panthor_vm_bind_exec_sync_op+0x8c/0xb8 [panthor]
panthor_ioctl_vm_bind+0xbc/0x170 [panthor]
drm_ioctl_kernel+0xc0/0x140
drm_ioctl+0x20c/0x500
__arm64_sys_ioctl+0xb4/0x118
invoke_syscall+0x5c/0x120
el0_svc_common.constprop.0+0x48/0xf8
do_el0_svc+0x28/0x40
el0_svc+0x38/0x128
el0t_64_sync_handler+0xa0/0xe8
el0t_64_sync+0x198/0x1a0
Code: 8b030021 cb020021 f940b800 d34cfc21 (f8617801)
---[ end trace 0000000000000000 ]---
v2: Fix indentation |
