| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: prohibit deactivating all links
In the internal API this calls this is a WARN_ON, but that
should remain since internally we want to know about bugs
that may cause this. Prevent deactivating all links in the
debugfs write directly. |
| In the Linux kernel, the following vulnerability has been resolved:
ipmi: ipmb: Add check devm_kasprintf() returned value
devm_kasprintf() can return a NULL pointer on failure but this
returned value is not checked. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: emux: improve patch ioctl data validation
In load_data(), make the validation of and skipping over the main info
block match that in load_guspatch().
In load_guspatch(), add checking that the specified patch length matches
the actually supplied data, like load_data() already did. |
| In the Linux kernel, the following vulnerability has been resolved:
fpga: m10bmc-sec: Fix probe rollback
Handle probe error rollbacks properly to avoid leaks. |
| In the Linux kernel, the following vulnerability has been resolved:
tty: goldfish: Fix free_irq() on remove
Pass the correct dev_id to free_irq() to fix this splat when the driver
is unbound:
WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq
Trying to free already-free IRQ 65
Call Trace:
warn_slowpath_fmt
free_irq
goldfish_tty_remove
platform_remove
device_remove
device_release_driver_internal
device_driver_detach
unbind_store
drv_attr_store
... |
| In the Linux kernel, the following vulnerability has been resolved:
net/tcp_ao: Don't leak ao_info on error-path
It seems I introduced it together with TCP_AO_CMDF_AO_REQUIRED, on
version 5 [1] of TCP-AO patches. Quite frustrative that having all these
selftests that I've written, running kmemtest & kcov was always in todo.
[1]: https://lore.kernel.org/netdev/20230215183335.800122-5-dima@arista.com/ |
| In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip
It's possible that mtk_crtc->event is NULL in
mtk_drm_crtc_finish_page_flip().
pending_needs_vblank value is set by mtk_crtc->event, but in
mtk_drm_crtc_atomic_flush(), it's is not guarded by the same
lock in mtk_drm_finish_page_flip(), thus a race condition happens.
Consider the following case:
CPU1 CPU2
step 1:
mtk_drm_crtc_atomic_begin()
mtk_crtc->event is not null,
step 1:
mtk_drm_crtc_atomic_flush:
mtk_drm_crtc_update_config(
!!mtk_crtc->event)
step 2:
mtk_crtc_ddp_irq ->
mtk_drm_finish_page_flip:
lock
mtk_crtc->event set to null,
pending_needs_vblank set to false
unlock
pending_needs_vblank set to true,
step 2:
mtk_crtc_ddp_irq ->
mtk_drm_finish_page_flip called again,
pending_needs_vblank is still true
//null pointer
Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more
efficient to just check if mtk_crtc->event is null before use. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Fix for out-of bound access error
Selfgen stats are placed in a buffer using print_array_to_buf_index() function.
Array length parameter passed to the function is too big, resulting in possible
out-of bound memory error.
Decreasing buffer size by one fixes faulty upper bound of passed array.
Discovered in coverity scan, CID 1600742 and CID 1600758 |
| In the Linux kernel, the following vulnerability has been resolved:
ice: fix 'scheduling while atomic' on aux critical err interrupt
There's a kernel BUG splat on processing aux critical error
interrupts in ice_misc_intr():
[ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000
...
[ 2101.060770] Call Trace:
[ 2101.063229] <IRQ>
[ 2101.065252] dump_stack+0x41/0x60
[ 2101.068587] __schedule_bug.cold.100+0x4c/0x58
[ 2101.073060] __schedule+0x6a4/0x830
[ 2101.076570] schedule+0x35/0xa0
[ 2101.079727] schedule_preempt_disabled+0xa/0x10
[ 2101.084284] __mutex_lock.isra.7+0x310/0x420
[ 2101.088580] ? ice_misc_intr+0x201/0x2e0 [ice]
[ 2101.093078] ice_send_event_to_aux+0x25/0x70 [ice]
[ 2101.097921] ice_misc_intr+0x220/0x2e0 [ice]
[ 2101.102232] __handle_irq_event_percpu+0x40/0x180
[ 2101.106965] handle_irq_event_percpu+0x30/0x80
[ 2101.111434] handle_irq_event+0x36/0x53
[ 2101.115292] handle_edge_irq+0x82/0x190
[ 2101.119148] handle_irq+0x1c/0x30
[ 2101.122480] do_IRQ+0x49/0xd0
[ 2101.125465] common_interrupt+0xf/0xf
[ 2101.129146] </IRQ>
...
As Andrew correctly mentioned previously[0], the following call
ladder happens:
ice_misc_intr() <- hardirq
ice_send_event_to_aux()
device_lock()
mutex_lock()
might_sleep()
might_resched() <- oops
Add a new PF state bit which indicates that an aux critical error
occurred and serve it in ice_service_task() in process context.
The new ice_pf::oicr_err_reg is read-write in both hardirq and
process contexts, but only 3 bits of non-critical data probably
aren't worth explicit synchronizing (and they're even in the same
byte [31:24]).
[0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel data leak
For some sev ioctl interfaces, the length parameter that is passed maybe
less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data
that PSP firmware returns. In this case, kmalloc will allocate memory
that is the size of the input rather than the size of the data.
Since PSP firmware doesn't fully overwrite the allocated buffer, these
sev ioctl interface may return uninitialized kernel slab memory. |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c
Add error pointer checks after calling otx2_mbox_get_rsp(). |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Skip Rx TID cleanup for self peer
During peer create, dp setup for the peer is done where Rx TID is
updated for all the TIDs. Peer object for self peer will not go through
dp setup.
When core halts, dp cleanup is done for all the peers. While cleanup,
rx_tid::ab is accessed which causes below stack trace for self peer.
WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851
Call Trace:
__warn+0x7b/0x1a0
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
report_bug+0x10b/0x200
handle_bug+0x3f/0x70
exc_invalid_op+0x13/0x60
asm_exc_invalid_op+0x16/0x20
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k]
ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k]
ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k]
ath12k_core_halt+0x3b/0x100 [ath12k]
ath12k_core_reset+0x494/0x4c0 [ath12k]
sta object in peer will be updated when remote peer is created. Hence
use peer::sta to detect the self peer and skip the cleanup.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 |
| In the Linux kernel, the following vulnerability has been resolved:
ovl: fix tmpfile leak
Missed an error cleanup. |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP
and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.
Command to trigger the warning:
# perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5
Performance counter stats for 'sleep 5':
0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/
5.002117947 seconds time elapsed
0.000131000 seconds user
0.001063000 seconds sys
Below is snippet of the warning in dmesg:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec
preempt_count: 2, expected: 0
4 locks held by perf-exec/2869:
#0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90
#1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0
#2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510
#3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510
irq event stamp: 4806
hardirqs last enabled at (4805): [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0
hardirqs last disabled at (4806): [<c0000000003fae44>] perf_event_exec+0x394/0x510
softirqs last enabled at (0): [<c00000000013c404>] copy_process+0xc34/0x1ff0
softirqs last disabled at (0): [<0000000000000000>] 0x0
CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61
Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV
Call Trace:
dump_stack_lvl+0x98/0xe0 (unreliable)
__might_resched+0x2f8/0x310
__mutex_lock+0x6c/0x13f0
thread_imc_event_add+0xf4/0x1b0
event_sched_in+0xe0/0x210
merge_sched_in+0x1f0/0x600
visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0
ctx_flexible_sched_in+0xcc/0x140
ctx_sched_in+0x20c/0x2a0
ctx_resched+0x104/0x1c0
perf_event_exec+0x340/0x510
begin_new_exec+0x730/0xef0
load_elf_binary+0x3f8/0x1e10
...
do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0
WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0
CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61
Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV
NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670
REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2)
MSR: 9000000000021033 <SF,HV,ME,IR,DR,RI,LE> CR: 48002824 XER: 00000000
CFAR: c00000000013fb64 IRQMASK: 1
The above warning triggered because the current imc-pmu code uses mutex
lock in interrupt disabled sections. The function mutex_lock()
internally calls __might_resched(), which will check if IRQs are
disabled and in case IRQs are disabled, it will trigger the warning.
Fix the issue by changing the mutex lock to spinlock.
[mpe: Fix comments, trim oops in change log, add reported-by tags] |
| In the Linux kernel, the following vulnerability has been resolved:
um: ubd: Do not use drvdata in release
The drvdata is not available in release. Let's just use container_of()
to get the ubd instance. Otherwise, removing a ubd device will result
in a crash:
RIP: 0033:blk_mq_free_tag_set+0x1f/0xba
RSP: 00000000e2083bf0 EFLAGS: 00010246
RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00
RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348
RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7
R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000
R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0
Kernel panic - not syncing: Segfault with no mm
CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1
Workqueue: events mc_work_proc
Stack:
00000000 604f7ef0 62c5d000 62405d20
e2083c30 6002c776 6002c755 600e47ff
e2083c60 6025ffe3 04208060 603d36e0
Call Trace:
[<6002c776>] ubd_device_release+0x21/0x55
[<6002c755>] ? ubd_device_release+0x0/0x55
[<600e47ff>] ? kfree+0x0/0x100
[<6025ffe3>] device_release+0x70/0xba
[<60381d6a>] kobject_put+0xb5/0xe2
[<6026027b>] put_device+0x19/0x1c
[<6026a036>] platform_device_put+0x26/0x29
[<6026ac5a>] platform_device_unregister+0x2c/0x2e
[<6002c52e>] ubd_remove+0xb8/0xd6
[<6002bb74>] ? mconsole_reply+0x0/0x50
[<6002b926>] mconsole_remove+0x160/0x1cc
[<6002bbbc>] ? mconsole_reply+0x48/0x50
[<6003379c>] ? um_set_signals+0x3b/0x43
[<60061c55>] ? update_min_vruntime+0x14/0x70
[<6006251f>] ? dequeue_task_fair+0x164/0x235
[<600620aa>] ? update_cfs_group+0x0/0x40
[<603a0e77>] ? __schedule+0x0/0x3ed
[<60033761>] ? um_set_signals+0x0/0x43
[<6002af6a>] mc_work_proc+0x77/0x91
[<600520b4>] process_scheduled_works+0x1af/0x2c3
[<6004ede3>] ? assign_work+0x0/0x58
[<600527a1>] worker_thread+0x2f7/0x37a
[<6004ee3b>] ? set_pf_worker+0x0/0x64
[<6005765d>] ? arch_local_irq_save+0x0/0x2d
[<60058e07>] ? kthread_exit+0x0/0x3a
[<600524aa>] ? worker_thread+0x0/0x37a
[<60058f9f>] kthread+0x130/0x135
[<6002068e>] new_thread_handler+0x85/0xb6 |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdh - explicitly zeroize private_key
private_key is overwritten with the key parameter passed in by the
caller (if present), or alternatively a newly generated private key.
However, it is possible that the caller provides a key (or the newly
generated key) which is shorter than the previous key. In that
scenario, some key material from the previous key would not be
overwritten. The easiest solution is to explicitly zeroize the entire
private_key array first.
Note that this patch slightly changes the behavior of this function:
previously, if the ecc_gen_privkey failed, the old private_key would
remain. Now, the private_key is always zeroized. This behavior is
consistent with the case where params.key is set and ecc_is_key_valid
fails. |
| In the Linux kernel, the following vulnerability has been resolved:
cachefiles: unmark inode in use in error path
Unmark inode in use if error encountered. If the in-use flag leakage
occurs in cachefiles_open_file(), Cachefiles will complain "Inode
already in use" when later another cookie with the same index key is
looked up.
If the in-use flag leakage occurs in cachefiles_create_tmpfile(), though
the "Inode already in use" warning won't be triggered, fix the leakage
anyway. |
| In the Linux kernel, the following vulnerability has been resolved:
net: tun: unlink NAPI from device on destruction
Syzbot found a race between tun file and device destruction.
NAPIs live in struct tun_file which can get destroyed before
the netdev so we have to del them explicitly. The current
code is missing deleting the NAPI if the queue was detached
first. |
| In the Linux kernel, the following vulnerability has been resolved:
mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()
It should be size of the struct clk_bulk_data, not data pointer pass to
devm_kcalloc(). |
| In the Linux kernel, the following vulnerability has been resolved:
mm: huge_memory: fix misused mapping_large_folio_support() for anon folios
When I did a large folios split test, a WARNING "[ 5059.122759][ T166]
Cannot split file folio to non-0 order" was triggered. But the test cases
are only for anonmous folios. while mapping_large_folio_support() is only
reasonable for page cache folios.
In split_huge_page_to_list_to_order(), the folio passed to
mapping_large_folio_support() maybe anonmous folio. The folio_test_anon()
check is missing. So the split of the anonmous THP is failed. This is
also the same for shmem_mapping(). We'd better add a check for both. But
the shmem_mapping() in __split_huge_page() is not involved, as for
anonmous folios, the end parameter is set to -1, so (head[i].index >= end)
is always false. shmem_mapping() is not called.
Also add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon
mapping, So we can detect the wrong use more easily.
THP folios maybe exist in the pagecache even the file system doesn't
support large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is
enabled, khugepaged will try to collapse read-only file-backed pages to
THP. But the mapping does not actually support multi order large folios
properly.
Using /sys/kernel/debug/split_huge_pages to verify this, with this patch,
large anon THP is successfully split and the warning is ceased. |
