nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations
When fuzzing the nvme target code, I tripped a kernel warning in
nvmet_tcp_map_data() because the length passed into the allocator is
controlled by the remote initiator.
A remote initiator that sends a command with an SGL claiming a huge
number, can create a scatterlist and iovec allocation of over 1 million
entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER
and then the page allocator will trip on a WARN_ON_ONCE_GFP() message:
WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_
fbdev: Wrap user-invoked calls to fb_set_var() in helper
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Wrap user-invoked calls to fb_set_var() in helper
Handle fbcon during display updates in fb_set_var_from_user(). Check
with fbcon if the mode change is possible, update hardware state and
finally update fbcon. Update all callers.
Only the FBIOPUT_VSCREENINFO ioctl currently does all steps. Other
mode-changes callers in sysfs and driver code are missing fbcon-related
steps.
With the new helper, ps3fb and sh_mobile_lcdcfb no longer maintain
fbcon state themselves.
fbdev: serialize mode sysfs access with lock_fb_info()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: serialize mode sysfs access with lock_fb_info()
show_mode(), show_modes(), and store_mode() access fb_info->modelist
and fb_info->mode without holding lock_fb_info(). store_modes() takes
lock_fb_info() while replacing the modelist and freeing the old one.
A concurrent reader or writer can load a pointer to an old modelist
entry before store_modes() frees it, then dereference freed memory or
store a stale freed pointer in fb_info->mode.
Take lock_fb_info() in show_mode(), show_modes(), and store_mode() to
serialize with store_modes(). In show_mode(), copy the mode t
HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()
In the Linux kernel, the following vulnerability has been resolved:
HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event()
magicmouse_raw_event() handles DOUBLE_REPORT_ID (0xf7) packets, which pack
two touch reports into one, by splitting the packet and calling itself on
each half. The only guard against runaway recursion is a "size < 1" check,
which stops zero-sized calls but does not bound the recursion depth.
A malicious HID device that matches this driver can send a report starting
with DOUBLE_REPORT_ID and filled with the sequence [0xf7, 0x00]. Each level
consumes two bytes and recurses on the remainder, so an incoming
HID: magicmouse: do not keep a stale msc->input if no input is claimed
In the Linux kernel, the following vulnerability has been resolved:
HID: magicmouse: do not keep a stale msc->input if no input is claimed
magicmouse_input_mapping() caches the first hid_input's input_dev in
msc->input while the report descriptor is parsed, and the rest of the
driver treats a non-NULL msc->input as proof that an input device was
registered.
That does not hold on the hid-input error path. If hidinput_connect()
fails -- for instance because input_register_device() returns an error --
it unwinds through hidinput_disconnect(), which frees every input_dev it
created, including the one cached in msc->input.
The failure does not
HID: core: fix OOB read of field->usage in hid_set_field()
In the Linux kernel, the following vulnerability has been resolved:
HID: core: fix OOB read of field->usage in hid_set_field()
hid_set_field() hands field->usage + offset to hid_dump_input() before
the guard that bounds offset:
hid_dump_input(field->report->device, field->usage + offset, value);
if (offset >= field->report_count) {
hid_err(...);
return -1;
}
Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with
buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is
allocated inline with the hid_field in hid_register_field() and holds
field->maxusage entries, so an offset past it reads off the end of the
k
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)
selinux: reject a class permission count below its inherited common
In the Linux kernel, the following vulnerability has been resolved:
selinux: reject a class permission count below its inherited common
security_get_permissions() maps an inherited common's permissions into
an array sized by the class's own permissions.nprim, but class_read()
takes that nprim verbatim from the policy image and never checks that it
covers the common. A class that inherits a common of N permissions while
declaring a smaller nprim is accepted, and on load the common's
permissions are written past the class-sized array -- an out-of-bounds
heap write.
Reject a class whose permission count is below its inherited common's.
Well-
selinux: reject a permission value exceeding the class permission count
In the Linux kernel, the following vulnerability has been resolved:
selinux: reject a permission value exceeding the class permission count
perm_read() bounds a permission value by SEL_VEC_MAX but never by the
nprim of the owning class or common, which is taken verbatim from the
policy image. security_get_permissions() then writes perms[value - 1]
into an nprim-sized kcalloc() array, so a class declaring fewer
permissions than its largest permission value drives an out-of-bounds
heap write. The top-level symbol tables are validated this way; the
nested per-class permission table is not.
Reject a permission whose value exceeds nprim, whic
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix F55 transmitter electrode count typo
During F55 sensor detection, the transmitter (TX) electrode count was
incorrectly assigned the value of the receiver (RX) electrode count
due to copy-paste typos.
This incorrect value was then propagated to the driver data and used
by F54 to determine the diagnostics report size. On devices with more
RX than TX electrodes, this inflated the perceived TX count, leading
to incorrect report size calculations and potential out-of-bounds
buffer accesses.
Fix the typos by correctly assigning the TX electrode count
In the Linux kernel, the following vulnerability has been resolved:
Input: psxpad-spi - set driver data before use
psxpad_spi_suspend() retrieves the controller state with
spi_get_drvdata(), but probe never stores it, so suspend dereferences a
NULL pointer. Store it during probe.
drm/amdkfd: Add bounds check for CRAT subtype length
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Add bounds check for CRAT subtype length
The CRAT parser validates that the subtype header fits within the image,
but does not verify that the advertised subtype length fits. A malformed
CRAT table with an oversized length field causes out-of-bounds reads when
kfd_parse_subtype() casts the header to specific subtype structures.
Add validation that sub_type_hdr + length does not exceed the image
boundary before parsing the subtype contents.
(cherry picked from commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d)
ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers
In the Linux kernel, the following vulnerability has been resolved:
ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers
The irq handlers take a struct device pointer and call
dev_get_drvdata() to obtain the driver data. However, the driver
data is only set at the end of probe, after devm_request_irq(),
so an interrupt taken in between causes the handlers to pass a
NULL pointer to readl() and crash.
Pass the private data directly as the devm_request_irq() argument
instead of the device pointer, matching what the handlers expect.
af_packet: Don't send zero-byte data in tpacket_snd().
In the Linux kernel, the following vulnerability has been resolved:
af_packet: Don't send zero-byte data in tpacket_snd().
syzbot reported a WARNING in __dev_queue_xmit() triggered via tpacket_snd():
skb_assert_len
WARNING: at include/linux/skbuff.h:2753 skb_assert_len
WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781
Call Trace:
<TASK>
dev_queue_xmit include/linux/netdevice.h:3448 [inline]
packet_xmit+0x243/0x310 net/packet/af_packet.c:276
tpacket_snd net/packet/af_packet.c:2907 [inline]
packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134
When sending 0-byte packets via TPACKET ring buffer on devices with no
hard
net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock
In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is
deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring
ESW devcom lock without condition. In addition, in case of peer_flow,
__mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock.
This results in an AA deadlock.
To fix this, introduce a new PEER flag that is set on flows created as
peer flows (the duplicate flows on peer devices), and check it in
mlx5e_tc_del_flow() before acquiring ESW devcom lock.
Lockdep splat:
bpf: Check sk_state before sk_protocol in bpf_tcp_*_syncookie
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check sk_state before sk_protocol in bpf_tcp_*_syncookie
bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie accept a socket pointer
'sk' with argument type ARG_PTR_TO_BTF_ID_SOCK_COMMON. However, they access
sk->sk_protocol without validating whether 'sk' represents a full socket.
Fix this issue by checking sk->sk_state != TCP_LISTEN before inspecting
sk->sk_protocol in both bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie.
Since mini-sockets are never in the TCP_LISTEN state, the condition
short-circuits and prevents dereferencing fullsock-specific fields.
In the Linux kernel, the following vulnerability has been resolved:
serial: amba-pl011: synchronize DMA teardown
dmaengine_terminate_all() does not wait for a running callback, so the TX
callback can still touch the TX buffer after it is freed. The RX poll
timer reads the RX buffers without the port lock.
Switch to dmaengine_terminate_sync() and delete the RX timer before
freeing the buffers.