| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline
In the unregister path we use __in_uprobe_trampoline check with
current->mm for the VMA lookup, which is wrong, because we are
in the tracer context, not the traced process.
Add mm_struct pointer argument to __in_uprobe_trampoline and
changing related callers to pass proper mm_struct pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays
Currently defined VF/PF relay actions use regular REQUEST messages
only and the PF shouldn't attempt to handle FAST_REQUEST nor EVENT
messages as this would result in breaking the VFPF ABI protocol
and also might trigger an assert on the PF side.
(cherry picked from commit 1714d360fc5ae2e0886a69e979095d9c7ff3568a) |
| In the Linux kernel, the following vulnerability has been resolved:
cachefiles: Fix double unlock in nomem_d_alloc error path
When start_creating() fails and returns -ENOMEM, it has already
released the parent directory lock in __start_dirop():
static struct dentry *__start_dirop(...)
{
...
inode_lock_nested(dir, I_MUTEX_PARENT);
dentry = lookup_one_qstr_excl(name, parent, lookup_flags);
if (IS_ERR(dentry))
inode_unlock(dir); <-- Lock released on error
return dentry;
}
However, the nomem_d_alloc error path in cachefiles_get_directory()
unconditionally calls inode_unlock(d_inode(dir)) again, causing a
double unlock that corrupts the rwsem state.
This is a leftover from commit 7ab96df840e60 which replaced manual
locking with start_creating() but failed to update the nomem_d_alloc
path (while correctly updating mkdir_error and lookup_error paths). |
| In the Linux kernel, the following vulnerability has been resolved:
minix: avoid overflow in bitmap block count calculation
minix_check_superblock() uses minix_blocks_needed() to verify that the
on-disk imap and zmap block counts are large enough for the advertised
inode and zone counts.
The helper currently performs DIV_ROUND_UP() in unsigned int arithmetic.
A Minix v3 image can set s_ninodes or s_zones near UINT_MAX so the
addition inside DIV_ROUND_UP() wraps to zero. That makes a zero imap/zmap
block count look valid, after which minix_fill_super() can dereference
s_imap[0] or s_zmap[0] even though no bitmap buffers were allocated.
Impact: mounting a crafted Minix v3 image whose s_ninodes or s_zones is
near UINT_MAX makes minix_check_superblock() accept a zero bitmap-block
count and minix_fill_super() dereference s_imap[0]/s_zmap[0], panicking
the kernel.
The divisor is the bitmap capacity in bits, blocksize * 8, which is
always a power of two: minix_fill_super() obtains the block size through
sb_set_blocksize(), and blk_validate_block_size() rejects any size that
is not a power of two. Use DIV_ROUND_UP_POW2(), which divides before
adding the round-up term and so cannot overflow for a power-of-two
divisor. |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus) Fix passing events to regulator core
Sashiko reports:
Commit 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with
mutex") introduced a worker to batch regulator events over time using
atomic_or(). The delayed worker then passes the combined bitmask unmodified
to regulator_notifier_call_chain().
The core regulator subsystem's regulator_handle_critical() function
evaluates the event parameter using a strict switch statement. If
multiple distinct faults occur before the worker runs (e.g.,
REGULATOR_EVENT_UNDER_VOLTAGE | REGULATOR_EVENT_OVER_CURRENT), the combined
bitmask fails to match any case. This leaves the reason as NULL and
completely bypasses the critical hw_protection_trigger().
Fix the problem by passing events bit by bit to the regulator event
handler. |
| In the Linux kernel, the following vulnerability has been resolved:
irqchip/ts4800: Fix missing chained handler cleanup on remove
The driver installs a chained handler for the parent interrupt during probe
using irq_set_chained_handler_and_data(), but the remove function does not
clear this handler. This leaves a dangling handler that may be called when
the parent interrupt fires after the driver has been removed, potentially
accessing freed memory and causing a kernel crash.
Additionally, the parent_irq obtained via irq_of_parse_and_map() is not
stored, making it inaccessible in the remove function. Moreover, interrupt
mappings created during probe are not properly disposed.
Fix this by:
- Saving parent_irq in probe
- Clearing the chained handler with NULL in ts4800_ic_remove()
- Disposing all IRQ mappings before domain removal to prevent resource
leaks |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF
The teql master->slaves singly linked list is not protected against
multiple writes. It can be mod'ed concurently from teql_master_xmit(),
teql_dequeue(), teql_init() and teql_destroy() without holding any list
lock or RCU protection.
zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed
after an RCU grace period, but teql_master_xmit() running on another
CPU can still hold a stale pointer into the list, resulting in a
slab-use-after-free:
BUG: KASAN: slab-use-after-free in teql_master_xmit+0xf0f/0x16b0
Read of size 8 at addr ffff888013fb0440 by task poc/332
Freed 512-byte region [ffff888013fb0400, ffff888013fb0600) (kmalloc-512)
The fix?
Add a per-master slaves_lock spinlock that serializes all mutations of
master->slaves and the NEXT_SLAVE() links in teql_destroy() and
teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock
around those updates.
Annotate master->slaves and the per-slave ->next pointer with __rcu and
use the appropriate RCU accessors everywhere they are touched:
rcu_assign_pointer() on the writer side (under slaves_lock),
rcu_dereference_protected() for the writer-side loads (also under
slaves_lock), rcu_dereference_bh() for the loads in teql_master_xmit() and
rtnl_dereference() for the loads in teql_master_open()/teql_master_mtu(),
which run under RTNL.
Pair this with rcu_read_lock_bh()/rcu_read_unlock_bh() around the list
traversal in teql_master_xmit(), so that readers either observe a fully
linked list or are deferred until the in-flight mutation completes. The two
early-return paths in teql_master_xmit() are updated to release the RCU-bh
read-side critical section before returning, since leaving it held would
disable BH on that CPU for good. |
| In the Linux kernel, the following vulnerability has been resolved:
net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy
sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(),
a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy()
only unregisters the bus and clears sfp->i2c_mii without calling
mdiobus_free(). As the only reference to the bus is then cleared, the
struct mii_bus is leaked.
This is hit whenever a copper/RollBall SFP module that instantiated an MDIO
bus is removed: sfp_sm_main() takes the global teardown path and calls
sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees
sfp->i2c_mii directly, which is why the leak only triggered on module
hot-removal and not on unbind.
Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in
sfp_i2c_mdiobus_create(). |
| In the Linux kernel, the following vulnerability has been resolved:
eth: fbnic: don't cache shinfo across skb realloc
fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb
including the shared info. We can't use the pointer calculated
before the call.
BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0
Read of size 4 at addr ff110000262edd98 by task swapper/5/0
Call Trace:
fbnic_tx_lso.isra.0+0x668/0x8e0
fbnic_xmit_frame+0x622/0xba0
dev_hard_start_xmit+0xf4/0x620
Allocated by task 8653:
__alloc_skb+0x11e/0x5f0
alloc_skb_with_frags+0xcc/0x6c0
sock_alloc_send_pskb+0x327/0x3f0
__ip_append_data+0x188b/0x47a0
ip_make_skb+0x24a/0x300
udp_sendmsg+0x14d2/0x21e0
Freed by task 0:
kfree+0x123/0x5a0
pskb_expand_head+0x36c/0xfa0
fbnic_tx_lso.isra.0+0x500/0x8e0
fbnic_xmit_frame+0x622/0xba0
dev_hard_start_xmit+0xf4/0x620
sch_direct_xmit+0x25b/0x1100
The buggy address belongs to the object at ff110000262edc40
which belongs to the cache skbuff_small_head of size 640
The buggy address is located 344 bytes inside of
freed 640-byte region [ff110000262edc40, ff110000262ede |
| In the Linux kernel, the following vulnerability has been resolved:
net: sungem: fix probe error cleanup
gem_init_one() calls gem_remove_one() when register_netdev() fails.
gem_remove_one() unregisters and frees resources owned by the net_device,
including the DMA block, MMIO mapping, PCI regions, and the net_device
itself. gem_init_one() then falls through to its own cleanup labels and
frees the same resources again.
Keep the register_netdev() error path in gem_init_one(): clear drvdata so
PM/remove paths do not see a half-registered device, remove the NAPI
instance added during probe, and let the existing cleanup labels release
the resources once.
The issue was found by a local static-analysis checker for probe error
paths. The reported path was manually inspected before sending this fix.
Compile-tested with CONFIG_SUNGEM=y. Runtime testing was not performed
because no sungem hardware is available. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/mm: Fix handling of _PAGE_UNUSED pte bit
The _PAGE_UNUSED softbit should not really be lying around. Its sole
purpose is to signal to try_to_unmap_one() and try_to_migrate_one()
that the page can be discarded instead of being moved / swapped.
KVM has no way to know why a page is being unmapped, so it sets the bit
on userspace ptes corresponding to unused guest pages every time they
get unmapped. KVM has no reasonable way to clear the bit once the page
is in use again.
While set_ptes() checks and clears the bit, other paths that set new
ptes did not. This led to used pages being thrown out as if they were
unused, causing guest corruption.
Fix the issue by clearing the _PAGE_UNUSED bit for present ptes in
set_pte(), i.e. whenever a present pte is getting set. The check in
set_ptes() is then redundant and can be removed.
Also fix gmap_helper_try_set_pte_unused() to only set the bit if the
pte is present; the _PAGE_UNUSED bit is only defined for present ptes
and thus should not be set for non-present ptes. |
| In the Linux kernel, the following vulnerability has been resolved:
alloc_tag: fix use-after-free in /proc/allocinfo after module unload
allocinfo_start() only reinitializes the codetag iterator at position 0.
For subsequent reads (position > 0), it reuses cached iterator state from
the previous batch. allocinfo_stop() drops mod_lock between read batches,
which allows module unload to complete and free the module memory that the
cached iterator still references:
CPU0 (read) CPU1 (rmmod)
---- ----
allocinfo_start(pos=0)
down_read(mod_lock)
allocinfo_show()
...
allocinfo_stop()
up_read(mod_lock)
codetag_unload_module()
kfree(cmod)
release_module_tags()
...
free_mod_mem()
allocinfo_start(pos=N)
down_read(mod_lock)
// reuses cached iter, skips re-init
allocinfo_show()
ct->filename <-- UAF
After free_mod_mem() frees the module's .rodata, allocinfo_show()
dereferences ct->filename, ct->function which point there.
Save the iterator state in allocinfo_next() and resume from it in
allocinfo_start() with codetag_next_ct(), which detects module removal via
idr_find() returning NULL and skips to the next module. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix insn_aux_data leak on verifier err_free_env path
When bpf_check() allocates env->insn_aux_data successfully but later
fails to allocate env->succ, it jumps directly to err_free_env.
The existing vfree(env->insn_aux_data) sits before the err_free_env
label, so that direct jump bypasses it and leaks insn_aux_data.
Move vfree(env->insn_aux_data) into err_free_env so all early and late
exit paths release it consistently. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints
MIDI 2.0 input URBs are started during snd_usb_midi_v2_create(). A
later setup failure can still jump to snd_usb_midi_v2_free(), which
currently frees each endpoint and its coherent URB buffers without first
stopping the submitted URBs. A completion can then dereference the
embedded URB context and endpoint state after they have been freed, or
try to resubmit from the stale endpoint.
This was observed as a KASAN slab-use-after-free in
input_urb_complete().
The buggy scenario involves two paths, with each column showing the order
within that path:
probe error path: USB completion path:
1. start_input_streams() submits 1. The HCD still owns a
input URBs. submitted input URB.
2. A later setup helper returns 2. input_urb_complete() runs
an error. with urb->context in ep.
3. snd_usb_midi_v2_free() frees 3. The completion reads ep
endpoint storage and URB buffers. state and can requeue URBs.
Make the endpoint destructor follow the same teardown ordering used for
disconnect when the endpoint has not already been disconnected: publish
ep->disconnected, kill the URBs synchronously, and drain the endpoint
before freeing URB buffers and endpoint storage. The guard avoids
repeating the stop sequence after the normal
snd_usb_midi_v2_disconnect_all() path, while still synchronizing the
direct MIDI 2.0 create-error free path.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in input_urb_complete+0x37/0x1b0
Workqueue: usb_hub_wq hub_event
RIP: 0010:_raw_spin_unlock_irq+0x2e/0x50
Read of size 8
Call trace:
dump_stack_lvl+0x77/0xb0
print_report+0xce/0x5f0
input_urb_complete+0x37/0x1b0 (sound/usb/midi2.c:186)
srso_alias_return_thunk+0x5/0xfbef5
__virt_addr_valid+0x19f/0x330
kasan_report+0xe0/0x110
__usb_hcd_giveback_urb+0x112/0x1d0
dummy_timer+0xaaa/0x19a0
lock_is_held_type+0x9a/0x110
__lock_acquire+0x467/0x28b0
mark_held_locks+0x40/0x70
_raw_spin_unlock_irqrestore+0x44/0x60
lockdep_hardirqs_on_prepare+0xbb/0x1a0
__hrtimer_run_queues+0x101/0x520
hrtimer_run_softirq+0xd0/0x130
handle_softirqs+0x15b/0x670
__irq_exit_rcu+0xd0/0x170
irq_exit_rcu+0xe/0x20
sysvec_apic_timer_interrupt+0x6c/0x80
asm_sysvec_apic_timer_interrupt+0x1a/0x20 |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Fix leak of SQ timestamp buffer on teardown
The send-queue timestamp ring is allocated with qmem_alloc() when
timestamping is used, but otx2_free_sq_res() never freed sq->timestamps,
leaking that memory across ifdown and device removal. Add the missing
qmem_free() alongside the other SQ companion buffers. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915: clear CRTC color blob pointers after dropping refs
intel_crtc_put_color_blobs() drops the CRTC color blob references, but
leaves the corresponding pointers unchanged.
This can matter in intel_crtc_prepare_cleared_state(), which frees the
old CRTC hw state before calling intel_dp_tunnel_atomic_clear_stream_bw().
The latter can fail while looking up the DP tunnel group state, for
example with -EDEADLK.
If that happens, the function returns without completing the cleared
state preparation. The failed atomic state will then be cleared by the
atomic core and intel_crtc_free_hw_state() can be called again for the
same state, dropping the same blob references again.
Clear the blob pointers after dropping the references so repeated cleanup
of the same CRTC hw state is safe.
(cherry picked from commit d5005addb5f68e8a0edce249506757bdc9e3d8c8) |
| In the Linux kernel, the following vulnerability has been resolved:
apparmor: fail policy unpack on accept2 allocation failure
unpack_pdb() may need to allocate a missing ACCEPT2 table for older policy
data. If that allocation failed, it set an error message but jumped to the
success path, returning a policydb with the required table missing.
Return -ENOMEM through the normal failure path when the ACCEPT2 allocation
fails. Remove the now-unused out label. |
| In the Linux kernel, the following vulnerability has been resolved:
apparmor: aa_label_alloc use aa_label_free on alloc failure
aa_label_alloc() allocates a secid before allocating or taking the label
proxy. If the later proxy step fails, the error path only freed the label
memory, leaking any resources initialized by aa_label_init().
Use aa_label_free() on the failure path so partially initialized labels
release their secid and other label resources before the backing memory is
freed. |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Validate NIX maximum LFs correctly
NIX maximum number of LFs can be set via devlink command
but that can be done before assigning any LFs to a PF/VF.
The condition used to check whether any LFs are assigned is
incorrect. This patch fixes that condition. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_compat: ebtables emulation must reject non-bridge targets
xtables targets return netfilter verdicts: NF_ACCEPT, NF_DROP, and so
on. ebtables targets return incompatible verdicts: EBT_ACCEPT,
EBT_DROP, ... We cannot allow fallback to NFPROTO_UNSPEC.
ebtables doesn't permit this since
11ff7288beb2 ("netfilter: ebtables: reject non-bridge targets")
but that commit missed the nft_compat layer. |
