HID: alps: unregister DualPoint Stick input device on remove
In the Linux kernel, the following vulnerability has been resolved:
HID: alps: unregister DualPoint Stick input device on remove
alps_input_configured() allocates a second input device ("DualPoint
Stick") with input_allocate_device() and registers it, but the
alps_driver struct has no .remove handler and input2 is not tracked in
hdev->inputs. The default remove path (hid_hw_stop -> hidinput_disconnect)
only iterates hdev->inputs, so input2 is never unregistered and leaks
on every device removal.
Add a .remove handler that stops the device first (preventing URB
callbacks from touching input2 during teardown) and then unregisters
input2.
HID: alps: fix use-after-free on input2 registration failure
In the Linux kernel, the following vulnerability has been resolved:
HID: alps: fix use-after-free on input2 registration failure
alps_input_configured() stores data->input2 before calling
input_register_device(). If registration fails, input_free_device()
frees the input device but data->input2 still points to the freed memory.
alps_input_configured() calls hid_hw_open() before allocating input2, so
URBs are already active and raw_event can fire during the failure window.
A U1_SP_ABSOLUTE_REPORT_ID report arriving then causes u1_raw_event()
to dereference the freed data->input2 -> use-after-free.
Fix by only storing input2 into drvdata af
HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()
In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: fix OOB read in wacom_wac_pen_serial_enforce()
The 'wacom_wac_pen_serial_enforce()' function may calculate and pass an
invalid offset to hid_field_extract(), resulting in memory reads at
incorrect addresses -- possibly beyond the end of the report. If a
field in the HID descriptor lists more usages than its Report Count
actually reserves space for, the function's inner 'j' will walk past
the end of the field:
for (i = 0; i < report->maxfield; i++) {
for (j = 0; j < report->field[i]->maxusage; j++) {
...
value = hid_field_extract(hdev, raw_data + 1,
net/mlx5: Fix rev_entry reference leak in mlx5_tc_ct_shared_counter_get()
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix rev_entry reference leak in mlx5_tc_ct_shared_counter_get()
When the reverse entry is found but its counter is already being
released, refcount_inc_not_zero() fails and the reference taken by
mlx5_tc_ct_entry_get() is never dropped before falling through to
create_counter. Drop it so the reverse entry is not kept alive forever
by a shared counter lookup that did not use it.
In the Linux kernel, the following vulnerability has been resolved:
net: arp: terminate device name before lookup
The ARP ioctl copies a user-provided struct arpreq into a stack object. Its
arp_dev field may contain IFNAMSIZ bytes without a NUL terminator.
Such input is passed to dev_get_by_name_rcu() or __dev_get_by_name(), where
strcmp() can read past the end of the stack object when a matching
alternative interface name exists.
Terminate the field before the lookup to prevent the out-of-bounds read.
net: atl1: fix soft lockup on out-of-range cmb_tpd_next_to_clean read
In the Linux kernel, the following vulnerability has been resolved:
net: atl1: fix soft lockup on out-of-range cmb_tpd_next_to_clean read
Same issue as atl1c (see the first commit in this series, "net:
atl1c: fix soft lockup on out-of-range tpd_cons read"): the hardware
can report an out-of-range cmb_tpd_next_to_clean (seen as 0xffff)
while the PCIe link/MAC is resetting. An out-of-range value can
never be reached and the loop below would spin forever. Treat it as
"nothing new to clean" instead.
In the Linux kernel, the following vulnerability has been resolved:
net: ipconfig: bound DHCP option construction
ic_dhcp_init_options() appends the hostname (option 12), vendor-class
(option 60) and client-ID (option 61) options into the fixed 312-byte
bootp_pkt.exten[] buffer. Only the client-ID branch checked the
remaining space; the hostname and vendor-class writes were unbounded.
A 64-byte hostname together with the maximum 252-byte dhcpclass=
identifier needs 18 + (2 + 64) + (2 + 252) = 338 of the 312 available
bytes even before the terminating END marker, so the vendor-class memcpy
runs past the end of exten[]. With CONFIG_FORTIFY
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: conntrack: avoid modifying shared unconfirmed ct entry
In a case where skb with an unconfirmed ct entry gets cloned, we may
end up committing both but with different sets of extensions.
The series of events:
1. The first clone wants to commit and runs the helpers wiring up
the extension pointer into the expectation list.
2. Then it looses the confirmation keeping the entry unconfirmed.
3. Second clone now wants to commit labels and adds the new extension
for that breaking the pointer in the expectation list causing
UAF on the destruction p
net: openvswitch: conntrack: fix helper UAF due to extensions realloc
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: conntrack: fix helper UAF due to extensions realloc
While calling the helpers, a raw pointer to the extensions area is
wired into expectations list:
-> nf_ct_helper()
-> helper->help()
-> nf_ct_expect_related_report()
-> nf_ct_expect_insert()
-> hlist_add_head_rcu(&exp->lnode, &master_help->expectations)
In case the connection is not confirmed yet, more extensions can be
added afterwards with *_ext_add() calls reallocating the extension
space and leaving the now invalid pointer in the expectations list
that is later accessed while rem
net: atl1c: fix soft lockup on out-of-range tpd_cons read
In the Linux kernel, the following vulnerability has been resolved:
net: atl1c: fix soft lockup on out-of-range tpd_cons read
The hardware can report an out-of-range tpd_cons (seen as 0xffff)
while the PCIe link/MAC is resetting. An out-of-range value can
never be reached and the loop below would spin forever. To avoid
a soft lockup treat it as "nothing new to clean" instead.
Reproduced on two machines, same NIC (Qualcomm Atheros AR8151 v2.0,
4-port), triggered by rebooting a Mikrotik CCR2004 PCIe card that
the ports are directly linked to:
- Ubuntu 26.04.1 LTS, kernel 7.0.0-31-generic. The link-flap
precursor, before the lockup was cap
net: atl1e: fix soft lockup on out-of-range hw_next_to_clean read
In the Linux kernel, the following vulnerability has been resolved:
net: atl1e: fix soft lockup on out-of-range hw_next_to_clean read
Same issue as atl1c (see the first commit in this series, "net:
atl1c: fix soft lockup on out-of-range tpd_cons read"): the hardware
can report an out-of-range hw_next_to_clean (seen as 0xffff) while
the PCIe link/MAC is resetting. An out-of-range value can never be
reached and the loop below would spin forever. Treat it as "nothing
new to clean" instead.
net: bridge: mdb: restart port group walk after deletion
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mdb: restart port group walk after deletion
br_mdb_flush_pgs() keeps a pointer-to-pointer cursor while walking
mp->ports. br_multicast_del_pg() can re-enter the same MDB entry through
br_multicast_sg_del_exclude_ports() and unlink other port groups. If the
cursor points into one of those groups, the next iteration dereferences a
stale cursor and can leave mp->ports pointing at freed memory.
A following RTM_GETMDB exposes the dangling pointer:
BUG: KASAN: slab-use-after-free in br_mdb_dump
Read of size 8
br_mdb_dump
rtnl_mdb_dump
rtnl_dumpit
net: ena: fix MMIO read buffer leak on probe failure
In the Linux kernel, the following vulnerability has been resolved:
net: ena: fix MMIO read buffer leak on probe failure
ena_device_init() initializes the MMIO read mechanism with
ena_com_mmio_reg_read_request_init(), which allocates a coherent DMA
buffer for MMIO read responses.
The normal removal path releases this buffer through
ena_com_mmio_reg_read_request_destroy(). However, if ena_probe() fails
after ena_device_init() succeeds, the error path destroys the admin
resources and eventually frees ena_dev without destroying the MMIO read
request, leaving the coherent DMA buffer allocated.
Call ena_com_mmio_reg_read_request_destroy() in t
netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ip6t_rt: fix zero-address non-strict match out-of-bounds read
rt_mt6_check() permits rules to be configured with rtinfo->addrnr == 0
even when address matching (IP6T_RT_FST_MASK) is requested.
In the IP6T_RT_FST_NSTRICT path, rt_mt6() evaluates packet routing
addresses against rtinfo->addrs[i] and terminates backwards at the bottom
of the loop:
if (ipv6_addr_equal(ap, &rtinfo->addrs[i])) {
i++;
}
if (i == rtinfo->addrnr)
break;
When addrnr is 0, if the first packet address matches rtinfo->addrs[0],
i is incremented to 1. Because i i
netfilter: nf_tables: skip expired catchall elements on insert and delete
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: skip expired catchall elements on insert and delete
nft_setelem_catchall_insert() looks up duplicates with
nft_set_elem_active() only, while nft_set_catchall_lookup() and the
dump path additionally skip expired elements.
Once a catchall element with a timeout expires, this predicate drift
makes it invisible to userspace dumps, yet it still blocks
re-insertion: with NLM_F_EXCL the request fails with -EEXIST, and
without it the request reports success but silently inserts nothing.
The stale entry only goes away when the (user-tunable) gc interval
elapse
nfc: fix use-after-free in nfc_get_local_general_bytes
In the Linux kernel, the following vulnerability has been resolved:
nfc: fix use-after-free in nfc_get_local_general_bytes
Commit 6709d4b7bc2e ("net: nfc: Fix use-after-free caused by
nfc_llcp_find_local") attempted to fix a use-after-free (UAF) issue by
invoking nfc_llcp_local_put(local) after accessing local->gb. However,
if the reference count drops to zero, local is freed immediately,
leading to a use-after-free when callers access the returned pointer.
Alternative approaches using dynamic allocation (e.g. kmemdup) introduced
memory leaks because callers consistently treat the returned pointer as
borrowed memory.
Fix this properly by r
nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()
nfc_llcp_recv_hdlc() reads the sequence byte skb->data[2], via
nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path
only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it
with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs
-- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb
tailroom. The byte becomes N(R)/N(S); a peer can already set those with
a well-formed PDU, so this is acting on uninitialised memory, not new
peer control.
Guard the r
nfc: port100: reject frames whose declared length exceeds the received data
In the Linux kernel, the following vulnerability has been resolved:
nfc: port100: reject frames whose declared length exceeds the received data
port100_recv_response() passes the URB transfer buffer to
port100_rx_frame_is_valid(), which checksums le16_to_cpu(frame->datalen)
bytes of frame->data. datalen is a 16-bit field supplied by the device
and is never checked against the number of bytes actually received
(urb->actual_length), so a device reporting a datalen larger than the
received frame makes port100_data_checksum() read out of bounds past the
transfer buffer.
Reject a response whose declared frame size does not fit the received
leng
scsi: libiscsi_tcp: Check the data direction of a Data-In PDU
In the Linux kernel, the following vulnerability has been resolved:
scsi: libiscsi_tcp: Check the data direction of a Data-In PDU
The Data-In branch of iscsi_tcp_hdr_dissect() resolves the ITT to a task
and copies the PDU's data segment into that command's scatterlist without
asking whether the command was reading. iscsi_tcp_r2t_rsp() in the same
file does ask, and rejects an R2T for a command that is not DMA_TO_DEVICE.
A target that answers a WRITE command's ITT with a Data-In therefore has
the initiator write target-supplied bytes into the pages that write was
about to send. Those are the caller's own pinned pages for an O_DIRECT
write,
perf/core: Fix NULL pmu_ctx passed to pmu->sched_task()
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix NULL pmu_ctx passed to pmu->sched_task()
perf_pmu_sched_task() returns early when cpuctx->task_ctx is set, and
cpc->task_epc is only non-NULL while a task context is scheduled in on
this CPU. __perf_pmu_sched_task() therefore always passes NULL:
Unable to handle kernel NULL pointer dereference at virtual address 00
pc : armv8pmu_sched_task+0x14/0x50
Call trace:
armv8pmu_sched_task+0x14/0x50 (P)
perf_pmu_sched_task+0xac/0x108
__perf_event_task_sched_out+0x6c/0xe0
Pass &cpc->epc instead, the CPU-wide context for this PMU, which the
function alr