| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/drm_file: Fix pid refcounting race
<maarten.lankhorst@linux.intel.com>, Maxime Ripard
<mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>
filp->pid is supposed to be a refcounted pointer; however, before this
patch, drm_file_update_pid() only increments the refcount of a struct
pid after storing a pointer to it in filp->pid and dropping the
dev->filelist_mutex, making the following race possible:
process A process B
========= =========
begin drm_file_update_pid
mutex_lock(&dev->filelist_mutex)
rcu_replace_pointer(filp->pid, <pid B>, 1)
mutex_unlock(&dev->filelist_mutex)
begin drm_file_update_pid
mutex_lock(&dev->filelist_mutex)
rcu_replace_pointer(filp->pid, <pid A>, 1)
mutex_unlock(&dev->filelist_mutex)
get_pid(<pid A>)
synchronize_rcu()
put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here ***
get_pid(<pid B>) *** UAF ***
synchronize_rcu()
put_pid(<pid A>)
As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y
because it requires RCU to detect a quiescent state in code that is not
explicitly calling into the scheduler.
This race leads to use-after-free of a "struct pid".
It is probably somewhat hard to hit because process A has to pass
through a synchronize_rcu() operation while process B is between
mutex_unlock() and get_pid().
Fix it by ensuring that by the time a pointer to the current task's pid
is stored in the file, an extra reference to the pid has been taken.
This fix also removes the condition for synchronize_rcu(); I think
that optimization is unnecessary complexity, since in that case we
would usually have bailed out on the lockless check above. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: starfive - Do not free stack buffer
RSA text data uses variable length buffer allocated in software stack.
Calling kfree on it causes undefined behaviour in subsequent operations. |
| In the Linux kernel, the following vulnerability has been resolved:
media: mgb4: Fix double debugfs remove
Fixes an error where debugfs_remove_recursive() is called first on a parent
directory and then again on a child which causes a kernel panic.
[hverkuil: added Fixes/Cc tags] |
| In the Linux kernel, the following vulnerability has been resolved:
9p: add missing locking around taking dentry fid list
Fix a use-after-free on dentry's d_fsdata fid list when a thread
looks up a fid through dentry while another thread unlinks it:
UAF thread:
refcount_t: addition on 0; use-after-free.
p9_fid_get linux/./include/net/9p/client.h:262
v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129
v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181
v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314
v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400
vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248
Freed by:
p9_fid_destroy (inlined)
p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456
p9_fid_put linux/./include/net/9p/client.h:278
v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55
v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518
vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335
The problem is that d_fsdata was not accessed under d_lock, because
d_release() normally is only called once the dentry is otherwise no
longer accessible but since we also call it explicitly in v9fs_remove
that lock is required:
move the hlist out of the dentry under lock then unref its fids once
they are no longer accessible. |
| In the Linux kernel, the following vulnerability has been resolved:
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
When the cpu5wdt module is removing, the origin code uses del_timer() to
de-activate the timer. If the timer handler is running, del_timer() could
not stop it and will return directly. If the port region is released by
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
to write into the region that is released, the use-after-free bug will
happen.
Change del_timer() to timer_shutdown_sync() in order that the timer handler
could be finished before the port region is released. |
| In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix potential glock use-after-free on unmount
When a DLM lockspace is released and there ares still locks in that
lockspace, DLM will unlock those locks automatically. Commit
fb6791d100d1b started exploiting this behavior to speed up filesystem
unmount: gfs2 would simply free glocks it didn't want to unlock and then
release the lockspace. This didn't take the bast callbacks for
asynchronous lock contention notifications into account, which remain
active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the
glocks that should not be unlocked on the sd_dead_glocks list, release
the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if
the receiving glock is dead. |
| In the Linux kernel, the following vulnerability has been resolved:
kunit: Fix kthread reference
There is a race condition when a kthread finishes after the deadline and
before the call to kthread_stop(), which may lead to use after free. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix UAF for cq async event
The refcount of CQ is not protected by locks. When CQ asynchronous
events and CQ destruction are concurrent, CQ may have been released,
which will cause UAF.
Use the xa_lock() to protect the CQ refcount. |
| In the Linux kernel, the following vulnerability has been resolved:
genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()
irq_find_at_or_after() dereferences the interrupt descriptor which is
returned by mt_find() while neither holding sparse_irq_lock nor RCU read
lock, which means the descriptor can be freed between mt_find() and the
dereference:
CPU0 CPU1
desc = mt_find()
delayed_free_desc(desc)
irq_desc_get_irq(desc)
The use-after-free is reported by KASAN:
Call trace:
irq_get_next_irq+0x58/0x84
show_stat+0x638/0x824
seq_read_iter+0x158/0x4ec
proc_reg_read_iter+0x94/0x12c
vfs_read+0x1e0/0x2c8
Freed by task 4471:
slab_free_freelist_hook+0x174/0x1e0
__kmem_cache_free+0xa4/0x1dc
kfree+0x64/0x128
irq_kobj_release+0x28/0x3c
kobject_put+0xcc/0x1e0
delayed_free_desc+0x14/0x2c
rcu_do_batch+0x214/0x720
Guard the access with a RCU read lock section. |
| In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mst: fix vlan use-after-free
syzbot reported a suspicious rcu usage[1] in bridge's mst code. While
fixing it I noticed that nothing prevents a vlan to be freed while
walking the list from the same path (br forward delay timer). Fix the rcu
usage and also make sure we are not accessing freed memory by making
br_mst_vlan_set_state use rcu read lock.
[1]
WARNING: suspicious RCU usage
6.9.0-rc6-syzkaller #0 Not tainted
-----------------------------
net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage!
...
stack backtrace:
CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
nbp_vlan_group net/bridge/br_private.h:1599 [inline]
br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105
br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47
br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88
call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793
expire_timers kernel/time/timer.c:1844 [inline]
__run_timers kernel/time/timer.c:2418 [inline]
__run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429
run_timer_base kernel/time/timer.c:2438 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448
__do_softirq+0x2c6/0x980 kernel/softirq.c:554
invoke_softirq kernel/softirq.c:428 [inline]
__irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633
irq_exit_rcu+0x9/0x30 kernel/softirq.c:645
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758
Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25
RSP: 0018:ffffc90013657100 EFLAGS: 00000206
RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001
RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60
RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0
R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28
R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246 |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: core: delete incorrect free in pinctrl_enable()
The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
so freeing it in pinctrl_enable() will lead to a double free.
The devm_pinctrl_dev_release() function frees the pindescs and destroys
the mutex as well. |
| In the Linux kernel, the following vulnerability has been resolved:
thermal/debugfs: Prevent use-after-free from occurring after cdev removal
Since thermal_debug_cdev_remove() does not run under cdev->lock, it can
run in parallel with thermal_debug_cdev_state_update() and it may free
the struct thermal_debugfs object used by the latter after it has been
checked against NULL.
If that happens, thermal_debug_cdev_state_update() will access memory
that has been freed already causing the kernel to crash.
Address this by using cdev->lock in thermal_debug_cdev_remove() around
the cdev->debugfs value check (in case the same cdev is removed at the
same time in two different threads) and its reset to NULL.
Cc :6.8+ <stable@vger.kernel.org> # 6.8+ |
| In the Linux kernel, the following vulnerability has been resolved:
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique()
with nice analysis.
Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for
timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's
sk_refcnt after putting it into ehash and releasing the bucket lock.
Thus, there is a small race window where other threads could try to
reuse the port during connect() and call sock_hold() in tcp_twsk_unique()
for the TIME-WAIT socket with zero refcnt.
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten
and sock_put() will cause underflow, triggering a real use-after-free
somewhere else.
To avoid the use-after-free, we need to use refcount_inc_not_zero() in
tcp_twsk_unique() and give up on reusing the port if it returns false.
[0]:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1
Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023
RIP: 0010:refcount_warn_saturate+0xe5/0x110
Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8
RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027
RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0
RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0
R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84
R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0
FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0
PKRU: 55555554
Call Trace:
<TASK>
? refcount_warn_saturate+0xe5/0x110
? __warn+0x81/0x130
? refcount_warn_saturate+0xe5/0x110
? report_bug+0x171/0x1a0
? refcount_warn_saturate+0xe5/0x110
? handle_bug+0x3c/0x80
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? refcount_warn_saturate+0xe5/0x110
tcp_twsk_unique+0x186/0x190
__inet_check_established+0x176/0x2d0
__inet_hash_connect+0x74/0x7d0
? __pfx___inet_check_established+0x10/0x10
tcp_v4_connect+0x278/0x530
__inet_stream_connect+0x10f/0x3d0
inet_stream_connect+0x3a/0x60
__sys_connect+0xa8/0xd0
__x64_sys_connect+0x18/0x20
do_syscall_64+0x83/0x170
entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7f62c11a885d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48
RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d
RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003
RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0
R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
a UAF in the tipc_buf_append() error path:
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
linux/net/core/skbuff.c:1183
Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.0-debian-1.16.0-5 04/01/2014
Call Trace:
<IRQ>
__dump_stack linux/lib/dump_stack.c:88
dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106
print_address_description linux/mm/kasan/report.c:377
print_report+0xc4/0x620 linux/mm/kasan/report.c:488
kasan_report+0xda/0x110 linux/mm/kasan/report.c:601
kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183
skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026
skb_release_all linux/net/core/skbuff.c:1094
__kfree_skb linux/net/core/skbuff.c:1108
kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144
kfree_skb linux/./include/linux/skbuff.h:1244
tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186
tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324
tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824
tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159
tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390
udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108
udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186
udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346
__udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422
ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233
NF_HOOK linux/./include/linux/netfilter.h:314
NF_HOOK linux/./include/linux/netfilter.h:308
ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254
dst_input linux/./include/net/dst.h:461
ip_rcv_finish linux/net/ipv4/ip_input.c:449
NF_HOOK linux/./include/linux/netfilter.h:314
NF_HOOK linux/./include/linux/netfilter.h:308
ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569
__netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534
__netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648
process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976
__napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576
napi_poll linux/net/core/dev.c:6645
net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781
__do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553
do_softirq linux/kernel/softirq.c:454
do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441
</IRQ>
<TASK>
__local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381
local_bh_enable linux/./include/linux/bottom_half.h:33
rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851
__dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378
dev_queue_xmit linux/./include/linux/netdevice.h:3169
neigh_hh_output linux/./include/net/neighbour.h:526
neigh_output linux/./include/net/neighbour.h:540
ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235
__ip_finish_output linux/net/ipv4/ip_output.c:313
__ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295
ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323
NF_HOOK_COND linux/./include/linux/netfilter.h:303
ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433
dst_output linux/./include/net/dst.h:451
ip_local_out linux/net/ipv4/ip_output.c:129
ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492
udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963
udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250
inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850
sock_sendmsg_nosec linux/net/socket.c:730
__sock_sendmsg linux/net/socket.c:745
__sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191
__do_sys_sendto linux/net/socket.c:2203
__se_sys_sendto linux/net/socket.c:2199
__x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199
do_syscall_x64 linux/arch/x86/entry/common.c:52
do_syscall_
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: fix the double free in rvu_npc_freemem()
Clang static checker(scan-build) warning：
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c:line 2184, column 2
Attempt to free released memory.
npc_mcam_rsrcs_deinit() has released 'mcam->counters.bmap'. Deleted this
redundant kfree() to fix this double free problem. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
Extend a critical section to prevent chan from early freeing.
Also make the l2cap_connect() return type void. Nothing is using the
returned value but it is ugly to return a potentially freed pointer.
Making it void will help with backports because earlier kernels did use
the return value. Now the compile will break for kernels where this
patch is not a complete fix.
Call stack summary:
[use]
l2cap_bredr_sig_cmd
l2cap_connect
┌ mutex_lock(&conn->chan_lock);
│ chan = pchan->ops->new_connection(pchan); <- alloc chan
│ __l2cap_chan_add(conn, chan);
│ l2cap_chan_hold(chan);
│ list_add(&chan->list, &conn->chan_l); ... (1)
└ mutex_unlock(&conn->chan_lock);
chan->conf_state ... (4) <- use after free
[free]
l2cap_conn_del
┌ mutex_lock(&conn->chan_lock);
│ foreach chan in conn->chan_l: ... (2)
│ l2cap_chan_put(chan);
│ l2cap_chan_destroy
│ kfree(chan) ... (3) <- chan freed
└ mutex_unlock(&conn->chan_lock);
==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read
include/linux/instrumented.h:68 [inline]
BUG: KASAN: slab-use-after-free in _test_bit
include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0
net/bluetooth/l2cap_core.c:4260
Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311 |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: msft: fix slab-use-after-free in msft_do_close()
Tying the msft->data lifetime to hdev by freeing it in
hci_release_dev() to fix the following case:
[use]
msft_do_close()
msft = hdev->msft_data;
if (!msft) ...(1) <- passed.
return;
mutex_lock(&msft->filter_lock); ...(4) <- used after freed.
[free]
msft_unregister()
msft = hdev->msft_data;
hdev->msft_data = NULL; ...(2)
kfree(msft); ...(3) <- msft is freed.
==================================================================
BUG: KASAN: slab-use-after-free in __mutex_lock_common
kernel/locking/mutex.c:587 [inline]
BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30
kernel/locking/mutex.c:752
Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309 |
| In the Linux kernel, the following vulnerability has been resolved:
phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered
The power_supply frame-work is not really designed for there to be
long living in kernel references to power_supply devices.
Specifically unregistering a power_supply while some other code has
a reference to it triggers a WARN in power_supply_unregister():
WARN_ON(atomic_dec_return(&psy->use_cnt));
Folllowed by the power_supply still getting removed and the
backing data freed anyway, leaving the tusb1210 charger-detect code
with a dangling reference, resulting in a crash the next time
tusb1210_get_online() is called.
Fix this by only holding the reference in tusb1210_get_online()
freeing it at the end of the function. Note this still leaves
a theoretical race window, but it avoids the issue when manually
rmmod-ing the charger chip driver during development. |
| In the Linux kernel, the following vulnerability has been resolved:
raid1: fix use-after-free for original bio in raid1_write_request()
r1_bio->bios[] is used to record new bios that will be issued to
underlying disks, however, in raid1_write_request(), r1_bio->bios[]
will set to the original bio temporarily. Meanwhile, if blocked rdev
is set, free_r1bio() will be called causing that all r1_bio->bios[]
to be freed:
raid1_write_request()
r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL
for (i = 0; i < disks; i++) -> for each rdev in conf
// first rdev is normal
r1_bio->bios[0] = bio; -> set to original bio
// second rdev is blocked
if (test_bit(Blocked, &rdev->flags))
break
if (blocked_rdev)
free_r1bio()
put_all_bios()
bio_put(r1_bio->bios[0]) -> original bio is freed
Test scripts:
mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean
fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \
-iodepth=128 -name=test -direct=1
echo blocked > /sys/block/md0/md/rd2/state
Test result:
BUG bio-264 (Not tainted): Object already free
-----------------------------------------------------------------------------
Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869
kmem_cache_alloc+0x324/0x480
mempool_alloc_slab+0x24/0x50
mempool_alloc+0x6e/0x220
bio_alloc_bioset+0x1af/0x4d0
blkdev_direct_IO+0x164/0x8a0
blkdev_write_iter+0x309/0x440
aio_write+0x139/0x2f0
io_submit_one+0x5ca/0xb70
__do_sys_io_submit+0x86/0x270
__x64_sys_io_submit+0x22/0x30
do_syscall_64+0xb1/0x210
entry_SYSCALL_64_after_hwframe+0x6c/0x74
Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869
kmem_cache_free+0x28c/0x550
mempool_free_slab+0x1f/0x30
mempool_free+0x40/0x100
bio_free+0x59/0x80
bio_put+0xf0/0x220
free_r1bio+0x74/0xb0
raid1_make_request+0xadf/0x1150
md_handle_request+0xc7/0x3b0
md_submit_bio+0x76/0x130
__submit_bio+0xd8/0x1d0
submit_bio_noacct_nocheck+0x1eb/0x5c0
submit_bio_noacct+0x169/0xd40
submit_bio+0xee/0x1d0
blkdev_direct_IO+0x322/0x8a0
blkdev_write_iter+0x309/0x440
aio_write+0x139/0x2f0
Since that bios for underlying disks are not allocated yet, fix this
problem by using mempool_free() directly to free the r1_bio. |
| In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix oops when HEVC init fails
The stateless HEVC decoder saves the instance pointer in the context
regardless if the initialization worked or not. This caused a use after
free, when the pointer is freed in case of a failure in the deinit
function.
Only store the instance pointer when the initialization was successful,
to solve this issue.
Hardware name: Acer Tomato (rev3 - 4) board (DT)
pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]
lr : vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]
sp : ffff80008750bc20
x29: ffff80008750bc20 x28: ffff1299f6d70000 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
x23: ffff80008750bc98 x22: 000000000000a003 x21: ffffd45c4cfae000
x20: 0000000000000010 x19: ffff1299fd668310 x18: 000000000000001a
x17: 000000040044ffff x16: ffffd45cb15dc648 x15: 0000000000000000
x14: ffff1299c08da1c0 x13: ffffd45cb1f87a10 x12: ffffd45cb2f5fe80
x11: 0000000000000001 x10: 0000000000001b30 x9 : ffffd45c4d12b488
x8 : 1fffe25339380d81 x7 : 0000000000000001 x6 : ffff1299c9c06c00
x5 : 0000000000000132 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000010 x1 : ffff80008750bc98 x0 : 0000000000000000
Call trace:
vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]
vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]
vpu_dec_deinit+0x1c/0x30 [mtk_vcodec_dec]
vdec_hevc_slice_deinit+0x30/0x98 [mtk_vcodec_dec]
vdec_if_deinit+0x38/0x68 [mtk_vcodec_dec]
mtk_vcodec_dec_release+0x20/0x40 [mtk_vcodec_dec]
fops_vcodec_release+0x64/0x118 [mtk_vcodec_dec]
v4l2_release+0x7c/0x100
__fput+0x80/0x2d8
__fput_sync+0x58/0x70
__arm64_sys_close+0x40/0x90
invoke_syscall+0x50/0x128
el0_svc_common.constprop.0+0x48/0xf0
do_el0_svc+0x24/0x38
el0_svc+0x38/0xd8
el0t_64_sync_handler+0xc0/0xc8
el0t_64_sync+0x1a8/0x1b0
Code: d503201f f9401660 b900127f b900227f (f9400400) |
