In the Linux kernel, the following vulnerability has been resolved:
futex/pi: Reject cross-mm private futex owners
A private futex key borrows the waiter's mm without taking an mm_users
reference. Nevertheless, attach_to_pi_owner() currently accepts an owner
from a different address space and copies the private key into the owner's
PI state.
When that owner exits, exit_pi_state_list() uses the saved key to find the
hash bucket and acquires a reference to the waiter's private hash. If the
last user of the waiter's mm exits concurrently, futex_hash_free() frees
the hash while the owner still uses its bucket and reference.
Prevent this by va
In the Linux kernel, the following vulnerability has been resolved:
futex/pi: Plug private futex exec() race
The check for private futexes whether the waiter's mm, which is stored in
the futex_key and copied into the pi_state, is the same as the owner's mm
is not sufficient for exec(). exec() has a gap where the mm check fails to
give the correct answer:
exec()
...
exec_release_mm()
futex_exec_release()
tsk::futex::exit_state = EXITING;
cleanup_robust_list();
1) tsk::futex::exit_state = OK;
...
old_mm = tsk::mm;
2) tsk::mm = ->mm;
Between #1 and #2 the check for the mm is wrong as that mm is abo
futex: Fix race in futex_pivot_pending() during private hash resize
In the Linux kernel, the following vulnerability has been resolved:
futex: Fix race in futex_pivot_pending() during private hash resize
A task performing a custom private hash resize can remain blocked in
uninterruptible sleep indefinitely. The hung-task detector reports:
INFO: task futex-resizer:314 blocked for more than 10 seconds.
task:futex-resizer state:D stack:14824 pid:314 tgid:312 ppid:311
Call Trace:
__schedule+0x521/0xf30
schedule+0x22/0xa0
futex_hash_allocate+0x3db/0x490
__do_sys_prctl+0x6f5/0xbd0
do_syscall_64+0xf9/0x530
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Kernel panic - not syncing: hung_task:
Nicht bewertetEPSS 0,18%Öffentlicher ExploitKorrektur verfügbar
futex: Fix race on the initial mm->futex.phash.ref allocation
In the Linux kernel, the following vulnerability has been resolved:
futex: Fix race on the initial mm->futex.phash.ref allocation
futex_hash_allocate() allocates mm->futex.phash.ref without any locking.
Commit d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()")
moved the allocation here and assumed that the process has just a single
thread at this point.
Commit ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private
default hash alloc") widened need_futex_hash_allocate_default() to cover
any CLONE_VM clone, but left out vfork because the parent is suspended and
cannot race.
That no longer holds once vfork is nested. I
In the Linux kernel, the following vulnerability has been resolved:
HID: asus: fix missing hid_is_usb() check
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the issue.
HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler()
In the Linux kernel, the following vulnerability has been resolved:
HID: nintendo: fix out-of-bounds read in joycon_ctlr_read_handler()
joycon_ctlr_read_handler() casts an incoming HID input report to
struct joycon_input_report and parses it, guarding the cast only with a
12-byte length check:
if (size >= 12) /* make sure it contains the input report */
joycon_parse_report(ctlr, (struct joycon_input_report *)data);
struct joycon_input_report is 49 bytes: a 13-byte header followed by a
union whose IMU arm is 36 bytes. For an IMU report joycon_parse_report()
-> joycon_parse_imu_report() walks that union (struct offsets 13..48),
so a repo
HID: nintendo: register input device after capabilities are set
In the Linux kernel, the following vulnerability has been resolved:
HID: nintendo: register input device after capabilities are set
input_register_device() exposes the device to userspace immediately.
In joycon_input_create() it was called before joycon_config_rumble()
configures the FF_RUMBLE capability and the memless force-feedback
device, so a concurrent EVIOCSFF could dereference a NULL dev->ff.
Registering early also means the initial udev event lacks button and
axis information, which can make input managers ignore the device.
Move input_register_device() to the end of joycon_input_create(), after
all capabilities, the IMU input de
HID: nintendo: stop device IO before hid_hw_stop on probe failure
In the Linux kernel, the following vulnerability has been resolved:
HID: nintendo: stop device IO before hid_hw_stop on probe failure
nintendo_hid_probe() calls hid_device_io_start() before joycon_init()
and joycon_leds_create(). If either fails, the error path jumps to
err_close which calls hid_hw_close()/hid_hw_stop() without first calling
hid_device_io_stop().
hid_hw_stop() does not stop device IO, so hid_input_report() may still
run and access driver data that is being torn down, resulting in a
use-after-free.
Add an err_io_stop label that calls hid_device_io_stop() before
hid_hw_close(), and point the two post-io_start error paths a
In the Linux kernel, the following vulnerability has been resolved:
HID: rapoo: fix missing hid_is_usb() check
to_usb_interface() can only be used on a hid_device whose parent is really
USB; uhid can create devices that identify as being on BUS_USB, but don't
actually have a USB parent.
Fix the use of to_usb_interface() without a hid_is_usb() check.
Add a dependency on USB_HID for hid_is_usb(), as other HID drivers do; the
alternative would be to provide a simple stub implementation on !USB_HID
builds.
I have verified that it is currently possible to trigger a kernel splat due
to this bug in an ASAN build, and that this commit fixes the i
HID: ft260: fix stack-use-after-return write in I2C read race
In the Linux kernel, the following vulnerability has been resolved:
HID: ft260: fix stack-use-after-return write in I2C read race
ft260_i2c_read() points dev->read_buf at a caller-supplied buffer
(often an on-stack variable), arms a completion and waits up to five
seconds for the device to return the data. The HID input callback
ft260_raw_event() runs in the input/IRQ path, independent of the
dev->lock mutex held by the read path, and copies the device-supplied
payload into dev->read_buf after a plain NULL check.
These two paths share read_buf, read_idx and read_len with no
serialization. If the device delays its response until the read
ti
HID: sensor: custom: Fix use-after-free in enable_sensor
In the Linux kernel, the following vulnerability has been resolved:
HID: sensor: custom: Fix use-after-free in enable_sensor
enable_sensor_store() can call set_power_report_state(), which
dereferences sensor_inst->power_state and sensor_inst->report_state.
These pointers refer to entries in sensor_inst->fields.
Create the field attributes before exposing the enable_sensor sysfs
attribute, so enable_sensor cannot be accessed before the state it
depends on has been initialized.
On remove, delete enable_sensor before freeing the field attributes,
so a concurrent sysfs write cannot dereference freed memory through
power_state or report_state.
HID: uclogic: fix use-after-free of inrange_timer on remove
In the Linux kernel, the following vulnerability has been resolved:
HID: uclogic: fix use-after-free of inrange_timer on remove
uclogic_remove() cancels the pen in-range timer and then stops the
device:
timer_delete_sync(&drvdata->inrange_timer);
hid_hw_stop(hdev);
timer_delete_sync() only guarantees the timer is idle at that instant.
uclogic_raw_event_pen() keeps delivering pen reports until hid_hw_stop()
stops the transport several lines later, and every report with
pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE re-arms the timer:
mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100));
A report landing between the tim
In the Linux kernel, the following vulnerability has been resolved:
HID: hyperv: validate initial device info bounds
The Hyper-V synthetic HID host supplies SYNTH_HID_INITIAL_DEVICE_INFO
messages that contain a HID descriptor followed by the report descriptor
bytes. mousevsc_on_receive_device_info() trusts bLength and
wDescriptorLength without checking that the received packet contains both
byte ranges.
A malformed host or backend message can therefore make the guest read
past the received VMBus packet while copying the report descriptor. Pass
the received initial-device-info size into the parser and reject
descriptor lengths that exceed t
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: fix LE list UAF on reset
hci_cc_reset() clears the LE accept and resolving lists without taking
hdev->lock. Other command-complete handlers serialize updates to these
lists with that lock, and the debugfs readers hold it while walking them.
This permits the reset completion and a debugfs read to interleave as
follows:
hci_rx_work debugfs reader
----------- --------------
lock hdev->lock
fetch current entry
list_del(entry)
kfree(entry)
Bluetooth: hci_event: validate LE Set CIG Parameters response
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: validate LE Set CIG Parameters response
The Command Complete dispatch validates only the fixed part of the LE Set
CIG Parameters response. After that part is pulled from the skb,
hci_cc_le_set_cig_params() trusts num_handles and reads each entry in the
trailing handle array.
Matching num_handles against the command's num_cis does not guarantee
that the response contains the advertised handles. A truncated response
from a malfunctioning controller can therefore make the handler read
beyond the skb data.
Validate that the remaining skb data contains al
Bluetooth: hci_sync: Fix accept list UAF during suspend
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: Fix accept list UAF during suspend
hci_update_event_filter_sync() walks hdev->accept_list while sending a
synchronous HCI command for each remote-wakeup device. The suspend path
holds hdev->req_lock, but accept-list updates are serialized by hdev->lock.
Consequently, remove_device() can free the current list entry during the
controller wait.
The following interleaving causes the use-after-free:
hci_update_event_filter_sync() remove_device()
fetch accept-list entry
hci_set_event_filter_sync()
wait for controller response hci_dev_lock()
Bluetooth: ISO: zero the sockaddr before returning it in getname
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: zero the sockaddr before returning it in getname
iso_sock_getname() fills a struct sockaddr_iso in place and returns its
size without clearing it first, so bytes it does not write are copied to
user space from the kernel stack. The getsockname(2) and getpeername(2)
paths both run through do_getsockname(), which hands getname() an
uninitialized sockaddr_storage on the stack and copies back up to the
number of bytes getname() returns, so the driver has to initialize every
byte it accounts for.
Two ranges are left uninitialized:
- struct sockaddr_iso is 10
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: reject HCI_CMD_SYNC params_len above 255
mgmt_hci_cmd_sync() checks that the message length agrees with params_len
but puts no upper bound on it. params_len is __le16 while the parameter
length in the HCI command header is a u8:
struct hci_command_hdr {
__le16 opcode;
__u8 plen;
} __packed;
hci_cmd_sync_alloc() assigns one to the other:
hdr->plen = plen;
if (plen)
skb_put_data(skb, param, plen);
so a params_len of 256 leaves plen at 0 while all 256 bytes are still
appended. The frame handed to the driver then declares no parameters and
carrie
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_aml: validate firmware segment lengths
aml_download_firmware() reads two lengths from the firmware header and
uses them to build pointers before checking that the header and segment
data are present. A truncated or inconsistent firmware image can make
the driver read past firmware->data while constructing TCI commands.
Reject images shorter than the header and ensure that the ICCM and DCCM
ranges fit within the loaded firmware before downloading either segment.
futex: Avoid private hash use-after-free on final put
In the Linux kernel, the following vulnerability has been resolved:
futex: Avoid private hash use-after-free on final put
futex_private_hash_put() drops the reference to fph before evaluating
fph->mm for wake_up_var(). futex_ref_put() enables preemption again before
returning. If that put drops the final reference and the task is preempted,
another task can pivot to the replacement hash and free the old hash after
an RCU grace period. The first task then reads fph->mm from the freed
allocation when it resumes.
KASAN reports a slab-use-after-free in futex_private_hash_put(), with the
read at offset 24 in a freed kmalloc-512 allocation. The