| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: reclaim forward-allocated memory on RX path errors
After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"),
errors in the receive path prior to queueing skbs into the receive
queue do not trigger forward-allocated memory reclaiming.
Prevent forward memory from growing unboundedly in pathological drop
scenarios by explicitly reclaiming memory when skbs are dropped. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: validate user buffer length in SNMP and ARP query ioctls
qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by
a user-supplied length (udata_len) without checking a lower bound, then
set udata_offset to a fixed non-zero value and pass both to a reply
callback. The callback bounds-checks the copy with
if ((udata_len - udata_offset) < len)
Both fields are u32, so a udata_len smaller than udata_offset makes the
subtraction wrap and the check pass, and the following memcpy() writes
past the allocation. A udata_len of 0 also yields ZERO_SIZE_PTR from
kzalloc(), which the existing NULL check does not catch.
Reject buffers smaller than udata_offset before allocating, so the
callback subtraction can no longer underflow. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Cancel existing workqueues
The initialization of the io_work and crw_work workqueues begs the
question of whether they should be un-initialized. Add the corresponding
cleanup tags in _release_dev to ensure work isn't dispatched after
the private struct is free'd. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Ensure index for read/write regions are within range
The introduction of the capability chain rightly clamped the
region indexes to the range of the capabilities itself, but
neglected to do so for the existing read/write regions which
should also be enforced. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Fix out of bounds check on CCW array
The routine ccwchain_calc_length() counts the number of channel
command words (CCWs) that are chained together in a single channel
program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs.
The loop itself is "do..while (count < 257)", and while the logic in
is_cpa_within_range() correctly adjusts between the 0-index array of
CCWs and the count of CCWs starting at 1, this means it would look
at a possible 257th CCW before ending the loop and (correctly)
returning an error.
Fix this by restructuring the loop to break as soon as 256 CCWs
(thus indexes 0-255) are examined, without looking at memory
outside the range. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Move cp cleanup out of not operational
The fsm_notoper() routine is called when the device has been
lost, and is (by definition) no longer operational. Since this
can happen asynchronously from the normal behavior of the
driver, the cleanup may happen when holding other locks
in the calling sequence (notably, the cio subchannel lock).
Push the cleanup of the private->cp resources to a workqueue,
where it can be done out from under that lock sequence and
a future patch can safely manage the locking requirements. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Selectively expand io_mutex
The io_mutex was defined to serialize the io_regions, but then has
also sort of been associated with the I/O themselves because of
the close relationship they share.
With the handful of races that are possible, the choices are either to:
A) expand the scope of io_mutex to close these remaining windows, or
B) reduce the scope of io_mutex to just io_region, and introduce a new
lock mechanism for the remaining I/O resources
This patch implements A, since B brings with it a lot more interactions
that would need to be tracked and kept in a correct hierarchy. It also
takes advantage of the workqueue element for cp_free() that now gets
called out of fsm_notoper(), which could be invoked out of an interrupt
context and thus cannot acquire a mutex itself. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Implement a crw lock
Unlike the channel_program struct, which covers synchronous I/O
submissions and asynchronous interrupts, the CRW region relies
exclusively on asynchronous events coming from hardware.
Implement a lock to manage the list of those payloads, to ensure
they are read cohesively. |
| In the Linux kernel, the following vulnerability has been resolved:
eth: bnxt: avoid deadlock when canceling IRQ affinity notifier
Unregistering IRQ affinity notifiers waits for the callback synchronously.
bnxt takes the netdev instance lock in the notifier (to restart the queue)
and cancels the work under the same lock. This may obviously deadlock.
Move the restart to the async service task. The queue restart isn't
super time sensitive. Store the new TPH tag, schedule the task.
Safely canceling the service task is already ironed out.
In bnxt_request_irq() the order of registering notifier, affinity and
initial TPH programming has to be inverted. I think it was racy
previously since user may trigger an update as soon as notifier
is installed.
There's a small known gap - if pcie_tph_get_cpu_st() fails at init
and the target tag is 0 we may miss programming the entry.
This does not seem worth fixing, the code has skip-on-failure
all over the place, anyway. |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: validate launch-time metadata size
Launch-time metadata extends beyond the first 16 bytes of struct
xsk_tx_metadata. Reject the request when the registered metadata area does
not contain the complete field.
Snapshot the validated flags for the generic transmit path and use that
snapshot for request and completion processing, avoiding inconsistent
decisions if user space changes the flags concurrently.
Note that only xsk_skb_metadata is properly using the flags,
__xsk_buff_get_metadata ignores them. Next commits address that. |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: validate metadata when processing requests
The zero-copy path validates TX metadata while obtaining the descriptor
context, then reads it again later when preparing the hardware request.
User space can change the metadata between those operations and bypass the
original validation.
Validate the metadata in xsk_tx_metadata_request() and use the resulting
flags snapshot for every feature check. Read request fields once so all
zero-copy drivers process only values observed after successful
validation. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: usx2y: bound the hwdep mmap fault offset
snd_us428ctls_vm_fault() turns the faulting page offset into a kernel
address with no bound of any kind:
offset = vmf->pgoff << PAGE_SHIFT;
vaddr = (char *)(...)->us428ctls_sharedmem + offset;
page = virt_to_page(vaddr);
get_page(page);
vmf->page = page;
return 0;
snd_us428ctls_mmap() checks only the length of the mapping, never the
offset, and us428ctls_sharedmem is a single page from
alloc_pages_exact(). For a character device file_mmap_size_max()
returns ULONG_MAX, so the mm layer imposes no ceiling either. Every page
offset above zero resolves to a struct page outside the object, and the
handler installs it into the caller's address space read-write; the vma
is not marked read-only.
The caller picks the page frame with a single mmap() argument and gets
read-write access to a page of kernel memory it does not own; an offset
that lands in an unpopulated vmemmap region oopses instead.
A process that can open the hwdep node of an attached US-X2Y reaches
this after loading the FPGA image through the same node; no capability
check is involved.
On 7.2.0-rc5 (arm64), mmap() with a large offset:
Unable to handle kernel paging request at virtual address fffffdffc45d5ac8
pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]
Call trace:
snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]
__do_fault
__handle_mm_fault
handle_mm_fault
el0_da
Reject any offset outside the shared region. The pcm hwdep handler in
usx2yhwdeppcm.c computes its address the same way and needs the same
bound.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: FCP: fix OOB write in fcp_meter_ctl_get()
fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size
by the driver's own limit of 255
if (map.map_size < 1 || map.map_size > 255 ||
map.meter_slots < 1 || map.meter_slots > 255)
return -EINVAL;
and passes it to fcp_add_new_ctl() as the control's channel count, where
it is stored as elem->channels.
Every control read writes into struct snd_ctl_elem_value, whose integer
array is declared long value[128], so the limit is 128, not 255.
fcp_meter_ctl_get() stores one 64-bit word per channel into that array
with no bound of its own:
for (i = 0; i < elem->channels; i++) {
int idx = private->meter_level_map[i];
int value = idx < 0 ? 0 : le32_to_cpu(resp[idx]);
ucontrol->value.integer.value[i] = value;
}
snd_ctl_elem_read_user() serves that object from
memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of
kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so
element i is written at byte 72 + 8 * i and element 144 already lands
past the allocation. At map_size 255 the last store ends at byte 2112,
888 bytes past the object and 64 bytes into the adjacent slab object.
The stored words come from the device and meter_level_map[] selects
which word lands in which slot, so extent and contents are both
controlled.
The core does not catch this. snd_ctl_check_elem_info() is reached only
from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under
CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a
compile-time true. __snd_ctl_add_replace() validates kcontrol->count and
never inspects elem->channels.
Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives
the hwdep descriptor that created it, so the out-of-bounds stores are
issued by any process able to read controls on /dev/snd/controlC0.
KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read:
BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get
Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185
__asan_store8
fcp_meter_ctl_get
snd_ctl_elem_read
snd_ctl_ioctl
Allocated by task 185:
memdup_user
snd_ctl_ioctl
The buggy address is located 0 bytes to the right of
allocated 1224-byte region [ffff000017af0000, ffff000017af04c8)
Bound the map size by the ABI limit rather than by 255, and bound the
store loop at the sink so it cannot run past the value array whatever
elem->channels holds.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: bitblit: bound-check glyph index in bit_cursor()
bit_cursor() fetches the glyph under the cursor with
c = scr_readw(vc_pos);
src = vc_font.data + ((c & charmask) * w * height);
where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer
value comes directly from scr_readw() and may be larger than the current
font's glyph count.
Syzkaller triggers this via vcs_write(). The Call Trace shows
vcs_write() in vc_screen.c writing an arbitrary 16-bit value with
writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via
vcs_scr_writew() without checking charcount. The stored value is later
read in bit_cursor() in bitblit.c.
When the font is changed from a font with 512 glyphs to a font with
256 glyphs, the screen buffer can retain characters with the high
bit set from the previous mode, which could also produce the same
out-of-bounds access.
BUG: KASAN: global-out-of-bounds in soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70
Read of size 16 at addr ffff800086c57970
Call Trace:
soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70
bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365
fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427
hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883
update_region+0x100/0x18c drivers/tty/vt/vt.c:669
vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685
bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph
index to vc_font.charcount. Apply the same clamp in bit_cursor() after
extracting the attribute and masking, before indexing fontdata.
The fix completes the bounds checking started in commit 18c4ef4e765a
("fbdev: bitblit: bound-check glyph index in bit_putcs*"), which missed
the cursor path.
This change should be safe because the clamp reuses the existing
contract from fbcon: charcount is maintained under console_lock in
con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when
switching from 512 to 256 glyphs. When stale screen data with high bits
remains after a font switch, or when vcs_write() stores an arbitrary
value, clamping the index to 0 prevents the out-of-bounds read without
changing cursor semantics — the same fallback bit_putcs uses. |
| In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent in6_dev_get() from resurrecting inet6_dev
in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally
increments its refcount. Device teardown can clear the pointer and drop
the last reference between these operations. The increment then
resurrects an object whose RCU free has already been queued, so callers
can use it after it is freed.
Use refcount_inc_not_zero() and return NULL when the object has already
reached zero. RCU keeps the memory accessible through the attempted
reference acquisition, and a successful increment pins the object for
the caller.
An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3)
kernel reproduced the invalid reference acquisition as UID 1000:
refcount_t: addition on 0; use-after-free.
ip6_mc_source+0xef4/0x17e0
It was followed by the corresponding reference underflow in
ip6_mc_source(). The supplied trace from the same unpatched revision
additionally shows the access after the RCU read-side section ends:
BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0
Write of size 8 at addr ffff888015b50240 by task poc/1219
Bug found and triaged by OpenAI Security Research and
validated by Trail of Bits. |
| In the Linux kernel, the following vulnerability has been resolved:
net/dibs: Correct freeing of dmb_clientid_arr
A dibs device interrupt handler can be active after dibs_dev_del() and
may still access dmb_clientid_arr. (UAF)
In case of a failure in dibs_dev_add() being called by dibs_lo_dev_probe()
dmb_clientid_arr is freed twice (double free).
Free dmb_clientid_arr in dibs_dev_release() after last reference is gone.
Note that allocating in dibs_dev_add() instead of dibs_dev_alloc() is ok
for now, because no dmbs can be registered before dibs_dev_add(). |
| In the Linux kernel, the following vulnerability has been resolved:
NTB: ntb_netdev: Preserve RX queue depth on allocation failure
ntb_netdev_rx_handler() hands the received skb to the network stack
before allocating its replacement. If the allocation fails, nothing is
reposted. Every failure therefore takes one buffer out of the RX queue
while the interface remains up, and enough failures eventually stall
reception.
A retry path could refill the queue later, but ntb_netdev has none.
Allocate the replacement first instead. If that fails, drop the packet
and repost the same skb. This keeps the queue full and lets packet
delivery resume as soon as memory is available again. |
| In the Linux kernel, the following vulnerability has been resolved:
dibs: initialise dibs->lock in dibs_dev_alloc()
dibs->lock is initialised by dibs_dev_add(), but a dibs device can
already take interrupts before that call: ism_probe() runs
ism_dev_init(), and hence request_irq(), before it calls
dibs_dev_add(). No client can have registered a dmb at that point, so
no dmb interrupt can occur, but a GID event interrupt can, and
ism_handle_irq() takes dibs->lock unconditionally on entry, before it
inspects anything else.
Initialise the lock in dibs_dev_alloc() instead, so that it is valid as
soon as a driver can publish the device to its interrupt handler. |
| In the Linux kernel, the following vulnerability has been resolved:
xdp: reject clones that overrun skb_shared_info tailroom
xdpf_clone() clones broadcast copies into a single page and sets
frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that
page like a normal XDP frame and expects the usual skb_shared_info
tailroom at the end of the buffer.
The current check only rejects frames whose linear xdp_frame header,
headroom, and packet data exceed PAGE_SIZE. A source frame backed by a
larger allocation can still satisfy that check while extending into the
clone's required shared-info area. When such a clone is converted back
into an skb, build_skb_around() places skb_shared_info over live packet
bytes and later writes can corrupt XDP return metadata.
Reject clones unless their linear area fits inside
SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already
enforced by the XDP-to-skb conversion path. |
| In the Linux kernel, the following vulnerability has been resolved:
vxlan: do not arm the ageing timer on a device that is down
vxlan_changelink() arms vxlan->age_timer whenever the requested ageing
interval differs from the configured one:
if (conf.age_interval != vxlan->cfg.age_interval)
mod_timer(&vxlan->age_timer, jiffies);
There is no netif_running() test, so the timer is armed even on a device
that was never brought up. The only synchronous cancel in the driver is
the timer_delete_sync() in vxlan_stop(), which is .ndo_stop.
netif_close_many() drops devices without IFF_UP before
__dev_close_many() runs, so that cancel is skipped for such a device.
vxlan_setup() sets dev->needs_free_netdev = true and age_timer is a
member of struct vxlan_dev, so free_netdev() releases the allocation the
timer lives in while it is still queued on a timer_base.
expire_timers() unlinks the entry before it loads timer->function, so
the timer core writes through the freed object's list pointers:
BUG: KASAN: slab-use-after-free in __run_timers+0x208/0x654
Write of size 8 at addr ffff00001adace68 by task true/192
__asan_store8+0x84/0xac
__run_timers+0x208/0x654
run_timer_softirq+0x154/0x18c
Allocated by task 189:
alloc_netdev_mqs+0x64/0x720
rtnl_create_link+0x4ac/0x520
rtnl_newlink+0x758/0xd00
Freed by task 191:
netdev_release+0x40/0x58
netdev_run_todo+0x4a4/0x8c0
rtnl_dellink+0x200/0x4e8
The rtnl operations involved are netns-scoped, so an unprivileged user
can perform them in a new user and network namespace.
Arming the timer on a down device never had an effect: vxlan_cleanup()
returns early on !netif_running(), and vxlan_open() arms the timer for
any non-zero interval once the device is brought up. Add the missing
test.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> |
