HID: synchronize input before cleaning up a failed probe
In the Linux kernel, the following vulnerability has been resolved:
HID: synchronize input before cleaning up a failed probe
hid_device_io_start() allows reports to run concurrently with probe. If
the probe subsequently fails, __hid_device_probe() releases driver
resources and clears hdev->driver without first excluding those report
callbacks.
For example, a report may enter hidraw_report_event() while the failure
path frees the associated hidraw object, leading to a use-after-free when
the report takes the object's list lock.
Stop input before performing failed-probe cleanup. This reacquires
driver_input_lock and waits for any report cal
In the Linux kernel, the following vulnerability has been resolved:
HID: steam: Reject short reads
Steam Controller FEATURE reports encode the size of the message in the
message itself. Previously we were trusting that the size reported matched
the size we actually read, leading to a potential issue with short reads.
Instead, we should actually verify the length of the read.
Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht
phonet: pep: do not write beyond optlen in getsockopt
In the Linux kernel, the following vulnerability has been resolved:
phonet: pep: do not write beyond optlen in getsockopt
pep_getsockopt() clamps the reported length to the caller's buffer with
min_t(), but then stores the value with put_user(val, (int __user *)
optval), which always writes sizeof(int) bytes. A getsockopt() call with
an optlen smaller than sizeof(int) thus reports the clamped length yet
writes a full int, one to three bytes past the user buffer.
Write the value with copy_to_user() bounded by len, so at most optlen
bytes are copied, matching the length reported back to userspace.
blk-cgroup: fix race between policy activation and blkg destruction
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix race between policy activation and blkg destruction
When switching an IO scheduler on a block device, blkcg_activate_policy()
allocates blkg_policy_data (pd) for all blkgs attached to the queue.
However, blkcg_activate_policy() may race with concurrent blkcg deletion,
leading to use-after-free and memory leak issues.
The use-after-free occurs in the following race:
T1 (blkcg_activate_policy):
- Successfully allocates pd for blkg1 (loop0->queue, blkcgA)
- Fails to allocate pd for blkg2 (loop0->queue, blkcgB)
- Enters the enomem rollback path to releas
blk-cgroup: skip dying blkg in blkcg_activate_policy()
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: skip dying blkg in blkcg_activate_policy()
When switching IO schedulers on a block device, blkcg_activate_policy()
can race with concurrent blkcg deletion, leading to a use-after-free in
rcu_accelerate_cbs.
T1: T2:
blkg_destroy
kill(&blkg->refcnt) // blkg->refcnt=1->0
blkg_release // call_rcu(__blkg_release)
...
blkg_free_workfn
->
In the Linux kernel, the following vulnerability has been resolved:
ublk: check import_ubuf() return value
import_ubuf() can fail if the address range (provided by the userspace
ublk server) is outside the allowed user address space. Return that 0
bytes were copied if import_ubuf() fails rather than passing an
uninitialized struct iov_iter to ublk_copy_user_pages().
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
ocfs2/cluster: keep heartbeat local node stable
In the Linux kernel, the following vulnerability has been resolved:
ocfs2/cluster: keep heartbeat local node stable
o2nm_node_local_store() handles local=0 by stopping o2net and setting
cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set.
That stale state makes o2nm_this_node() return 255, blocks a later local=1
attempt with -EBUSY, and can feed 255 to heartbeat users that call
o2nm_this_node() dynamically.
Clearing cl_has_local is required when the local node is reset. But
heartbeat threads can still be running at that point. They pin the local
node config item at startup, yet o2hb_do_disk_heartbeat() and thread
tear
ocfs2: validate inline xattrs during inode block validation
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate inline xattrs during inode block validation
Patch series "ocfs2: validate xattr entry bounds", v7.
This series validates OCFS2 xattr entry name/value bounds when xattr
metadata is read and validated, before getxattr() or listxattr() can walk
out-of-range entry arrays or offsets from corrupted metadata.
This patch (of 2):
ocfs2_validate_inode_block() verifies a dinode before OCFS2 users walk
metadata from it, but inline xattr metadata is still checked only in
operation-specific consumers. The existing ibody lookup helper validates
inline header placement
ocfs2: validate external xattr entries when reading metadata
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate external xattr entries when reading metadata
ocfs2_validate_xattr_block() checks the xattr block header before the
block reaches higher-level xattr users, but it does not verify that a
non-indexed block's xh_count and entry offsets fit inside the block.
Indexed buckets likewise reach list/get consumers after ECC without an
entry-bounds check.
Use the flat xattr entry validator for non-indexed external xattr blocks,
and use a bucket-specific validator for indexed buckets at metadata read
time. The bucket validator keeps the entry array bounded by the first
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
rapidio: clear mport->net when rio_add_net() fails
In the Linux kernel, the following vulnerability has been resolved:
rapidio: clear mport->net when rio_add_net() fails
rio_alloc_net() stores the newly allocated rio_net in mport->net before
rio_scan_alloc_net() registers the device.
If rio_add_net() fails, rio_scan_alloc_net() drops the device reference
with put_device(), which releases the rio_net through the device release
callback. However, mport->net is left pointing at the freed object.
A later mport unregister path can then dereference the dangling mport->net
pointer and may try to free the same rio_net again.
Clear mport->net in the rio_add_net() failure path, matching the clean
Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht
fat: release buffer head after rebuilding parent
In the Linux kernel, the following vulnerability has been resolved:
fat: release buffer head after rebuilding parent
fat_scan_logstart() leaves the matching directory entry's buffer head in
sinfo.bh for the caller to release, just like fat_scan().
fat_rebuild_parent() uses the directory entry to rebuild the parent inode
for the nostale_ro NFS export path, but does not release sinfo.bh after a
successful scan. Release it once fat_build_inode() has consumed the
directory entry data.
bpf: Invalidate RCU pointers after final spin unlock
In the Linux kernel, the following vulnerability has been resolved:
bpf: Invalidate RCU pointers after final spin unlock
In a sleepable BPF program, a spin lock can provide the only RCU protection
for a kptr. The final bpf_spin_unlock() ends that protection, but the
verifier leaves the pointer valid. Another CPU can then free the object
before the pointer is used. A capability-limited runtime PoC triggered a
task_struct use-after-free in __bpf_get_task_stack().
Record whether the program is in an RCU-protected context before releasing
the lock. Invalidate RCU-protected pointers only when the unlock leaves the
final such context. This prese
In the Linux kernel, the following vulnerability has been resolved:
drm/omap: dsi: Do not copy isr table
To be able to unregister stuff from isrs, the corresponding table was
copied. Nobody seems to unregister stuff that way, so it does not help.
But there are stack-allocated objects passed to these isrs giving chances
of UAF of these objects if irqs are unregistered while they are handled,
so better do not copy that table.
Nicht bewertetEPSS 0,2%Keine Korrektur veröffentlicht
PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers
In the Linux kernel, the following vulnerability has been resolved:
PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers
Currently, the legacy I/O and memory sysfs handlers do not check
security_locked_down(LOCKDOWN_PCI_ACCESS), leaving the legacy_io and
legacy_mem files unprotected when the kernel is locked down.
Commit eb627e17727e ("PCI: Lock down BAR access when the kernel is locked
down") added the check to pci_write_config(), pci_mmap_resource(), and
pci_write_resource_io() to prevent userspace from programming DMA-capable
hardware that could be used to modify kernel code, but did not cover the
legacy handlers.
As a resu
Nicht bewertetEPSS 0,23%Keine Korrektur veröffentlicht
remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry()
table->offset[i] is a u32 from firmware, but was stored into a signed
int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes
before the table buffer. The subsequent avail check was bypassed
because the negative int was promoted to a large size_t in the
expression "table_sz - offset - sizeof(*hdr)", yielding a large positive
avail and letting the out-of-bounds hdr->type read proceed undetected.
Store the offset as u32 and validate it with unsigned comparisons before
any pointer arith
bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed
In the Linux kernel, the following vulnerability has been resolved:
bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed
A potential invalid storage access issue can occur after replacing a
cgroup bpf prog.
This occurs in the following scenario:
1. prog1 with storage is attached to a cgroup in multi-attach mode.
2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach
mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or
update_effective_progs).
3. A new prog3 is attached to the cgroup in multi-attach mode.
The reason is that __cgroup_bpf_attach overwrites pl->storage with the
new storage
Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht
thermal: hwmon: Remove hwmon class device along with its parent
In the Linux kernel, the following vulnerability has been resolved:
thermal: hwmon: Remove hwmon class device along with its parent
The current code creates one hwmon device per thermal zone type and that
device is registered under the first thermal zone of the given type.
That turns out to be problematic when the thermal zone holding the
hwmon device is removed.
For example, say that there are two ACPI thermal zones on a system
/sys/devices/virtual/thermal/thermal_zone0/
/sys/devices/virtual/thermal/thermal_zone1/
The current code registers a hwmon class device for thermal_zone0 only:
/sys/devices/virtual/thermal/thermal_zone0/hwmo
RDMA/erdma: Hold CQ references when processing EQ events
In the Linux kernel, the following vulnerability has been resolved:
RDMA/erdma: Hold CQ references when processing EQ events
EQ handlers look up CQs from dev->cq_xa and invoke CQ completion or
error callbacks outside the xarray lock. erdma_destroy_cq() can erase the
CQ from the xarray and free its queue buffer and doorbell record while a
previously scheduled EQ handler is still using the CQ.
Add a CQ refcount and take a reference under the xarray lock with
refcount_inc_not_zero(). Remove the CQ from the xarray before dropping
the destroy-path reference, then wait for in-flight EQ users before
releasing CQ resources.
RDMA/erdma: Hold QP references for AE and CM processing
In the Linux kernel, the following vulnerability has been resolved:
RDMA/erdma: Hold QP references for AE and CM processing
AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa
and then use or reference them outside the xarray lock.
erdma_destroy_qp() can drop the destroy-path reference and free QP
resources while such a lookup is in flight.
Add erdma_qp_get_by_qpn() to acquire a kref under the xarray
lock with kref_get_unless_zero(). Remove the QP from the xarray
before dropping the destroy-path reference so no new lookup can acquire
it while destruction waits for existing users.
Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht
RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: fix heap information leak on a truncated SRP_CRED_REQ
srp_recv_done() passes wc->byte_len to srp_process_rsp(). It passes
nothing to srp_process_cred_req() and srp_process_aer_req(), which read
fixed-size fields from the receive buffer without checking that those
fields were received.
The buffer size is max_ti_iu_len, which comes from the login response
and is not validated. A target that advertises 8 and then sends an
8-byte SRP_CRED_REQ makes the initiator read req->tag from beyond the
end of the buffer. req->tag is copied into the SRP_CRED_RSP and sent
back, s