| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915: fix race condition UAF in i915_perf_add_config_ioctl
Userspace can guess the id value and try to race oa_config object creation
with config remove, resulting in a use-after-free if we dereference the
object after unlocking the metrics_lock. For that reason, unlocking the
metrics_lock must be done after we are done dereferencing the object.
[tursulin: Manually added stable tag.]
(cherry picked from commit 49f6f6483b652108bcb73accd0204a464b922395) |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: always release netdev hooks from notifier
This reverts "netfilter: nf_tables: skip netdev events generated on netns removal".
The problem is that when a veth device is released, the veth release
callback will also queue the peer netns device for removal.
Its possible that the peer netns is also slated for removal. In this
case, the device memory is already released before the pre_exit hook of
the peer netns runs:
BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0
Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45
Workqueue: netns cleanup_net
Call Trace:
nf_hook_entry_head+0x1b8/0x1d0
__nf_unregister_net_hook+0x76/0x510
nft_netdev_unregister_hooks+0xa0/0x220
__nft_release_hook+0x184/0x490
nf_tables_pre_exit_net+0x12f/0x1b0
..
Order is:
1. First netns is released, veth_dellink() queues peer netns device
for removal
2. peer netns is queued for removal
3. peer netns device is released, unreg event is triggered
4. unreg event is ignored because netns is going down
5. pre_exit hook calls nft_netdev_unregister_hooks but device memory
might be free'd already. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: flower: fix filter idr initialization
The cited commit moved idr initialization too early in fl_change() which
allows concurrent users to access the filter that is still being
initialized and is in inconsistent state, which, in turn, can cause NULL
pointer dereference [0]. Since there is no obvious way to fix the ordering
without reverting the whole cited commit, alternative approach taken to
first insert NULL pointer into idr in order to allocate the handle but
still cause fl_get() to return NULL and prevent concurrent users from
seeing the filter while providing miss-to-action infrastructure with valid
handle id early in fl_change().
[ 152.434728] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN
[ 152.436163] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 152.437269] CPU: 4 PID: 3877 Comm: tc Not tainted 6.3.0-rc4+ #5
[ 152.438110] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 152.439644] RIP: 0010:fl_dump_key+0x8b/0x1d10 [cls_flower]
[ 152.440461] Code: 01 f2 02 f2 c7 40 08 04 f2 04 f2 c7 40 0c 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 00 01 00 00 48 89 c8 48 c1 e8 03 <0f> b6 04 10 84 c0 74 08 3c 03 0f 8e 98 19 00 00 8b 13 85 d2 74 57
[ 152.442885] RSP: 0018:ffff88817a28f158 EFLAGS: 00010246
[ 152.443851] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 152.444826] RDX: dffffc0000000000 RSI: ffffffff8500ae80 RDI: ffff88810a987900
[ 152.445791] RBP: ffff888179d88240 R08: ffff888179d8845c R09: ffff888179d88240
[ 152.446780] R10: ffffed102f451e48 R11: 00000000fffffff2 R12: ffff88810a987900
[ 152.447741] R13: ffffffff8500ae80 R14: ffff88810a987900 R15: ffff888149b3c738
[ 152.448756] FS: 00007f5eb2a34800(0000) GS:ffff88881ec00000(0000) knlGS:0000000000000000
[ 152.449888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 152.450685] CR2: 000000000046ad19 CR3: 000000010b0bd006 CR4: 0000000000370ea0
[ 152.451641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 152.452628] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 152.453588] Call Trace:
[ 152.454032] <TASK>
[ 152.454447] ? netlink_sendmsg+0x7a1/0xcb0
[ 152.455109] ? sock_sendmsg+0xc5/0x190
[ 152.455689] ? ____sys_sendmsg+0x535/0x6b0
[ 152.456320] ? ___sys_sendmsg+0xeb/0x170
[ 152.456916] ? do_syscall_64+0x3d/0x90
[ 152.457529] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 152.458321] ? ___sys_sendmsg+0xeb/0x170
[ 152.458958] ? __sys_sendmsg+0xb5/0x140
[ 152.459564] ? do_syscall_64+0x3d/0x90
[ 152.460122] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 152.460852] ? fl_dump_key_options.part.0+0xea0/0xea0 [cls_flower]
[ 152.461710] ? _raw_spin_lock+0x7a/0xd0
[ 152.462299] ? _raw_read_lock_irq+0x30/0x30
[ 152.462924] ? nla_put+0x15e/0x1c0
[ 152.463480] fl_dump+0x228/0x650 [cls_flower]
[ 152.464112] ? fl_tmplt_dump+0x210/0x210 [cls_flower]
[ 152.464854] ? __kmem_cache_alloc_node+0x1a7/0x330
[ 152.465592] ? nla_put+0x15e/0x1c0
[ 152.466160] tcf_fill_node+0x515/0x9a0
[ 152.466766] ? tc_setup_offload_action+0xf0/0xf0
[ 152.467463] ? __alloc_skb+0x13c/0x2a0
[ 152.468067] ? __build_skb_around+0x330/0x330
[ 152.468814] ? fl_get+0x107/0x1a0 [cls_flower]
[ 152.469503] tc_del_tfilter+0x718/0x1330
[ 152.470115] ? is_bpf_text_address+0xa/0x20
[ 152.470765] ? tc_ctl_chain+0xee0/0xee0
[ 152.471335] ? __kernel_text_address+0xe/0x30
[ 152.471948] ? unwind_get_return_address+0x56/0xa0
[ 152.472639] ? __thaw_task+0x150/0x150
[ 152.473218] ? arch_stack_walk+0x98/0xf0
[ 152.473839] ? __stack_depot_save+0x35/0x4c0
[ 152.474501] ? stack_trace_save+0x91/0xc0
[ 152.475119] ? security_capable+0x51/0x90
[ 152.475741] rtnetlink_rcv_msg+0x2c1/0x9d0
[ 152.476387] ? rtnl_calcit.isra.0+0x2b0/0x2b0
[ 152.477042]
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
media: ov5675: Fix memleak in ov5675_init_controls()
There is a kmemleak when testing the media/i2c/ov5675.c with bpf mock
device:
AssertionError: unreferenced object 0xffff888107362160 (size 16):
comm "python3", pid 277, jiffies 4294832798 (age 20.722s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000abe7d67c>] __kmalloc_node+0x44/0x1b0
[<000000008a725aac>] kvmalloc_node+0x34/0x180
[<000000009a53cd11>] v4l2_ctrl_handler_init_class+0x11d/0x180
[videodev]
[<0000000055b46db0>] ov5675_probe+0x38b/0x897 [ov5675]
[<00000000153d886c>] i2c_device_probe+0x28d/0x680
[<000000004afb7e8f>] really_probe+0x17c/0x3f0
[<00000000ff2f18e4>] __driver_probe_device+0xe3/0x170
[<000000000a001029>] driver_probe_device+0x49/0x120
[<00000000e39743c7>] __device_attach_driver+0xf7/0x150
[<00000000d32fd070>] bus_for_each_drv+0x114/0x180
[<000000009083ac41>] __device_attach+0x1e5/0x2d0
[<0000000015b4a830>] bus_probe_device+0x126/0x140
[<000000007813deaf>] device_add+0x810/0x1130
[<000000007becb867>] i2c_new_client_device+0x386/0x540
[<000000007f9cf4b4>] of_i2c_register_device+0xf1/0x110
[<00000000ebfdd032>] of_i2c_notify+0xfc/0x1f0
ov5675_init_controls() won't clean all the allocated resources in fail
path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to
prevent memleak. |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: Fix potential resource leaks
nfc_get_device() take reference for the device, add missing
nfc_put_device() to release it when not need anymore.
Also fix the style warnning by use error EOPNOTSUPP instead of
ENOTSUPP. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: via-sdmmc: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
delete device, but it's not added yet, it will lead a kernel
crash because of null-ptr-deref in device_del().
Fix this by checking the return value and goto error path which
will call mmc_free_host(). |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: use hdev->workqueue when queuing hdev->{cmd,ncmd}_timer works
syzbot is reporting attempt to schedule hdev->cmd_work work from system_wq
WQ into hdev->workqueue WQ which is under draining operation [1], for
commit c8efcc2589464ac7 ("workqueue: allow chained queueing during
destruction") does not allow such operation.
The check introduced by commit 877afadad2dce8aa ("Bluetooth: When HCI work
queue is drained, only queue chained work") was incomplete.
Use hdev->workqueue WQ when queuing hdev->{cmd,ncmd}_timer works because
hci_{cmd,ncmd}_timeout() calls queue_work(hdev->workqueue). Also, protect
the queuing operation with RCU read lock in order to avoid calling
queue_delayed_work() after cancel_delayed_work() completed. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: snic: Fix possible UAF in snic_tgt_create()
Smatch reports a warning as follows:
drivers/scsi/snic/snic_disc.c:307 snic_tgt_create() warn:
'&tgt->list' not removed from list
If device_add() fails in snic_tgt_create(), tgt will be freed, but
tgt->list will not be removed from snic->disc.tgt_list, then list traversal
may cause UAF.
Remove from snic->disc.tgt_list before free(). |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix the error length of VALIDATE_NEGOTIATE_INFO message
Commit d5c7076b772a ("smb3: add smb3.1.1 to default dialect list")
extend the dialects from 3 to 4, but forget to decrease the extended
length when specific the dialect, then the message length is larger
than expected.
This maybe leak some info through network because not initialize the
message body.
After apply this patch, the VALIDATE_NEGOTIATE_INFO message length is
reduced from 28 bytes to 26 bytes. |
| In the Linux kernel, the following vulnerability has been resolved:
Revert "Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work"
This reverts commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f.
This patch introduces a possible null-ptr-def problem. Revert it. And the
fixed bug by this patch have resolved by commit 73f7b171b7c0 ("Bluetooth:
btsdio: fix use after free bug in btsdio_remove due to race condition"). |
| In the Linux kernel, the following vulnerability has been resolved:
remoteproc: sysmon: fix memory leak in qcom_add_sysmon_subdev()
The kfree() should be called when of_irq_get_byname() fails or
devm_request_threaded_irq() fails in qcom_add_sysmon_subdev(),
otherwise there will be a memory leak, so add kfree() to fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix timeout of a call that hasn't yet been granted a channel
afs_make_call() calls rxrpc_kernel_begin_call() to begin a call (which may
get stalled in the background waiting for a connection to become
available); it then calls rxrpc_kernel_set_max_life() to set the timeouts -
but that starts the call timer so the call timer might then expire before
we get a connection assigned - leading to the following oops if the call
stalled:
BUG: kernel NULL pointer dereference, address: 0000000000000000
...
CPU: 1 PID: 5111 Comm: krxrpcio/0 Not tainted 6.3.0-rc7-build3+ #701
RIP: 0010:rxrpc_alloc_txbuf+0xc0/0x157
...
Call Trace:
<TASK>
rxrpc_send_ACK+0x50/0x13b
rxrpc_input_call_event+0x16a/0x67d
rxrpc_io_thread+0x1b6/0x45f
? _raw_spin_unlock_irqrestore+0x1f/0x35
? rxrpc_input_packet+0x519/0x519
kthread+0xe7/0xef
? kthread_complete_and_exit+0x1b/0x1b
ret_from_fork+0x22/0x30
Fix this by noting the timeouts in struct rxrpc_call when the call is
created. The timer will be started when the first packet is transmitted.
It shouldn't be possible to trigger this directly from userspace through
AF_RXRPC as sendmsg() will return EBUSY if the call is in the
waiting-for-conn state if it dropped out of the wait due to a signal. |
| In the Linux kernel, the following vulnerability has been resolved:
auxdisplay: hd44780: Fix potential memory leak in hd44780_remove()
hd44780_probe() allocates a memory chunk for hd with kzalloc() and
makes "lcd->drvdata->hd44780" point to it. When we call hd44780_remove(),
we should release all relevant memory and resource. But "lcd->drvdata
->hd44780" is not released, which will lead to a memory leak.
We should release the "lcd->drvdata->hd44780" in hd44780_remove() to fix
the memory leak bug. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: it6505: Initialize AUX channel in it6505_i2c_probe
During device boot, the HPD interrupt could be triggered before the DRM
subsystem registers it6505 as a DRM bridge. In such cases, the driver
tries to access AUX channel and causes NULL pointer dereference.
Initializing the AUX channel earlier to prevent such error. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: toshsd: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host(), besides, free_irq() also needs be called. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: alcor: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and calling mmc_free_host() in the
error path. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: pxa: fix null-pointer dereference in filter()
kasprintf() would return NULL pointer when kmalloc() fail to allocate.
Need to check the return pointer before calling strcmp(). |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_api: remove block_cb from driver_list before freeing
Error handler of tcf_block_bind() frees the whole bo->cb_list on error.
However, by that time the flow_block_cb instances are already in the driver
list because driver ndo_setup_tc() callback is called before that up the
call chain in tcf_block_offload_cmd(). This leaves dangling pointers to
freed objects in the list and causes use-after-free[0]. Fix it by also
removing flow_block_cb instances from driver_list before deallocating them.
[0]:
[ 279.868433] ==================================================================
[ 279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0
[ 279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963
[ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4
[ 279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 279.876295] Call Trace:
[ 279.876882] <TASK>
[ 279.877413] dump_stack_lvl+0x33/0x50
[ 279.878198] print_report+0xc2/0x610
[ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0
[ 279.879994] kasan_report+0xae/0xe0
[ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0
[ 279.881744] ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core]
[ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0
[ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0
[ 279.885037] ? tcf_block_setup+0x6b0/0x6b0
[ 279.885901] ? mutex_lock+0x7d/0xd0
[ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0
[ 279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress]
[ 279.888846] tcf_block_get_ext+0x61c/0x1200
[ 279.889711] ingress_init+0x112/0x1c0 [sch_ingress]
[ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress]
[ 279.891701] qdisc_create+0x401/0xea0
[ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470
[ 279.893473] tc_modify_qdisc+0x6f7/0x16d0
[ 279.894344] ? tc_get_qdisc+0xac0/0xac0
[ 279.895213] ? mutex_lock+0x7d/0xd0
[ 279.896005] ? __mutex_lock_slowpath+0x10/0x10
[ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0
[ 279.897770] ? rtnl_calcit.isra.0+0x2b0/0x2b0
[ 279.898672] ? __sys_sendmsg+0xb5/0x140
[ 279.899494] ? do_syscall_64+0x3d/0x90
[ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 279.901337] ? kasan_save_stack+0x2e/0x40
[ 279.902177] ? kasan_save_stack+0x1e/0x40
[ 279.903058] ? kasan_set_track+0x21/0x30
[ 279.903913] ? kasan_save_free_info+0x2a/0x40
[ 279.904836] ? ____kasan_slab_free+0x11a/0x1b0
[ 279.905741] ? kmem_cache_free+0x179/0x400
[ 279.906599] netlink_rcv_skb+0x12c/0x360
[ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0
[ 279.908360] ? netlink_ack+0x1550/0x1550
[ 279.909192] ? rhashtable_walk_peek+0x170/0x170
[ 279.910135] ? kmem_cache_alloc_node+0x1af/0x390
[ 279.911086] ? _copy_from_iter+0x3d6/0xc70
[ 279.912031] netlink_unicast+0x553/0x790
[ 279.912864] ? netlink_attachskb+0x6a0/0x6a0
[ 279.913763] ? netlink_recvmsg+0x416/0xb50
[ 279.914627] netlink_sendmsg+0x7a1/0xcb0
[ 279.915473] ? netlink_unicast+0x790/0x790
[ 279.916334] ? iovec_from_user.part.0+0x4d/0x220
[ 279.917293] ? netlink_unicast+0x790/0x790
[ 279.918159] sock_sendmsg+0xc5/0x190
[ 279.918938] ____sys_sendmsg+0x535/0x6b0
[ 279.919813] ? import_iovec+0x7/0x10
[ 279.920601] ? kernel_sendmsg+0x30/0x30
[ 279.921423] ? __copy_msghdr+0x3c0/0x3c0
[ 279.922254] ? import_iovec+0x7/0x10
[ 279.923041] ___sys_sendmsg+0xeb/0x170
[ 279.923854] ? copy_msghdr_from_user+0x110/0x110
[ 279.924797] ? ___sys_recvmsg+0xd9/0x130
[ 279.925630] ? __perf_event_task_sched_in+0x183/0x470
[ 279.926656] ? ___sys_sendmsg+0x170/0x170
[ 279.927529] ? ctx_sched_in+0x530/0x530
[ 279.928369] ? update_curr+0x283/0x4f0
[ 279.929185] ? perf_event_update_userpage+0x570/0x570
[ 279.930201] ? __fget_light+0x57/0x520
[ 279.931023] ? __switch_to+0x53d/0xe70
[ 27
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: fix memory leak in mt7996_mcu_exit
Always purge mcu skb queues in mt7996_mcu_exit routine even if
mt7996_firmware_state fails. |
| In the Linux kernel, the following vulnerability has been resolved:
net: stream: purge sk_error_queue in sk_stream_kill_queues()
Changheon Lee reported TCP socket leaks, with a nice repro.
It seems we leak TCP sockets with the following sequence:
1) SOF_TIMESTAMPING_TX_ACK is enabled on the socket.
Each ACK will cook an skb put in error queue, from __skb_tstamp_tx().
__skb_tstamp_tx() is using skb_clone(), unless
SOF_TIMESTAMPING_OPT_TSONLY was also requested.
2) If the application is also using MSG_ZEROCOPY, then we put in the
error queue cloned skbs that had a struct ubuf_info attached to them.
Whenever an struct ubuf_info is allocated, sock_zerocopy_alloc()
does a sock_hold().
As long as the cloned skbs are still in sk_error_queue,
socket refcount is kept elevated.
3) Application closes the socket, while error queue is not empty.
Since tcp_close() no longer purges the socket error queue,
we might end up with a TCP socket with at least one skb in
error queue keeping the socket alive forever.
This bug can be (ab)used to consume all kernel memory
and freeze the host.
We need to purge the error queue, with proper synchronization
against concurrent writers. |
