Vulnerabilities

Micron Crucial MX500 Series Solid State Drives M3CR046 is vulnerable to Buffer Overflow, which can be triggered by sending specially crafted ATA packets from the host to the drive controller. NOTE: The supplier states that this vulnerability was fully remediated in December 2024 and that updated firmware is available through Crucial’s official support page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent UAF in ip6_send_skb()<br /> <br /> syzbot reported an UAF in ip6_send_skb() [1]<br /> <br /> After ip6_local_out() has returned, we no longer can safely<br /> dereference rt, unless we hold rcu_read_lock().<br /> <br /> A similar issue has been fixed in commit<br /> a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")<br /> <br /> Another potential issue in ip6_finish_output2() is handled in a<br /> separate patch.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964<br /> Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530<br /> <br /> CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964<br /> rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588<br /> rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x1a6/0x270 net/socket.c:745<br /> sock_write_iter+0x2dd/0x400 net/socket.c:1160<br /> do_iter_readv_writev+0x60a/0x890<br /> vfs_writev+0x37c/0xbb0 fs/read_write.c:971<br /> do_writev+0x1b1/0x350 fs/read_write.c:1018<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f936bf79e79<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014<br /> RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79<br /> RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004<br /> RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8<br /> <br /> <br /> Allocated by task 6530:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> unpoison_slab_object mm/kasan/common.c:312 [inline]<br /> __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338<br /> kasan_slab_alloc include/linux/kasan.h:201 [inline]<br /> slab_post_alloc_hook mm/slub.c:3988 [inline]<br /> slab_alloc_node mm/slub.c:4037 [inline]<br /> kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044<br /> dst_alloc+0x12b/0x190 net/core/dst.c:89<br /> ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670<br /> make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]<br /> xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313<br /> ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257<br /> rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x1a6/0x270 net/socket.c:745<br /> ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597<br /> ___sys_sendmsg net/socket.c:2651 [inline]<br /> __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 45:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579<br /> poison_slab_object+0xe0/0x150 mm/kasan/common.c:240<br /> __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256<br /> kasan_slab_free include/linux/kasan.h:184 [inline]<br /> slab_free_hook mm/slub.c:2252 [inline]<br /> slab_free mm/slub.c:4473 [inline]<br /> kmem_cache_free+0x145/0x350 mm/slub.c:4548<br /> dst_destroy+0x2ac/0x460 net/core/dst.c:124<br /> rcu_do_batch kernel/rcu/tree.c:2569 [inline]<br /> rcu_core+0xafd/0x1830 kernel/rcu/tree.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm, slub: do not call do_slab_free for kfence object<br /> <br /> In 782f8906f805 the freeing of kfence objects was moved from deep<br /> inside do_slab_free to the wrapper functions outside. This is a nice<br /> change, but unfortunately it missed one spot in __kmem_cache_free_bulk.<br /> <br /> This results in a crash like this:<br /> <br /> BUG skbuff_head_cache (Tainted: G S B E ): Padding overwritten. 0xffff88907fea0f00-0xffff88907fea0fff @offset=3840<br /> <br /> slab_err (mm/slub.c:1129)<br /> free_to_partial_list (mm/slub.c:? mm/slub.c:4036)<br /> slab_pad_check (mm/slub.c:864 mm/slub.c:1290)<br /> check_slab (mm/slub.c:?)<br /> free_to_partial_list (mm/slub.c:3171 mm/slub.c:4036)<br /> kmem_cache_alloc_bulk (mm/slub.c:? mm/slub.c:4495 mm/slub.c:4586 mm/slub.c:4635)<br /> napi_build_skb (net/core/skbuff.c:348 net/core/skbuff.c:527 net/core/skbuff.c:549)<br /> <br /> All the other callers to do_slab_free appear to be ok.<br /> <br /> Add a kfence_free check in __kmem_cache_free_bulk to avoid the crash.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_flat: Fix corruption when not offsetting data start<br /> <br /> Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start")<br /> introduced a RISC-V specific variant of the FLAT format which does<br /> not allocate any space for the (obsolete) array of shared library<br /> pointers. However, it did not disable the code which initializes the<br /> array, resulting in the corruption of sizeof(long) bytes before the DATA<br /> segment, generally the end of the TEXT segment.<br /> <br /> Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of<br /> CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of<br /> the shared library pointer region so that it will only be initialized<br /> if space is reserved for it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mgag200: Bind I2C lifetime to DRM device<br /> <br /> Managed cleanup with devm_add_action_or_reset() will release the I2C<br /> adapter when the underlying Linux device goes away. But the connector<br /> still refers to it, so this cleanup leaves behind a stale pointer<br /> in struct drm_connector.ddc.<br /> <br /> Bind the lifetime of the I2C adapter to the connector&amp;#39;s lifetime by<br /> using DRM&amp;#39;s managed release. When the DRM device goes away (after<br /> the Linux device) DRM will first clean up the connector and then<br /> clean up the I2C adapter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tick/broadcast: Move per CPU pointer access into the atomic section<br /> <br /> The recent fix for making the take over of the broadcast timer more<br /> reliable retrieves a per CPU pointer in preemptible context.<br /> <br /> This went unnoticed as compilers hoist the access into the non-preemptible<br /> region where the pointer is actually used. But of course it&amp;#39;s valid that<br /> the compiler keeps it at the place where the code puts it which rightfully<br /> triggers:<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code:<br /> caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0<br /> <br /> Move it to the actual usage site which is in a non-preemptible region.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/sclp: Prevent release of buffer in I/O<br /> <br /> When a task waiting for completion of a Store Data operation is<br /> interrupted, an attempt is made to halt this operation. If this attempt<br /> fails due to a hardware or firmware problem, there is a chance that the<br /> SCLP facility might store data into buffers referenced by the original<br /> operation at a later time.<br /> <br /> Handle this situation by not releasing the referenced data buffers if<br /> the halt attempt fails. For current use cases, this might result in a<br /> leak of few pages of memory in case of a rare hardware/firmware<br /> malfunction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink<br /> <br /> When all the strides in a WQE have been consumed, the WQE is unlinked<br /> from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible<br /> to receive CQEs with 0 consumed strides for the same WQE even after the<br /> WQE is fully consumed and unlinked. This triggers an additional unlink<br /> for the same wqe which corrupts the linked list.<br /> <br /> Fix this scenario by accepting 0 sized consumed strides without<br /> unlinking the WQE again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()<br /> <br /> bcm_sf2_mdio_register() calls of_phy_find_device() and then<br /> phy_device_remove() in a loop to remove existing PHY devices.<br /> of_phy_find_device() eventually calls bus_find_device(), which calls<br /> get_device() on the returned struct device * to increment the refcount.<br /> The current implementation does not decrement the refcount, which causes<br /> memory leak.<br /> <br /> This commit adds the missing phy_device_free() call to decrement the<br /> refcount via put_device() to balance the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: sc16is7xx: fix TX fifo corruption<br /> <br /> Sometimes, when a packet is received on channel A at almost the same time<br /> as a packet is about to be transmitted on channel B, we observe with a<br /> logic analyzer that the received packet on channel A is transmitted on<br /> channel B. In other words, the Tx buffer data on channel B is corrupted<br /> with data from channel A.<br /> <br /> The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change<br /> EFR lock to operate on each channels"), which changed the EFR locking to<br /> operate on each channel instead of chip-wise.<br /> <br /> This commit has introduced a regression, because the EFR lock is used not<br /> only to protect the EFR registers access, but also, in a very obscure and<br /> undocumented way, to protect access to the data buffer, which is shared by<br /> the Tx and Rx handlers, but also by each channel of the IC.<br /> <br /> Fix this regression first by switching to kfifo_out_linear_ptr() in<br /> sc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.<br /> <br /> Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for<br /> each channel.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.