platform/x86: lg-laptop: Fix LED resource handling
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: lg-laptop: Fix LED resource handling
The event notification callback might access kbd_backlight even
when it was not successfully registered with the LED subsystem.
The same happens inside acpi_remove(), where the LED devices are
unregistered unconditionally.
Fix this by tracking the availability of the kbd_backlight LED
device and use devm_led_classdev_register() to let devres take
care of unregistering the LED devices during removal. For this
the parent device of the LED devices is changed to the native
platform device.
bpf: Reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max
check_kfunc_args() detects a kfunc argument named rdonly_buf_size or
rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64,
and does not bound it. check_kfunc_call() later copies that value into
the returned register's mem_size field:
meta->r0_size = reg->var_off.value;
...
regs[BPF_REG_0].mem_size = meta.r0_size;
regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are set
gets truncated instead of causing a load-time rejection, so the verifier
records a PTR_TO_MEM regis
usb: gadget: uac: validate rate list length before storing
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: uac: validate rate list length before storing
UAC1 and UAC2 configfs rate-list attributes parse a comma-separated
list of sampling rates and store each parsed value in fixed-size arrays.
The arrays have UAC_MAX_RATES entries, but the store paths do not check
that the input contains at most that many tokens before writing through
opts->name##s[i++].
Writing more than ten rates therefore writes past the end of the
p_srates[] or c_srates[] array in struct f_uac1_opts or struct
f_uac2_opts.
With CONFIG_UBSAN_BOUNDS enabled, writing an 11-entry rate list to the
UA
usb: gadget: configfs: fix out-of-bounds read of qw_sign
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: configfs: fix out-of-bounds read of qw_sign
os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input
length to utf16s_to_utf8s(), but that argument counts UTF-16 code
units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[].
The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the
conversion reads up to 7 units (14 bytes) past the end of qw_sign[]
into the following members of struct gadget_info when the stored
signature fills the array without a NUL terminator, exposing those
bytes through the configfs attribute.
The store pat
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: aspeed_udc: check endpoint DMA allocation
ast_udc_probe() allocates a coherent DMA buffer used as the backing store
for endpoint buffers. ast_udc_init_ep() derives per-endpoint buffer
pointers from udc->ep0_buf, so a failed allocation is dereferenced during
probe.
Check the allocation before endpoint setup. The existing probe error path
called ast_udc_remove(), which unregisters the gadget unconditionally and
is not safe before usb_add_gadget_udc() succeeds. Add a local cleanup
helper for probe failures so pre-registration failures only unwind the
resources th
usb: fix UAF when probe runs concurrent to dyn ID removal
In the Linux kernel, the following vulnerability has been resolved:
usb: fix UAF when probe runs concurrent to dyn ID removal
Dynamic IDs are only guaranteed to be valid when usb_dynids_lock is held,
as remove_id_store can free the node. Thus, make a copy in
usb_probe_interface. Clarify the documentation that the id parameter is
only valid during the probe.
USB serial has the same pattern, but it does not need fixing as the IDs
cannot be removed via sysfs.
platform/x86: asus-wmi: fix resource leaks on probe failure
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: asus-wmi: fix resource leaks on probe failure
During driver initialization in asus_wmi_add(), various subsystems are
registered sequentially. However, the error path labels are out of order
relative to the registration sequence.
Specifically:
1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to
fail_custom_fan_curve. Because this label is placed below fail_sysfs,
it bypasses the cleanup calls for the input device and sysfs groups,
which were successfully registered before, leaking those resources.
2. If asus_screenpad_init() fails, the d
platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL
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 again
platform/surface: acpi-notify: Check ACPI companion before use
In the Linux kernel, the following vulnerability has been resolved:
platform/surface: acpi-notify: Check ACPI companion before use
Since 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(),
platform drivers that rely on the existence of a device's ACPI companion
object should verify its presence.
san_probe() dereferences the result of ACPI_COMPANION() when installing
the GSBUS address space handler, so force-binding the driver to a device
without an ACPI companion leads to a NULL pointer dereference. The
dereference was introduced when the probe function
RDMA/core: Wait for RCU callbacks before unloading ib_core
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Wait for RCU callbacks before unloading ib_core
put_gid_ndev() is queued with call_rcu() and implemented in ib_core.
Stopping the workqueues does not drain callbacks already queued, so RCU
could invoke it after the module code has been unloaded.
synchronize_rcu() does not wait for callbacks. Wait for them after all
producers have stopped.
RDMA/mlx5: Drain RCU callbacks during module teardown
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Drain RCU callbacks during module teardown
devx_free_subscription() can remain queued after the last DevX event file
drops its module reference or an auxiliary driver detaches its devices.
mlx5_ib can then unload before the callback runs.
Registration error unwind has the same risk because driver registration
can attach existing devices before failing. Wait after all drivers have
stopped.
RDMA/ipoib: Drain RCU callbacks during module teardown
In the Linux kernel, the following vulnerability has been resolved:
RDMA/ipoib: Drain RCU callbacks during module teardown
IPoIB reclamation completions can be signaled from inside an RCU callback.
Teardown can wake before the callback returns and unload ib_ipoib while its
code is still executing.
Client registration failure can also remove already-added devices and queue
callbacks. Wait after client and workqueue teardown.
esp: do not unref managed frag pages in esp_ssg_unref()
In the Linux kernel, the following vulnerability has been resolved:
esp: do not unref managed frag pages in esp_ssg_unref()
esp_ssg_unref() releases the page references held on the source
scatterlist after the AEAD operation completes. It calls
skb_page_unref() on every frag page for an out-of-place transform
(req->src != req->dst), and in the error path of esp_output_tail()
(already_unref == true) on the request's own scatterlist.
This is wrong when the skb carries managed frags
(SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf
and the skb does not hold a per-frag page reference; io_uring SEND_ZC
with a registered bu
RDMA/rvt: Return NULL after port allocation failure
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rvt: Return NULL after port allocation failure
rvt_alloc_device() deallocates the IB device when its port array cannot
be allocated but then returns the pointer to the released allocation.
Callers treat any non-NULL value as valid and dereference it, resulting
in a use-after-free.
Return NULL immediately after deallocation so callers can propagate the
allocation failure.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Preserve unit 0 on allocation failure
hfi1_free_devdata() assumes that the device was inserted into the unit
table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the
zero-initialized unit remains zero, so full cleanup can remove an
unrelated device from index 0.
Release only the rdmavt allocation and return immediately while the unit
table has not acquired the device.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Free RX data on late probe failure
hfi1_init_dd() allocates the shared AIP/VNIC RX support before returning.
If hfi1_init() or hfi1_register_ib_device() later fails, init_one() tears
down the device data without calling hfi1_free_rx(). This leaks netdev_rx
and its dummy netdev.
Free the RX support after IB unregistration and before postinit_cleanup(),
as done on normal device removal.
fs/resctrl: Prevent use-after-free in rdtgroup_kn_put()
In the Linux kernel, the following vulnerability has been resolved:
fs/resctrl: Prevent use-after-free in rdtgroup_kn_put()
A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that
need the structure to remain valid across a sleep (while waiting on acquiring
rdtgroup_mutex) take a reference with rdtgroup_kn_get() and release it with
rdtgroup_kn_put().
The release path is intended to serve as the fallback freer: if the count
drops to zero and the group has already been marked RDT_DELETED,
rdtgroup_kn_put() frees the structure.
The bulk teardown paths free_all_child_rdtgrp() and rmdir_all_sub() resulting
from a resctrl d
fs/resctrl: Fix UAF from worker threads when domains are removed
In the Linux kernel, the following vulnerability has been resolved:
fs/resctrl: Fix UAF from worker threads when domains are removed
The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters
and may sleep while doing so. They are scheduled via delayed_work embedded in
struct rdt_l3_mon_domain. Architecture allocates and frees these domains from
CPU hotplug callbacks under cpus_write_lock(), and the workers acquire
cpus_read_lock() to keep the domain alive across their access.
A use-after-free can occur when a worker is blocked waiting for
cpus_read_lock() while the hotplug core holds cpus_write_lock(): the
architecture f
rpmsg: glink: fix deadlock in endpoint destroy during driver detach
In the Linux kernel, the following vulnerability has been resolved:
rpmsg: glink: fix deadlock in endpoint destroy during driver detach
During driver detach, the device core holds the device mutex throughout
the driver's remove callback chain. When the rpmsg endpoint is
destroyed as part of that teardown, the GLINK endpoint destroy
implementation attempts to unregister the underlying rpmsg device.
That unregistration calls device_del(), which tries to re-acquire the
same device mutex already held higher up the stack, causing rmmod to
hang indefinitely.
The deadlock manifests with the following call chain:
[<0>] device_del+0x44/0x414 <-
hfsplus: validate thread record before delete key rebuild
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: validate thread record before delete key rebuild
hfsplus_delete_cat() is called with str == NULL when the last open
reference to an unlinked HFS+ hardlink backing inode is closed. In that
case, the function finds the catalog thread by CNID and rebuilds the
catalog key from thread.nodeName.
That reconstruction path reads thread.nodeName.length directly from the
catalog B-tree into fd.search_key and then copies length * 2 bytes into
fd.search_key->cat.name.unicode. It does not first check that the found
record is a thread record or that its size matches the thread n