| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix a kernel verifier crash in stacksafe()
Daniel Hodges reported a kernel verifier crash when playing with sched-ext.
Further investigation shows that the crash is due to invalid memory access
in stacksafe(). More specifically, it is the following code:
if (exact != NOT_EXACT &&
old->stack[spi].slot_type[i % BPF_REG_SIZE] !=
cur->stack[spi].slot_type[i % BPF_REG_SIZE])
return false;
The 'i' iterates old->allocated_stack.
If cur->allocated_stack < old->allocated_stack the out-of-bound
access will happen.
To fix the issue add 'i >= cur->allocated_stack' check such that if
the condition is true, stacksafe() should fail. Otherwise,
cur->stack[spi].slot_type[i % BPF_REG_SIZE] memory access is legal. |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: Fix out-of-bound access
If an ATU violation was caused by a CPU Load operation, the SPID could
be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array). |
| In the Linux kernel, the following vulnerability has been resolved:
net: drop bad gso csum_start and offset in virtio_net_hdr
Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb
for GSO packets.
The function already checks that a checksum requested with
VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets
this might not hold for segs after segmentation.
Syzkaller demonstrated to reach this warning in skb_checksum_help
offset = skb_checksum_start_offset(skb);
ret = -EINVAL;
if (WARN_ON_ONCE(offset >= skb_headlen(skb)))
By injecting a TSO packet:
WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0
ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774
ip_finish_output_gso net/ipv4/ip_output.c:279 [inline]
__ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301
iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82
ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813
__gre_xmit net/ipv4/ip_gre.c:469 [inline]
ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661
__netdev_start_xmit include/linux/netdevice.h:4850 [inline]
netdev_start_xmit include/linux/netdevice.h:4864 [inline]
xmit_one net/core/dev.c:3595 [inline]
dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611
__dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261
packet_snd net/packet/af_packet.c:3073 [inline]
The geometry of the bad input packet at tcp_gso_segment:
[ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0
[ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244
[ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0))
[ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536
ip_summed=3 complete_sw=0 valid=0 level=0)
Mitigate with stricter input validation.
csum_offset: for GSO packets, deduce the correct value from gso_type.
This is already done for USO. Extend it to TSO. Let UFO be:
udp[46]_ufo_fragment ignores these fields and always computes the
checksum in software.
csum_start: finding the real offset requires parsing to the transport
header. Do not add a parser, use existing segmentation parsing. Thanks
to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded.
Again test both TSO and USO. Do not test UFO for the above reason, and
do not test UDP tunnel offload.
GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be
CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit
from devices with no checksum offload"), but then still these fields
are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no
need to test for ip_summed == CHECKSUM_PARTIAL first.
This revises an existing fix mentioned in the Fixes tag, which broke
small packets with GSO offload, as detected by kselftests. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: Fix input error path memory access
When there is a misconfiguration of input state slow path
KASAN report error. Fix this error.
west login:
[ 52.987278] eth1: renamed from veth11
[ 53.078814] eth1: renamed from veth21
[ 53.181355] eth1: renamed from veth31
[ 54.921702] ==================================================================
[ 54.922602] BUG: KASAN: wild-memory-access in xfrmi_rcv_cb+0x2d/0x295
[ 54.923393] Read of size 8 at addr 6b6b6b6b00000000 by task ping/512
[ 54.924169]
[ 54.924386] CPU: 0 PID: 512 Comm: ping Not tainted 6.9.0-08574-gcd29a4313a1b #25
[ 54.925290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 54.926401] Call Trace:
[ 54.926731] <IRQ>
[ 54.927009] dump_stack_lvl+0x2a/0x3b
[ 54.927478] kasan_report+0x84/0xa6
[ 54.927930] ? xfrmi_rcv_cb+0x2d/0x295
[ 54.928410] xfrmi_rcv_cb+0x2d/0x295
[ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e
[ 54.929354] xfrm4_rcv_cb+0x46/0x5e
[ 54.929804] xfrm_rcv_cb+0x7e/0xa1
[ 54.930240] xfrm_input+0x1b3a/0x1b96
[ 54.930715] ? xfrm_offload+0x41/0x41
[ 54.931182] ? raw_rcv+0x292/0x292
[ 54.931617] ? nf_conntrack_confirm+0xa2/0xa2
[ 54.932158] ? skb_sec_path+0xd/0x3f
[ 54.932610] ? xfrmi_input+0x90/0xce
[ 54.933066] xfrm4_esp_rcv+0x33/0x54
[ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2
[ 54.934089] ip_local_deliver_finish+0x110/0x120
[ 54.934659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2
[ 54.935248] NF_HOOK.constprop.0+0xf8/0x138
[ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68
[ 54.936317] ? secure_tcpv6_ts_off+0x23/0x168
[ 54.936859] ? ip_protocol_deliver_rcu+0x1b2/0x1b2
[ 54.937454] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d
[ 54.938135] NF_HOOK.constprop.0+0xf8/0x138
[ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68
[ 54.939220] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d
[ 54.939904] ? ip_local_deliver_finish+0x120/0x120
[ 54.940497] __netif_receive_skb_one_core+0xc9/0x107
[ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2
[ 54.941771] ? blk_mq_start_stopped_hw_queues+0xc7/0xf9
[ 54.942413] ? blk_mq_start_stopped_hw_queue+0x38/0x38
[ 54.943044] ? virtqueue_get_buf_ctx+0x295/0x46b
[ 54.943618] process_backlog+0xb3/0x187
[ 54.944102] __napi_poll.constprop.0+0x57/0x1a7
[ 54.944669] net_rx_action+0x1cb/0x380
[ 54.945150] ? __napi_poll.constprop.0+0x1a7/0x1a7
[ 54.945744] ? vring_new_virtqueue+0x17a/0x17a
[ 54.946300] ? note_interrupt+0x2cd/0x367
[ 54.946805] handle_softirqs+0x13c/0x2c9
[ 54.947300] do_softirq+0x5f/0x7d
[ 54.947727] </IRQ>
[ 54.948014] <TASK>
[ 54.948300] __local_bh_enable_ip+0x48/0x62
[ 54.948832] __neigh_event_send+0x3fd/0x4ca
[ 54.949361] neigh_resolve_output+0x1e/0x210
[ 54.949896] ip_finish_output2+0x4bf/0x4f0
[ 54.950410] ? __ip_finish_output+0x171/0x1b8
[ 54.950956] ip_send_skb+0x25/0x57
[ 54.951390] raw_sendmsg+0xf95/0x10c0
[ 54.951850] ? check_new_pages+0x45/0x71
[ 54.952343] ? raw_hash_sk+0x21b/0x21b
[ 54.952815] ? kernel_init_pages+0x42/0x51
[ 54.953337] ? prep_new_page+0x44/0x51
[ 54.953811] ? get_page_from_freelist+0x72b/0x915
[ 54.954390] ? signal_pending_state+0x77/0x77
[ 54.954936] ? preempt_count_sub+0x14/0xb3
[ 54.955450] ? __might_resched+0x8a/0x240
[ 54.955951] ? __might_sleep+0x25/0xa0
[ 54.956424] ? first_zones_zonelist+0x2c/0x43
[ 54.956977] ? __rcu_read_lock+0x2d/0x3a
[ 54.957476] ? __pte_offset_map+0x32/0xa4
[ 54.957980] ? __might_resched+0x8a/0x240
[ 54.958483] ? __might_sleep+0x25/0xa0
[ 54.958963] ? inet_send_prepare+0x54/0x54
[ 54.959478] ? sock_sendmsg_nosec+0x42/0x6c
[ 54.960000] sock_sendmsg_nosec+0x42/0x6c
[ 54.960502] __sys_sendto+0x15d/0x1cc
[ 54.960966] ? __x64_sys_getpeername+0x44/0x44
[ 54.961522] ? __handle_mm_fault+0x679/0xae4
[ 54.962068] ? find_vma+0x6b/0x
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
media: pci: ivtv: Add check for DMA map result
In case DMA fails, 'dma->SG_length' is 0. This value is later used to
access 'dma->SGarray[dma->SG_length - 1]', which will cause out of
bounds access.
Add check to return early on invalid value. Adjust warnings accordingly.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Revise lpfc_prep_embed_io routine with proper endian macro usages
On big endian architectures, it is possible to run into a memory out of
bounds pointer dereference when FCP targets are zoned.
In lpfc_prep_embed_io, the memcpy(ptr, fcp_cmnd, sgl->sge_len) is
referencing a little endian formatted sgl->sge_len value. So, the memcpy
can cause big endian systems to crash.
Redefine the *sgl ptr as a struct sli4_sge_le to make it clear that we are
referring to a little endian formatted data structure. And, update the
routine with proper le32_to_cpu macro usages. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed
If an NTFS file system is mounted to another system with different
PAGE_SIZE from the original system, log->page_size will change in
log_replay(), but log->page_{mask,bits} don't change correspondingly.
This will cause a panic because "u32 bytes = log->page_size - page_off"
will get a negative value in the later read_log_page(). |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: mm: Fix lockless walks with static and dynamic page-table folding
Lina reports random oopsen originating from the fast GUP code when
16K pages are used with 4-level page-tables, the fourth level being
folded at runtime due to lack of LPA2.
In this configuration, the generic implementation of
p4d_offset_lockless() will return a 'p4d_t *' corresponding to the
'pgd_t' allocated on the stack of the caller, gup_fast_pgd_range().
This is normally fine, but when the fourth level of page-table is folded
at runtime, pud_offset_lockless() will offset from the address of the
'p4d_t' to calculate the address of the PUD in the same page-table page.
This results in a stray stack read when the 'p4d_t' has been allocated
on the stack and can send the walker into the weeds.
Fix the problem by providing our own definition of p4d_offset_lockless()
when CONFIG_PGTABLE_LEVELS <= 4 which returns the real page-table
pointer rather than the address of the local stack variable. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Prevent out of bounds access in performance query extensions
Check that the number of perfmons userspace is passing in the copy and
reset extensions is not greater than the internal kernel storage where
the ids will be copied into.
(cherry picked from commit f32b5128d2c440368b5bf3a7a356823e235caabb) |
| In the Linux kernel, the following vulnerability has been resolved:
gve: Account for stopped queues when reading NIC stats
We now account for the fact that the NIC might send us stats for a
subset of queues. Without this change, gve_get_ethtool_stats might make
an invalid access on the priv->stats_report->stats array. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: always do the basic checks for btrfs_qgroup_inherit structure
[BUG]
Syzbot reports the following regression detected by KASAN:
BUG: KASAN: slab-out-of-bounds in btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277
Read of size 8 at addr ffff88814628ca50 by task syz-executor318/5171
CPU: 0 PID: 5171 Comm: syz-executor318 Not tainted 6.10.0-rc2-syzkaller-00010-g2ab795141095 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup.c:3277
create_pending_snapshot+0x1359/0x29b0 fs/btrfs/transaction.c:1854
create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1922
btrfs_commit_transaction+0xf20/0x3740 fs/btrfs/transaction.c:2382
create_snapshot+0x6a1/0x9e0 fs/btrfs/ioctl.c:875
btrfs_mksubvol+0x58f/0x710 fs/btrfs/ioctl.c:1029
btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1075
__btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1340
btrfs_ioctl_snap_create_v2+0x1f2/0x3a0 fs/btrfs/ioctl.c:1422
btrfs_ioctl+0x99e/0xc60
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fcbf1992509
RSP: 002b:00007fcbf1928218 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fcbf1a1f618 RCX: 00007fcbf1992509
RDX: 0000000020000280 RSI: 0000000050009417 RDI: 0000000000000003
RBP: 00007fcbf1a1f610 R08: 00007ffea1298e97 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fcbf19eb660
R13: 00000000200002b8 R14: 00007fcbf19e60c0 R15: 0030656c69662f2e
</TASK>
And it also pinned it down to commit b5357cb268c4 ("btrfs: qgroup: do not
check qgroup inherit if qgroup is disabled").
[CAUSE]
That offending commit skips the whole qgroup inherit check if qgroup is
not enabled.
But that also skips the very basic checks like
num_ref_copies/num_excl_copies and the structure size checks.
Meaning if a qgroup enable/disable race is happening at the background,
and we pass a btrfs_qgroup_inherit structure when the qgroup is
disabled, the check would be completely skipped.
Then at the time of transaction commitment, qgroup is re-enabled and
btrfs_qgroup_inherit() is going to use the incorrect structure and
causing the above KASAN error.
[FIX]
Make btrfs_qgroup_check_inherit() only skip the source qgroup checks.
So that even if invalid btrfs_qgroup_inherit structure is passed in, we
can still reject invalid ones no matter if qgroup is enabled or not.
Furthermore we do already have an extra safety inside
btrfs_qgroup_inherit(), which would just ignore invalid qgroup sources,
so even if we only skip the qgroup source check we're still safe. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link
Commit e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component
and rework codec link") removed the codec entry for the ETDM1_OUT_BE
dai link entirely instead of replacing it with COMP_EMPTY(). This worked
by accident as the remaining COMP_EMPTY() platform entry became the codec
entry, and the platform entry became completely empty, effectively the
same as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn't do anything
for platform entries.
This causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe()
in sound/soc/mediatek/common/mtk-soundcard-driver.c:
for_each_card_prelinks(card, i, dai_link) {
if (adsp_node && !strncmp(dai_link->name, "AFE_SOF", strlen("AFE_SOF")))
dai_link->platforms->of_node = adsp_node;
else if (!dai_link->platforms->name && !dai_link->platforms->of_node)
dai_link->platforms->of_node = platform_node;
}
where the code expects the platforms array to have space for at least one entry.
Add an COMP_EMPTY() entry so that dai_link->platforms has space. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
set_memory_ro() can fail, leaving memory unprotected.
Check its return and take it into account as an error. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix potential integer overflow in page size calculation
Explicitly cast tbo->page_alignment to u64 before bit-shifting to
prevent overflow when assigning to min_page_size. |
| In the Linux kernel, the following vulnerability has been resolved:
tun: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tun_xdp_one() path, which could cause a corrupted skb to be sent
downstack. Even before the skb is transmitted, the
tun_xdp_one-->eth_type_trans() may access the Ethernet header although it
can be less than ETH_HLEN. Once transmitted, this could either cause
out-of-bound access beyond the actual length, or confuse the underlayer
with incorrect or inconsistent header length in the skb metadata.
In the alternative path, tun_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted for
IFF_TAP.
This is to drop any frame shorter than the Ethernet header size just like
how tun_get_user() does.
CVE: CVE-2024-41091 |
| In the Linux kernel, the following vulnerability has been resolved:
tap: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tap_get_user_xdp() path, which could cause a corrupted skb to be
sent downstack. Even before the skb is transmitted, the
tap_get_user_xdp()-->skb_set_network_header() may assume the size is more
than ETH_HLEN. Once transmitted, this could either cause out-of-bound
access beyond the actual length, or confuse the underlayer with incorrect
or inconsistent header length in the skb metadata.
In the alternative path, tap_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted.
This is to drop any frame shorter than the Ethernet header size just like
how tap_get_user() does.
CVE: CVE-2024-41090 |
| In the Linux kernel, the following vulnerability has been resolved:
bcachefs: Fix sb_field_downgrade validation
- bch2_sb_downgrade_validate() wasn't checking for a downgrade entry
extending past the end of the superblock section
- for_each_downgrade_entry() is used in to_text() and needs to work on
malformed input; it also was missing a check for a field extending
past the end of the section |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers
Check that all fields of a V2 algorithm header fit into the available
firmware data buffer.
The wmfw V2 format introduced variable-length strings in the algorithm
block header. This means the overall header length is variable, and the
position of most fields varies depending on the length of the string
fields. Each field must be checked to ensure that it does not overflow
the firmware data buffer.
As this ia bugfix patch, the fixes avoid making any significant change to
the existing code. This makes it easier to review and less likely to
introduce new bugs. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: toshiba_acpi: Fix array out-of-bounds access
In order to use toshiba_dmi_quirks[] together with the standard DMI
matching functions, it must be terminated by a empty entry.
Since this entry is missing, an array out-of-bounds access occurs
every time the quirk list is processed.
Fix this by adding the terminating empty entry. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate ff offset
This adds sanity checks for ff offset. There is a check
on rt->first_free at first, but walking through by ff
without any check. If the second ff is a large offset.
We may encounter an out-of-bound read. |
