In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: disable txq irq before flushing hw
ice_qp_dis() intends to stop a given queue pair that is a target of xsk
pool attach/detach. One of the steps is to disable interrupts on these
queues. It currently is broken in a way that txq irq is turned off
*after* HW flush which in turn takes no effect.
ice_qp_dis():
-> ice_qvec_dis_irq()
--> disable rxq irq
--> flush hw
-> ice_vsi_stop_tx_ring()
-->disable txq irq
Below splat can be triggered by following steps:
- start xdpsock WITHOUT loading xdp prog
- run xdp_rxq_info with XDP_TX action on this interface
- start traffic
ext4: zero i_disksize when initializing the bootloader inode
In the Linux kernel, the following vulnerability has been resolved:
ext4: zero i_disksize when initializing the bootloader inode
If the boot loader inode has never been used before, the
EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the
i_size to 0. However, if the "never before used" boot loader has a
non-zero i_size, then i_disksize will be non-zero, and the
inconsistency between i_size and i_disksize can trigger a kernel
warning:
WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa
RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
Call Trace:
vfs_write+0x3b1/
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in ext4_update_inline_data
Syzbot found the following issue:
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
Modules linked in:
CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engin
firmware: xilinx: don't make a sleepable memory allocation from an atomic context
In the Linux kernel, the following vulnerability has been resolved:
firmware: xilinx: don't make a sleepable memory allocation from an atomic context
The following issue was discovered using lockdep:
[ 6.691371] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:209
[ 6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0
[ 6.702431] 2 locks held by swapper/0/1:
[ 6.706300] #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x4c/0x90
[ 6.714900] #1: ffffffc009a2abb8 (enable_lock){....}-{2:2}, at: clk_enable_lock+0x4c/0x140
[ 6.723156] irq ev
In the Linux kernel, the following vulnerability has been resolved:
media: rc: gpio-ir-recv: add remove function
In case runtime PM is enabled, do runtime PM clean up to remove
cpu latency qos request, otherwise driver removal may have below
kernel dump:
[ 19.463299] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000048
[ 19.472161] Mem abort info:
[ 19.474985] ESR = 0x0000000096000004
[ 19.478754] EC = 0x25: DABT (current EL), IL = 32 bits
[ 19.484081] SET = 0, FnV = 0
[ 19.487149] EA = 0, S1PTW = 0
[ 19.490361] FSC = 0x04: level 0 translation fault
[ 19.495256] Data abort info:
[
powerpc/iommu: fix memory leak with using debugfs_lookup()
In the Linux kernel, the following vulnerability has been resolved:
powerpc/iommu: fix memory leak with using debugfs_lookup()
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
In the Linux kernel, the following vulnerability has been resolved:
interconnect: fix mem leak when freeing nodes
The node link array is allocated when adding links to a node but is not
deallocated when nodes are destroyed.
tty: serial: fsl_lpuart: fix race on RX DMA shutdown
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: fsl_lpuart: fix race on RX DMA shutdown
From time to time DMA completion can come in the middle of DMA shutdown:
<process ctx>: <IRQ>:
lpuart32_shutdown()
lpuart_dma_shutdown()
del_timer_sync()
lpuart_dma_rx_complete()
lpuart_copy_rx_to_tty()
mod_timer()
lpuart_dma_rx_free()
When the timer fires a bit later, sport->dma_rx_desc is NULL:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
pc : lpuart_copy_rx_to_tty+0xcc/0x5bc
lr : lpuart_timer_func+0x1c/0x2c
Call trace:
lpuart_copy_rx_to_tty
In the Linux kernel, the following vulnerability has been resolved:
interconnect: exynos: fix node leak in probe PM QoS error path
Make sure to add the newly allocated interconnect node to the provider
before adding the PM QoS request so that the node is freed on errors.
ext4: update s_journal_inum if it changes after journal replay
In the Linux kernel, the following vulnerability has been resolved:
ext4: update s_journal_inum if it changes after journal replay
When mounting a crafted ext4 image, s_journal_inum may change after journal
replay, which is obviously unreasonable because we have successfully loaded
and replayed the journal through the old s_journal_inum. And the new
s_journal_inum bypasses some of the checks in ext4_get_journal(), which
may trigger a null pointer dereference problem. So if s_journal_inum
changes after the journal replay, we ignore the change, and rewrite the
current journal_inum to the superblock.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix an illegal memory access
In the kfd_wait_on_events() function, the kfd_event_waiter structure is
allocated by alloc_event_waiters(), but the event field of the waiter
structure is not initialized; When copy_from_user() fails in the
kfd_wait_on_events() function, it will enter exception handling to
release the previously allocated memory of the waiter structure;
Due to the event field of the waiters structure being accessed
in the free_waiters() function, this results in illegal memory access
and system crash, here is the crash log:
localhost kernel: RIP: 00
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix task hung in ext4_xattr_delete_inode
Syzbot reported a hung task problem:
==================================================================
INFO: task syz-executor232:5073 blocked for more than 143 seconds.
Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5244 [inline]
__schedule+0x995/0xe20 kernel/sched/core.c:6555
schedule+0xcb/0x190 kernel/sched/c
drm/i915/active: Fix misuse of non-idle barriers as fence trackers
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/active: Fix misuse of non-idle barriers as fence trackers
Users reported oopses on list corruptions when using i915 perf with a
number of concurrently running graphics applications. Root cause analysis
pointed at an issue in barrier processing code -- a race among perf open /
close replacing active barriers with perf requests on kernel context and
concurrent barrier preallocate / acquire operations performed during user
context first pin / last unpin.
When adding a request to a composite tracker, we try to reuse an existing
fence tracker, already allocated and re
drm/shmem-helper: Remove another errant put in error path
In the Linux kernel, the following vulnerability has been resolved:
drm/shmem-helper: Remove another errant put in error path
drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
in the dma-buf shmem GEM object getting prematurely freed leading to a
later use-after-free.
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix data corruption after failed write
When buffered write fails to copy data into underlying page cache page,
ocfs2_write_end_nolock() just zeroes out and dirties the page. This can
leave dirty page beyond EOF and if page writeback tries to write this page
before write succeeds and expands i_size, page gets into inconsistent
state where page dirty bit is clear but buffer dirty bits stay set
resulting in page data never getting written and so data copied to the
page is lost. Fix the problem by invalidating page beyond EOF after
failed write.
In the Linux kernel, the following vulnerability has been resolved:
xsk: Add missing overflow check in xdp_umem_reg
The number of chunks can overflow u32. Make sure to return -EINVAL on
overflow. Also remove a redundant u32 cast assigning umem->npgs.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix steering rules cleanup
vport's mc, uc and multicast rules are not deleted in teardown path when
EEH happens. Since the vport's promisc settings(uc, mc and all) in
firmware are reset after EEH, mlx5 driver will try to delete the above
rules in the initialization path. This cause kernel crash because these
software rules are no longer valid.
Fix by nullifying these rules right after delete to avoid accessing any dangling
pointers.
Call Trace:
__list_del_entry_valid+0xcc/0x100 (unreliable)
tree_put_node+0xf4/0x1b0 [mlx5_core]
tree_remove_node+0x30/0x70 [mlx5_co
scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()
In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()
If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not
freed, which will cause following memleak:
unreferenced object 0xffff88810b2c6980 (size 32):
comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$.............
backtrace:
[<0000000098f3a26d>] alua_activate+0xb0/0x320
[<000000003b529641>] scsi_dh_activate+0xb2/
drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes
[WHY]
When PTEBufferSizeInRequests is zero, UBSAN reports the following
warning because dml_log2 returns an unexpected negative value:
shift exponent 4294966273 is too large for 32-bit type 'int'
[HOW]
In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and
assign the result directly.
ftrace: Fix invalid address access in lookup_rec() when index is 0
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix invalid address access in lookup_rec() when index is 0
KASAN reported follow problem:
BUG: KASAN: use-after-free in lookup_rec
Read of size 8 at addr ffff000199270ff0 by task modprobe
CPU: 2 Comm: modprobe
Call trace:
kasan_report
__asan_load8
lookup_rec
ftrace_location
arch_check_ftrace_location
check_kprobe_address_safe
register_kprobe
When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a
pg which is newly added to ftrace_pages_start in ftrace_process_locs().
Before the first pg->index++, index is 0 and accessing pg->rec