| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix memory leak in error flow for subscribe event routine
In case the second xa_insert() fails, the obj_event is not released. Fix
the error unwind flow to free that memory to avoid a memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix double free during GPU reset on DC streams
[Why]
The issue only occurs during the GPU reset code path.
We first backup the current state prior to commiting 0 streams
internally from DM to DC. This state backup contains valid link
encoder assignments.
DC will clear the link encoder assignments as part of current state
(but not the backup, since it was a copied before the commit) and
free the extra stream reference it held.
DC requires that the link encoder assignments remain cleared/invalid
prior to commiting. Since the backup still has valid assignments we
call the interface post reset to clear them. This routine also
releases the extra reference that the link encoder interface held -
resulting in a double free (and eventually a NULL pointer dereference).
[How]
We'll have to do a full DC commit anyway after GPU reset because
the stream count previously went to 0.
We don't need to retain the assignment that we had backed up, so
just copy off of the now clean current state assignment after the
reset has occcurred with the new link_enc_cfg_copy() interface. |
| In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: fix race between xmit and reset
There is a race between reset and the transmit paths that can lead to
ibmvnic_xmit() accessing an scrq after it has been freed in the reset
path. It can result in a crash like:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000000
Faulting instruction address: 0xc0080000016189f8
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]
LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
Call Trace:
[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c9cfcc] sch_direct_xmit+0xec/0x330
[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0
[c000000000c00ad4] __dev_queue_xmit+0x394/0x730
[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]
[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]
[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280
[c000000000c00ca4] __dev_queue_xmit+0x564/0x730
[c000000000cf97e0] neigh_hh_output+0xd0/0x180
[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0
[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0
[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0
[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0
[c000000000d2d984] tcp_retransmit_skb+0x34/0x130
[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0
[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330
[c000000000d317bc] tcp_write_timer+0x5c/0x200
[c000000000243270] call_timer_fn+0x50/0x1c0
[c000000000243704] __run_timers.part.0+0x324/0x460
[c000000000243894] run_timer_softirq+0x54/0xa0
[c000000000ea713c] __do_softirq+0x15c/0x3e0
[c000000000166258] __irq_exit_rcu+0x158/0x190
[c000000000166420] irq_exit+0x20/0x40
[c00000000002853c] timer_interrupt+0x14c/0x2b0
[c000000000009a00] decrementer_common_virt+0x210/0x220
--- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c
The immediate cause of the crash is the access of tx_scrq in the following
snippet during a reset, where the tx_scrq can be either NULL or an address
that will soon be invalid:
ibmvnic_xmit()
{
...
tx_scrq = adapter->tx_scrq[queue_num];
txq = netdev_get_tx_queue(netdev, queue_num);
ind_bufp = &tx_scrq->ind_buf;
if (test_bit(0, &adapter->resetting)) {
...
}
But beyond that, the call to ibmvnic_xmit() itself is not safe during a
reset and the reset path attempts to avoid this by stopping the queue in
ibmvnic_cleanup(). However just after the queue was stopped, an in-flight
ibmvnic_complete_tx() could have restarted the queue even as the reset is
progressing.
Since the queue was restarted we could get a call to ibmvnic_xmit() which
can then access the bad tx_scrq (or other fields).
We cannot however simply have ibmvnic_complete_tx() check the ->resetting
bit and skip starting the queue. This can race at the "back-end" of a good
reset which just restarted the queue but has not cleared the ->resetting
bit yet. If we skip restarting the queue due to ->resetting being true,
the queue would remain stopped indefinitely potentially leading to transmit
timeouts.
IOW ->resetting is too broad for this purpose. Instead use a new flag
that indicates whether or not the queues are active. Only the open/
reset paths control when the queues are active. ibmvnic_complete_tx()
and others wake up the queue only if the queue is marked active.
So we will have:
A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()
->resetting = true
->tx_queues_active = false
disable tx queues
...
->tx_queues_active = true
start tx queues
B. Tx interrupt in ibmvnic_complete_tx():
if (->tx_queues_active)
netif_wake_subqueue();
To ensure that ->tx_queues_active and state of the queues are consistent,
we need a lock which:
- must also be taken in the interrupt path (ibmvnic_complete_tx())
- shared across the multiple
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
clk: Fix clk_hw_get_clk() when dev is NULL
Any registered clk_core structure can have a NULL pointer in its dev
field. While never actually documented, this is evidenced by the wide
usage of clk_register and clk_hw_register with a NULL device pointer,
and the fact that the core of_clk_hw_register() function also passes a
NULL device pointer.
A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that
case will result in a NULL pointer derefence when it calls dev_name() on
that NULL device pointer.
Add a test for this case and use NULL as the dev_id if the device
pointer is NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: visconti: prevent array overflow in visconti_clk_register_gates()
This code was using -1 to represent that there was no reset function.
Unfortunately, the -1 was stored in u8 so the if (clks[i].rs_id >= 0)
condition was always true. This lead to an out of bounds access in
visconti_clk_register_gates(). |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe
This node pointer is returned by of_parse_phandle() with refcount
incremented in this function. Calling of_node_put() to avoid
the refcount leak. |
| In the Linux kernel, the following vulnerability has been resolved:
net: sparx5: switchdev: fix possible NULL pointer dereference
As the possible failure of the allocation, devm_kzalloc() may return NULL
pointer.
Therefore, it should be better to check the 'db' in order to prevent
the dereference of NULL pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: fix ref leak when switching zones
When switching zones or network namespaces without doing a ct clear in
between, it is now leaking a reference to the old ct entry. That's
because tcf_ct_skb_nfct_cached() returns false and
tcf_ct_flow_table_lookup() may simply overwrite it.
The fix is to, as the ct entry is not reusable, free it already at
tcf_ct_skb_nfct_cached(). |
| In the Linux kernel, the following vulnerability has been resolved:
hwrng: cavium - fix NULL but dereferenced coccicheck error
Fix following coccicheck warning:
./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR:
pdev is NULL but dereferenced. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()
[ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020
[ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]
[ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1
[ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018
[ 12.356356] Call Trace:
[ 12.358821] dump_stack_lvl+0x34/0x44
[ 12.362514] check_preemption_disabled+0xd9/0xe0
[ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]
[ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx]
[ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40
[ 12.384284] local_pci_probe+0x42/0x80
[ 12.390162] ? pci_match_device+0xd7/0x110
[ 12.396366] pci_device_probe+0xfd/0x1b0
[ 12.402372] really_probe+0x1e7/0x3e0
[ 12.408114] __driver_probe_device+0xfe/0x180
[ 12.414544] driver_probe_device+0x1e/0x90
[ 12.420685] __driver_attach+0xc0/0x1c0
[ 12.426536] ? __device_attach_driver+0xe0/0xe0
[ 12.433061] ? __device_attach_driver+0xe0/0xe0
[ 12.439538] bus_for_each_dev+0x78/0xc0
[ 12.445294] bus_add_driver+0x12b/0x1e0
[ 12.451021] driver_register+0x8f/0xe0
[ 12.456631] ? 0xffffffffc07bc000
[ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx]
[ 12.468776] do_one_initcall+0x44/0x200
[ 12.474401] ? load_module+0xad3/0xba0
[ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410
[ 12.486268] do_init_module+0x5c/0x280
[ 12.491730] __do_sys_init_module+0x12e/0x1b0
[ 12.497785] do_syscall_64+0x3b/0x90
[ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 12.509764] RIP: 0033:0x7f554f73ab2e |
| In the Linux kernel, the following vulnerability has been resolved:
wireguard: socket: free skb in send6 when ipv6 is disabled
I got a memory leak report:
unreferenced object 0xffff8881191fc040 (size 232):
comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0
[<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340
[<ffffffff832974fb>] __alloc_skb+0x1db/0x200
[<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0
[<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110
[<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30
[<ffffffff8119c558>] process_one_work+0x2e8/0x770
[<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0
[<ffffffff811a88e0>] kthread+0x120/0x160
[<ffffffff8100242f>] ret_from_fork+0x1f/0x30
In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_
buffer_to_peer(), the semantics of send6() is required to free skb. But
when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it
to fix this bug. |
| In the Linux kernel, the following vulnerability has been resolved:
rtc: gamecube: Fix refcount leak in gamecube_rtc_read_offset_from_sram
The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount. |
| In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Free the page array when watch_queue is dismantled
Commit 7ea1a0124b6d ("watch_queue: Free the alloc bitmap when the
watch_queue is torn down") took care of the bitmap, but not the page
array.
BUG: memory leak
unreferenced object 0xffff88810d9bc140 (size 32):
comm "syz-executor335", pid 3603, jiffies 4294946994 (age 12.840s)
hex dump (first 32 bytes):
40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@.............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
kmalloc_array include/linux/slab.h:621 [inline]
kcalloc include/linux/slab.h:652 [inline]
watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251
pipe_ioctl+0x82/0x140 fs/pipe.c:632
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline] |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix memory leak of uid in files registration
When there are no files for __io_sqe_files_scm() to process in the
range, it'll free everything and return. However, it forgets to put uid. |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: felix: fix possible NULL pointer dereference
As the possible failure of the allocation, kzalloc() may return NULL
pointer.
Therefore, it should be better to check the 'sgi' in order to prevent
the dereference of NULL pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt
This event is just specified for SCO and eSCO link types.
On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR
of an existing LE connection, LE link type and a status that triggers the
second case of the packet processing a NULL pointer dereference happens,
as conn->link is NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj
This issue takes place in an error path in
amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into
default case, the function simply returns -EINVAL, forgetting to
decrement the reference count of a dma_fence obj, which is bumped
earlier by amdgpu_cs_get_fence(). This may result in reference count
leaks.
Fix it by decreasing the refcount of specific object before returning
the error code. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak
[why]
Resource release is needed on the error handling path
to prevent memory leak.
[how]
Fix this by adding kfree on the error handling path. |
| In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum: Guard against invalid local ports
When processing events generated by the device's firmware, the driver
protects itself from events reported for non-existent local ports, but
not for the CPU port (local port 0), which exists, but does not have all
the fields as any local port.
This can result in a NULL pointer dereference when trying access
'struct mlxsw_sp_port' fields which are not initialized for CPU port.
Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware")
already handled such issue by bailing early when processing a PUDE event
reported for the CPU port.
Generalize the approach by moving the check to a common function and
making use of it in all relevant places. |
| In the Linux kernel, the following vulnerability has been resolved:
ath11k: fix kernel panic during unload/load ath11k modules
Call netif_napi_del() from ath11k_ahb_free_ext_irq() to fix
the following kernel panic when unload/load ath11k modules
for few iterations.
[ 971.201365] Unable to handle kernel paging request at virtual address 6d97a208
[ 971.204227] pgd = 594c2919
[ 971.211478] [6d97a208] *pgd=00000000
[ 971.214120] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 971.412024] CPU: 2 PID: 4435 Comm: insmod Not tainted 5.4.89 #0
[ 971.434256] Hardware name: Generic DT based system
[ 971.440165] PC is at napi_by_id+0x10/0x40
[ 971.445019] LR is at netif_napi_add+0x160/0x1dc
[ 971.743127] (napi_by_id) from [<807d89a0>] (netif_napi_add+0x160/0x1dc)
[ 971.751295] (netif_napi_add) from [<7f1209ac>] (ath11k_ahb_config_irq+0xf8/0x414 [ath11k_ahb])
[ 971.759164] (ath11k_ahb_config_irq [ath11k_ahb]) from [<7f12135c>] (ath11k_ahb_probe+0x40c/0x51c [ath11k_ahb])
[ 971.768567] (ath11k_ahb_probe [ath11k_ahb]) from [<80666864>] (platform_drv_probe+0x48/0x94)
[ 971.779670] (platform_drv_probe) from [<80664718>] (really_probe+0x1c8/0x450)
[ 971.789389] (really_probe) from [<80664cc4>] (driver_probe_device+0x15c/0x1b8)
[ 971.797547] (driver_probe_device) from [<80664f60>] (device_driver_attach+0x44/0x60)
[ 971.805795] (device_driver_attach) from [<806650a0>] (__driver_attach+0x124/0x140)
[ 971.814822] (__driver_attach) from [<80662adc>] (bus_for_each_dev+0x58/0xa4)
[ 971.823328] (bus_for_each_dev) from [<80663a2c>] (bus_add_driver+0xf0/0x1e8)
[ 971.831662] (bus_add_driver) from [<806658a4>] (driver_register+0xa8/0xf0)
[ 971.839822] (driver_register) from [<8030269c>] (do_one_initcall+0x78/0x1ac)
[ 971.847638] (do_one_initcall) from [<80392524>] (do_init_module+0x54/0x200)
[ 971.855968] (do_init_module) from [<803945b0>] (load_module+0x1e30/0x1ffc)
[ 971.864126] (load_module) from [<803948b0>] (sys_init_module+0x134/0x17c)
[ 971.871852] (sys_init_module) from [<80301000>] (ret_fast_syscall+0x0/0x50)
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.6.0.1-00760-QCAHKSWPL_SILICONZ-1 |
