scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Zero-init bsg stack buffers to avoid info leak
Several bsg handlers stage their request/reply in an uninitialized 256-byte
on-stack buffer (uint8_t bsg[DMA_POOL_SIZE]) and fill it via
sg_copy_to_buffer(), which only copies as many bytes as the user-supplied
request payload. When the request is shorter than the structure, the
remainder of the buffer is left holding stale stack data.
qla2x00_read_fru_status() and qla2x00_read_i2c() then copy the full
structure back to the reply payload with sg_copy_from_buffer(), leaking the
uninitialized stack bytes to user s
In the Linux kernel, the following vulnerability has been resolved:
f2fs: validate MOVE_RANGE destination size
F2FS_IOC_MOVE_RANGE checks the source range, but not the destination end
before updating i_size. A source hole can expose this: __clone_blkaddrs()
skips NULL_ADDR entries and returns success, so the caller can still extend
the destination inode with unchecked pos_out + len.
Reject destination overflow and use inode_newsize_ok() before extending
the destination inode.
f2fs: limit recovery filename logging to stored length
In the Linux kernel, the following vulnerability has been resolved:
f2fs: limit recovery filename logging to stored length
F2FS stores recovery filenames as a length plus a fixed-size i_name
buffer. The buffer is not NUL-terminated, but recover_inode() and
recover_dentry() print it with %s.
For a 255-byte filename, recovery logging can read past i_name into the
following raw inode fields.
Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN.
Media · CVSS 5.7EPSS 0,21%Sin corrección publicada
f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages()
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages()
There is potential deadloop in race condition:
Thread A Thread B
- fsync
- f2fs_do_sync_file
- f2fs_fsync_node_pages
- last_fsync_dnode
- folio_get(last_folio)
- f2fs_setattr
- f2fs_truncate
- f2fs_truncate_blocks
- f2fs_do_truncate_blocks
- f2fs_truncate_inode_blocks
- truncate_dnode
- truncate_node
- invalidate_mapping_pages
- folio->mapping = NULL
- is_node_folio alwasy return false
- atomic && !marked is al
drm/i915: Guard against NULL driver_data in i915_pci_probe()
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Guard against NULL driver_data in i915_pci_probe()
pci_match_device() can return the dummy pci_device_id_any entry
when a device is force-bound via sysfs driver_override, in which
case ->driver_data is unset (NULL). i915_pci_probe() casts it to
struct intel_device_info * unconditionally and dereferences
intel_info->require_force_probe, causing a NULL-ptr-deref.
(cherry picked from commit 2727922084672cc274ecea726ea00363c2893731)
drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used
In the Linux kernel, the following vulnerability has been resolved:
drm: Fix drm_crtc_commit leak if signaled when PAGE_FLIP_EVENT is used
Commit 1c6ceeee6ebb ("drm/atomic: Fix memleak on ERESTARTSYS during
non-blocking commits") fixed a very similar issue when the event was
allocated by drm_atomic_helper_setup_commit() itself.
However, if the event is allocated in prepare_signaling(), it will also be
set to NULL in complete_signaling(), which prevents drm_crtc_commit from
being put in __drm_atomic_helper_crtc_destroy_state().
Dropping the reference when the event is set to NULL at
complete_signaling() fixes the leak.
The leak can be rep
Media · CVSS 6.8EPSS 0,21%Sin corrección publicada
drm/amdgpu: force complete the KIQ ring fences on reset
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: force complete the KIQ ring fences on reset
Like the MES scheduler ring, the KIQ ring sets no_scheduler = true and uses a
polling fence, so it is skipped by the force-completion loop in
amdgpu_device_pre_asic_reset(). Its hw fence value lives in wb (GTT) memory and
survives a MODE1 reset while fence_drv.sync_seq keeps advancing, so after a
reset the first KIQ submission can poll forever on a seq that is never written
back.
Force complete the KIQ ring fences too so their hw fence is realigned to
sync_seq.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disable preemption in bpf_get_stackid
The get_perf_callchain call needs disabled preemption plus we need
it disabled as long as we access its returned trace entries buffer.
Note the bpf_get_stackid_pe function is executed already with
preemption disabled.
power: supply: ab8500_fg: fix use-after-free on remove
In the Linux kernel, the following vulnerability has been resolved:
power: supply: ab8500_fg: fix use-after-free on remove
ab8500_fg_remove() destroys the driver workqueue while the threaded
interrupt handlers are still armed; they are devm-managed and freed
only after ->remove() returns, so a handler that fires in that
window queues work on the freed workqueue.
Tear the workqueue down through devm instead, registering its cleanup
after the power supply and before the interrupt requests. devm then
frees the interrupts first, so the handlers can no longer queue work,
before disabling the delayed and plain work items and destroying the
work
gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free
In the Linux kernel, the following vulnerability has been resolved:
gtp: add synchronize_net() in gtp_newlink() error path to prevent use-after-free
gtp_newlink()'s error path frees tid_hash and addr_hash without
waiting for an RCU grace period after clearing sk_user_data. A
concurrent gtp_encap_recv() in softirq may still hold the gtp_dev
pointer obtained via rcu_dereference_sk_user_data() and access the
freed memory.
BUG: KASAN: slab-use-after-free in gtp0_pdp_find+0x1f6/0x200 (gtp.c:152)
Call Trace:
<IRQ>
gtp0_pdp_find+0x1f6/0x200
gtp_encap_recv+0x527/0x24b0
udp_queue_rcv_one_skb+0x75f/0xc10
Add synchronize_net() before
ext4: fix out-of-bounds read in ext4_read_inline_dir()
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix out-of-bounds read in ext4_read_inline_dir()
ext4_read_inline_dir() can read a dirent header past the end of its inline
buffer, triggering a slab-out-of-bounds read during getdents64():
BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry
Read of size 2 at addr ffff88800f3dd23c by task exploit/148
...
__ext4_check_dir_entry
ext4_read_inline_dir
iterate_dir
The dirent payload lives in a buffer of exactly inline_size bytes:
dir_buf = kmalloc(inline_size, GFP_NOFS);
but iteration runs in a position space extra_offset bytes larger
(extra_size
SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6
rpcb_register_inet4() and rpcb_register_inet6() store the result of
rpc_sockaddr2uaddr() into map->r_addr without checking it for NULL.
rpc_sockaddr2uaddr() returns NULL when its final kstrdup() fails, and
the unchecked NULL is then carried into the synchronous RPCBPROC_SET
encode path: rpcb_register_call() -> rpc_call_sync() ->
rpcb_enc_getaddr() -> encode_rpcb_string(), whose first statement is
strlen(string), dereferencing NULL and oopsing the kernel.
The crash reproduces under failslab on v6.12; w
xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full
In the Linux kernel, the following vulnerability has been resolved:
xfrm6: fix out-of-bounds write in xfrm6_input_addr() when secpath is full
The depth check in xfrm6_input_addr() is off by one:
if (1 + sp->len == XFRM_MAX_DEPTH)
goto drop;
...
sp->xvec[sp->len++] = x;
xfrm_input() can leave sp->len == XFRM_MAX_DEPTH, and the transport-mode
receive path re-enters IPv6 input via xfrm_trans_reinject() with that
secpath preserved. If the inner packet carries a destination-options HAO
option or a type-2 routing header, xfrm6_input_addr() is called with
sp->len == XFRM_MAX_DEPTH; the check (1 + 6 == 6) is false, so
sp->xvec[sp-
isofs: fix out-of-bounds page array access on empty zisofs block
In the Linux kernel, the following vulnerability has been resolved:
isofs: fix out-of-bounds page array access on empty zisofs block
zisofs_uncompress_block()'s empty-block fast path returns
pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the
decompression path which returns bytes produced relative to poffset.
zisofs_fill_pages() uses that return to advance its page cursor, so when
the zisofs block size is below PAGE_SIZE and a sub-page block leaves
poffset partway into a page, a following empty block over-counts and
advances pages[] one element past its end, after which
"if (poffset && *pages)" reads pages[1] out of bounds. ro
vfio/pci: clear vdev->msi_perm after freeing it on init failure
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: clear vdev->msi_perm after freeing it on init failure
vfio_msi_cap_len() lazily allocates the per-device MSI permission table:
vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT);
if (!vdev->msi_perm)
return -ENOMEM;
ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags);
if (ret) {
kfree(vdev->msi_perm);
return ret; /* vdev->msi_perm left dangling */
}
When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the
error path frees vdev->msi_perm but leaves the freed pointer stored in
it. vdev->msi_perm is not re-zeroed la
timers/itimer: Zero-init old itimerval before copy to userspace
In the Linux kernel, the following vulnerability has been resolved:
timers/itimer: Zero-init old itimerval before copy to userspace
On native sparc64, struct __kernel_old_timeval contains a four-byte hole
after tv_usec because tv_sec is 64-bit while __kernel_suseconds_t is 32-bit.
put_itimerval() fills only the named fields in a stack-allocated
__kernel_old_itimerval and copies the entire object to userspace, so
getitimer() can expose the two padding holes.
Zero-initialize the aggregate before assigning the fields so implicit
padding is deterministic before it crosses the user/kernel boundary.
apparmor: fix cred UAF caused by begin_current_label_crit_section()
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix cred UAF caused by begin_current_label_crit_section()
AppArmor's begin_current_label_crit_section() is a scary function called
from lots of LSM hooks (in particular VFS/socket-related ones) that checks
if the label referenced by the current creds is marked FLAG_STALE, and if
so, attempts to use aa_replace_current_label() to replace the creds with an
updated version that uses a new label.
The first problem with this is that it would directly lead to UAF of
`struct cred` if anything in the kernel takes a pointer to the current
creds and accesses these past a se
apparmor: fix out-of-bounds write when null terminating a label vec
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix out-of-bounds write when null terminating a label vec
aa_vec_unique() null terminates at vec[n - dups] when VEC_FLAG_TERMINATE
is passed. If the components are all distinct no duplicates are dropped,
dups is 0 and the terminator goes to vec[n], so the caller has to provide
room for n + 1 entries.
aa_label_strn_parse() sets up its vector with vec_setup(profile, vec, len,
gfp) and then calls aa_vec_unique(vec, len, VEC_FLAG_TERMINATE), but
vec_setup() does not reserve the terminator entry. Up to LOCAL_VEC_ENTRIES
it uses the local array of LOCAL_VEC_ENTRIES poi
mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch()
In the Linux kernel, the following vulnerability has been resolved:
mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch()
migrate_pages_batch() unmaps each folio before moving it, and every
unmap runs the mmu_notifier invalidate callbacks. On KVM hosts
try_to_migrate() ends up in kvm_mmu_notifier_invalidate_range_start() ->
tdp_mmu_zap_leafs(), which is expensive, so unmapping a large batch keeps
the CPU busy for a long time.
The loop already calls cond_resched(), but on PREEMPTION kernels that is
a no-op, and involuntary preemption is not a Tasks-RCU quiescent state.
A long batch therefore never reports a quiescent stat
mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec()
I am seeing some rcu_tasks stalls in the Meta fleet during reclaim.
INFO: rcu_tasks detected stalls on tasks:
0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8
task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552
Call Trace:
shrink_lruvec
mem_cgroup_iter
shrink_node
do_try_to_free_pages
try_to_free_pages
__alloc_frozen_pages_noprof
alloc_pages_noprof
pte_alloc_one
__pte_alloc
handle_mm_fault
Nothing promises direct reclaim returns in bounded ti