Security Vulnerabilities - CVEs Published In May 2024
In the Linux kernel, the following vulnerability has been resolved:
netrom: Decrease sock refcount when sock timers expire
Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
del_timer() by sk_stop_timer().
Function sk_reset_timer() will increase the refcount of sock if it is
called on an inactive timer, hence, in case the timer expires, we need to
decrease the refcount ourselves in the handler, otherwise, the sock
refcount will be unbalanced and the sock will never be freed.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-05-21
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix memory leak in tcindex_partial_destroy_work
Syzbot reported memory leak in tcindex_set_parms(). The problem was in
non-freed perfect hash in tcindex_partial_destroy_work().
In tcindex_set_parms() new tcindex_data is allocated and some fields from
old one are copied to new one, but not the perfect hash. Since
tcindex_partial_destroy_work() is the destroy function for old
tcindex_data, we need to free perfect hash to avoid memory leak.
CVSS Score
7.5
EPSS Score
0.001
Published
2024-05-21
In the Linux kernel, the following vulnerability has been resolved:
KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak
vcpu_put is not called if the user copy fails. This can result in preempt
notifier corruption and crashes, among other issues.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-05-21
In the Linux kernel, the following vulnerability has been resolved:
net: fix uninit-value in caif_seqpkt_sendmsg
When nr_segs equal to zero in iovec_from_user, the object
msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg
which is defined in ___sys_sendmsg. So we cann't just judge
msg->msg_iter.iov->base directlly. We can use nr_segs to judge
msg in caif_seqpkt_sendmsg whether has data buffers.
=====================================================
BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg net/socket.c:672 [inline]
____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343
___sys_sendmsg net/socket.c:2397 [inline]
__sys_sendmmsg+0x808/0xc90 net/socket.c:2480
__compat_sys_sendmmsg net/compat.c:656 [inline]
CVSS Score
5.5
EPSS Score
0.0
Published
2024-05-21
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix potential memory leak on unlikely error case
If skb_linearize is needed and fails we could leak a msg on the error
handling. To fix ensure we kfree the msg block before returning error.
Found during code review.
CVSS Score
5.5
EPSS Score
0.001
Published
2024-05-21
In the Linux kernel, the following vulnerability has been resolved:
xdp, net: Fix use-after-free in bpf_xdp_link_release
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending
---truncated---
CVSS Score
5.5
EPSS Score
0.001
Published
2024-05-21
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix tail_call_reachable rejection for interpreter when jit failed
During testing of f263a81451c1 ("bpf: Track subprog poke descriptors correctly
and fix use-after-free") under various failure conditions, for example, when
jit_subprogs() fails and tries to clean up the program to be run under the
interpreter, we ran into the following freeze:
[...]
#127/8 tailcall_bpf2bpf_3:FAIL
[...]
[ 92.041251] BUG: KASAN: slab-out-of-bounds in ___bpf_prog_run+0x1b9d/0x2e20
[ 92.042408] Read of size 8 at addr ffff88800da67f68 by task test_progs/682
[ 92.043707]
[ 92.044030] CPU: 1 PID: 682 Comm: test_progs Tainted: G O 5.13.0-53301-ge6c08cb33a30-dirty #87
[ 92.045542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
[ 92.046785] Call Trace:
[ 92.047171] ? __bpf_prog_run_args64+0xc0/0xc0
[ 92.047773] ? __bpf_prog_run_args32+0x8b/0xb0
[ 92.048389] ? __bpf_prog_run_args64+0xc0/0xc0
[ 92.049019] ? ktime_get+0x117/0x130
[...] // few hundred [similar] lines more
[ 92.659025] ? ktime_get+0x117/0x130
[ 92.659845] ? __bpf_prog_run_args64+0xc0/0xc0
[ 92.660738] ? __bpf_prog_run_args32+0x8b/0xb0
[ 92.661528] ? __bpf_prog_run_args64+0xc0/0xc0
[ 92.662378] ? print_usage_bug+0x50/0x50
[ 92.663221] ? print_usage_bug+0x50/0x50
[ 92.664077] ? bpf_ksym_find+0x9c/0xe0
[ 92.664887] ? ktime_get+0x117/0x130
[ 92.665624] ? kernel_text_address+0xf5/0x100
[ 92.666529] ? __kernel_text_address+0xe/0x30
[ 92.667725] ? unwind_get_return_address+0x2f/0x50
[ 92.668854] ? ___bpf_prog_run+0x15d4/0x2e20
[ 92.670185] ? ktime_get+0x117/0x130
[ 92.671130] ? __bpf_prog_run_args64+0xc0/0xc0
[ 92.672020] ? __bpf_prog_run_args32+0x8b/0xb0
[ 92.672860] ? __bpf_prog_run_args64+0xc0/0xc0
[ 92.675159] ? ktime_get+0x117/0x130
[ 92.677074] ? lock_is_held_type+0xd5/0x130
[ 92.678662] ? ___bpf_prog_run+0x15d4/0x2e20
[ 92.680046] ? ktime_get+0x117/0x130
[ 92.681285] ? __bpf_prog_run32+0x6b/0x90
[ 92.682601] ? __bpf_prog_run64+0x90/0x90
[ 92.683636] ? lock_downgrade+0x370/0x370
[ 92.684647] ? mark_held_locks+0x44/0x90
[ 92.685652] ? ktime_get+0x117/0x130
[ 92.686752] ? lockdep_hardirqs_on+0x79/0x100
[ 92.688004] ? ktime_get+0x117/0x130
[ 92.688573] ? __cant_migrate+0x2b/0x80
[ 92.689192] ? bpf_test_run+0x2f4/0x510
[ 92.689869] ? bpf_test_timer_continue+0x1c0/0x1c0
[ 92.690856] ? rcu_read_lock_bh_held+0x90/0x90
[ 92.691506] ? __kasan_slab_alloc+0x61/0x80
[ 92.692128] ? eth_type_trans+0x128/0x240
[ 92.692737] ? __build_skb+0x46/0x50
[ 92.693252] ? bpf_prog_test_run_skb+0x65e/0xc50
[ 92.693954] ? bpf_prog_test_run_raw_tp+0x2d0/0x2d0
[ 92.694639] ? __fget_light+0xa1/0x100
[ 92.695162] ? bpf_prog_inc+0x23/0x30
[ 92.695685] ? __sys_bpf+0xb40/0x2c80
[ 92.696324] ? bpf_link_get_from_fd+0x90/0x90
[ 92.697150] ? mark_held_locks+0x24/0x90
[ 92.698007] ? lockdep_hardirqs_on_prepare+0x124/0x220
[ 92.699045] ? finish_task_switch+0xe6/0x370
[ 92.700072] ? lockdep_hardirqs_on+0x79/0x100
[ 92.701233] ? finish_task_switch+0x11d/0x370
[ 92.702264] ? __switch_to+0x2c0/0x740
[ 92.703148] ? mark_held_locks+0x24/0x90
[ 92.704155] ? __x64_sys_bpf+0x45/0x50
[ 92.705146] ? do_syscall_64+0x35/0x80
[ 92.706953] ? entry_SYSCALL_64_after_hwframe+0x44/0xae
[...]
Turns out that the program rejection from e411901c0b77 ("bpf: allow for tailcalls
in BPF subprograms for x64 JIT") is buggy since env->prog->aux->tail_call_reachable
is never true. Commit ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall
handling in JIT") added a tracker into check_max_stack_depth() which propagates
the tail_call_reachable condition throughout the subprograms. This info is then
assigned to the subprogram's
---truncated---
CVSS Score
5.5
EPSS Score
0.0
Published
2024-05-21
In the Linux kernel, the following vulnerability has been resolved:
igb: Fix use-after-free error during reset
Cleans the next descriptor to watch (next_to_watch) when cleaning the
TX ring.
Failure to do so can cause invalid memory accesses. If igb_poll() runs
while the controller is reset this can lead to the driver try to free
a skb that was already freed.
(The crash is harder to reproduce with the igb driver, but the same
potential problem exists as the code is identical to igc)
CVSS Score
7.8
EPSS Score
0.0
Published
2024-05-21
In the Linux kernel, the following vulnerability has been resolved:
igc: Fix use-after-free error during reset
Cleans the next descriptor to watch (next_to_watch) when cleaning the
TX ring.
Failure to do so can cause invalid memory accesses. If igc_poll() runs
while the controller is being reset this can lead to the driver try to
free a skb that was already freed.
Log message:
[ 101.525242] refcount_t: underflow; use-after-free.
[ 101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0
[ 101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E)
x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E)
ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E)
rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E)
soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E)
iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E)
soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E)
autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E)
i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E)
[ 101.525303] drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E)
e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E)
usbcore(E) drm(E) button(E) video(E)
[ 101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G E 5.10.30-rt37-tsn1-rt-ipipe #ipipe
[ 101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017
[ 101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0
[ 101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48
44 01 01 e8 d1 c6 42 00 <0f> 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3
[ 101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286
[ 101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001
[ 101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff
[ 101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50
[ 101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00
[ 101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40
[ 101.525337] FS: 0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000
[ 101.525339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0
[ 101.525343] Call Trace:
[ 101.525346] sock_wfree+0x9c/0xa0
[ 101.525353] unix_destruct_scm+0x7b/0xa0
[ 101.525358] skb_release_head_state+0x40/0x90
[ 101.525362] skb_release_all+0xe/0x30
[ 101.525364] napi_consume_skb+0x57/0x160
[ 101.525367] igc_poll+0xb7/0xc80 [igc]
[ 101.525376] ? sched_clock+0x5/0x10
[ 101.525381] ? sched_clock_cpu+0xe/0x100
[ 101.525385] net_rx_action+0x14c/0x410
[ 101.525388] __do_softirq+0xe9/0x2f4
[ 101.525391] __local_bh_enable_ip+0xe3/0x110
[ 101.525395] ? irq_finalize_oneshot.part.47+0xe0/0xe0
[ 101.525398] irq_forced_thread_fn+0x6a/0x80
[ 101.525401] irq_thread+0xe8/0x180
[ 101.525403] ? wake_threads_waitq+0x30/0x30
[ 101.525406] ? irq_thread_check_affinity+0xd0/0xd0
[ 101.525408] kthread+0x183/0x1a0
[ 101.525412] ? kthread_park+0x80/0x80
[ 101.525415] ret_from_fork+0x22/0x30
CVSS Score
7.8
EPSS Score
0.0
Published
2024-05-21
In the Linux kernel, the following vulnerability has been resolved:
kvm: avoid speculation-based attacks from out-of-range memslot accesses
KVM's mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot. The translation is
performed in __gfn_to_hva_memslot using the following formula:
hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE
It is expected that gfn falls within the boundaries of the guest's
physical memory. However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.
__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest's
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva. If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.
Right now it's not clear if there are any cases in which this is
exploitable. One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86. Right
now these are not vulnerable because the hva read goes through get_user(),
which contains an LFENCE speculation barrier. However, there are
patches in progress for x86 uaccess.h to mask kernel addresses instead of
using LFENCE; once these land, a guest could use speculation to read
from the VMM's ring 3 address space. Other architectures such as ARM
already use the address masking method, and would be susceptible to
this same kind of data-dependent access gadgets. Therefore, this patch
proactively protects from these attacks by masking out-of-bounds gfns
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.
Sean Christopherson noted that this patch does not cover
kvm_read_guest_offset_cached. This however is limited to a few bytes
past the end of the cache, and therefore it is unlikely to be useful in
the context of building a chain of data dependent accesses.
CVSS Score
7.1
EPSS Score
0.0
Published
2024-05-21