Vulnerabilities

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 /> net: phy: dp83822: Fix null pointer access on DP83825/DP83826 devices<br /> <br /> The probe() function is only used for the DP83822 PHY, leaving the<br /> private data pointer uninitialized for the smaller DP83825/26 models.<br /> While all uses of the private data structure are hidden in 82822 specific<br /> callbacks, configuring the interrupt is shared across all models.<br /> This causes a NULL pointer dereference on the smaller PHYs as it accesses<br /> the private data unchecked. Verifying the pointer avoids that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block, bfq: fix uaf for bfqq in bic_set_bfqq()<br /> <br /> After commit 64dc8c732f5c ("block, bfq: fix possible uaf for &amp;#39;bfqq-&gt;bic&amp;#39;"),<br /> bic-&gt;bfqq will be accessed in bic_set_bfqq(), however, in some context<br /> bic-&gt;bfqq will be freed, and bic_set_bfqq() is called with the freed<br /> bic-&gt;bfqq.<br /> <br /> Fix the problem by always freeing bfqq after bic_set_bfqq().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup/cpuset: Fix wrong check in update_parent_subparts_cpumask()<br /> <br /> It was found that the check to see if a partition could use up all<br /> the cpus from the parent cpuset in update_parent_subparts_cpumask()<br /> was incorrect. As a result, it is possible to leave parent with no<br /> effective cpu left even if there are tasks in the parent cpuset. This<br /> can lead to system panic as reported in [1].<br /> <br /> Fix this probem by updating the check to fail the enabling the partition<br /> if parent&amp;#39;s effective_cpus is a subset of the child&amp;#39;s cpus_allowed.<br /> <br /> Also record the error code when an error happens in update_prstate()<br /> and add a test case where parent partition and child have the same cpu<br /> list and parent has task. Enabling partition in the child will fail in<br /> this case.<br /> <br /> [1] https://www.spinics.net/lists/cgroups/msg36254.html

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: isotp: split tx timer into transmission and timeout<br /> <br /> The timer for the transmission of isotp PDUs formerly had two functions:<br /> 1. send two consecutive frames with a given time gap<br /> 2. monitor the timeouts for flow control frames and the echo frames<br /> <br /> This led to larger txstate checks and potentially to a problem discovered<br /> by syzbot which enabled the panic_on_warn feature while testing.<br /> <br /> The former &amp;#39;txtimer&amp;#39; function is split into &amp;#39;txfrtimer&amp;#39; and &amp;#39;txtimer&amp;#39;<br /> to handle the two above functionalities with separate timer callbacks.<br /> <br /> The two simplified timers now run in one-shot mode and make the state<br /> transitions (especially with isotp_rcv_echo) better understandable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: fix potential NULL deref in efi_mem_reserve_persistent<br /> <br /> When iterating on a linked list, a result of memremap is dereferenced<br /> without checking it for NULL.<br /> <br /> This patch adds a check that falls back on allocating a new page in<br /> case memremap doesn&amp;#39;t succeed.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> [ardb: return -ENOMEM instead of breaking out of the loop]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix flow memory leak in ovs_flow_cmd_new<br /> <br /> Syzkaller reports a memory leak of new_flow in ovs_flow_cmd_new() as it is<br /> not freed when an allocation of a key fails.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888116668000 (size 632):<br /> comm "syz-executor231", pid 1090, jiffies 4294844701 (age 18.871s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmem_cache_zalloc include/linux/slab.h:654 [inline]<br /> [] ovs_flow_alloc+0x19/0x180 net/openvswitch/flow_table.c:77<br /> [] ovs_flow_cmd_new+0x1de/0xd40 net/openvswitch/datapath.c:957<br /> [] genl_family_rcv_msg_doit+0x22d/0x330 net/netlink/genetlink.c:739<br /> [] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]<br /> [] genl_rcv_msg+0x328/0x590 net/netlink/genetlink.c:800<br /> [] netlink_rcv_skb+0x153/0x430 net/netlink/af_netlink.c:2515<br /> [] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811<br /> [] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]<br /> [] netlink_unicast+0x545/0x7f0 net/netlink/af_netlink.c:1339<br /> [] netlink_sendmsg+0x8e7/0xde0 net/netlink/af_netlink.c:1934<br /> [] sock_sendmsg_nosec net/socket.c:651 [inline]<br /> [] sock_sendmsg+0x152/0x190 net/socket.c:671<br /> [] ____sys_sendmsg+0x70a/0x870 net/socket.c:2356<br /> [] ___sys_sendmsg+0xf3/0x170 net/socket.c:2410<br /> [] __sys_sendmsg+0xe5/0x1b0 net/socket.c:2439<br /> [] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> To fix this the patch rearranges the goto labels to reflect the order of<br /> object allocations and adds appropriate goto statements on the error<br /> paths.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: kprobe: Fixup kernel panic when probing an illegal position<br /> <br /> The kernel would panic when probed for an illegal position. eg:<br /> <br /> (CONFIG_RISCV_ISA_C=n)<br /> <br /> echo &amp;#39;p:hello kernel_clone+0x16 a0=%a0&amp;#39; &gt;&gt; kprobe_events<br /> echo 1 &gt; events/kprobes/hello/enable<br /> cat trace<br /> <br /> Kernel panic - not syncing: stack-protector: Kernel stack<br /> is corrupted in: __do_sys_newfstatat+0xb8/0xb8<br /> CPU: 0 PID: 111 Comm: sh Not tainted<br /> 6.2.0-rc1-00027-g2d398fe49a4d #490<br /> Hardware name: riscv-virtio,qemu (DT)<br /> Call Trace:<br /> [] dump_backtrace+0x38/0x48<br /> [] show_stack+0x50/0x68<br /> [] dump_stack_lvl+0x60/0x84<br /> [] dump_stack+0x20/0x30<br /> [] panic+0x160/0x374<br /> [] generic_handle_arch_irq+0x0/0xa8<br /> [] sys_newstat+0x0/0x30<br /> [] sys_clone+0x20/0x30<br /> [] ret_from_syscall+0x0/0x4<br /> ---[ end Kernel panic - not syncing: stack-protector:<br /> Kernel stack is corrupted in: __do_sys_newfstatat+0xb8/0xb8 ]---<br /> <br /> That is because the kprobe&amp;#39;s ebreak instruction broke the kernel&amp;#39;s<br /> original code. The user should guarantee the correction of the probe<br /> position, but it couldn&amp;#39;t make the kernel panic.<br /> <br /> This patch adds arch_check_kprobe in arch_prepare_kprobe to prevent an<br /> illegal position (Such as the middle of an instruction).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF<br /> <br /> After a call to console_unlock() in vcs_read() the vc_data struct can be<br /> freed by vc_deallocate(). Because of that, the struct vc_data pointer<br /> load must be done at the top of while loop in vcs_read() to avoid a UAF<br /> when vcs_size() is called.<br /> <br /> Syzkaller reported a UAF in vcs_size().<br /> <br /> BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)<br /> Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537<br /> <br /> CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1<br /> Hardware name: Red Hat KVM, BIOS 1.15.0-2.module<br /> Call Trace:<br /> <br /> __asan_report_load4_noabort (mm/kasan/report_generic.c:350)<br /> vcs_size (drivers/tty/vt/vc_screen.c:215)<br /> vcs_read (drivers/tty/vt/vc_screen.c:415)<br /> vfs_read (fs/read_write.c:468 fs/read_write.c:450)<br /> ...<br /> <br /> <br /> Allocated by task 1191:<br /> ...<br /> kmalloc_trace (mm/slab_common.c:1069)<br /> vc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720<br /> drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108)<br /> con_install (drivers/tty/vt/vt.c:3383)<br /> tty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413<br /> drivers/tty/tty_io.c:1390)<br /> tty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126)<br /> chrdev_open (fs/char_dev.c:415)<br /> do_dentry_open (fs/open.c:883)<br /> vfs_open (fs/open.c:1014)<br /> ...<br /> <br /> Freed by task 1548:<br /> ...<br /> kfree (mm/slab_common.c:1021)<br /> vc_port_destruct (drivers/tty/vt/vt.c:1094)<br /> tty_port_destructor (drivers/tty/tty_port.c:296)<br /> tty_port_put (drivers/tty/tty_port.c:312)<br /> vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))<br /> vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)<br /> tty_ioctl (drivers/tty/tty_io.c:2776)<br /> ...<br /> <br /> The buggy address belongs to the object at ffff888113747800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 424 bytes inside of<br /> 1024-byte region [ffff888113747800, ffff888113747c00)<br /> <br /> The buggy address belongs to the physical page:<br /> page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000<br /> index:0x0 pfn:0x113740<br /> head:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0<br /> compound_pincount:0<br /> anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)<br /> raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001<br /> raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> &gt; ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ==================================================================<br /> Disabling lock debugging due to kernel taint

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: iscsi_tcp: Fix UAF during login when accessing the shost ipaddress<br /> <br /> If during iscsi_sw_tcp_session_create() iscsi_tcp_r2tpool_alloc() fails,<br /> userspace could be accessing the host&amp;#39;s ipaddress attr. If we then free the<br /> session via iscsi_session_teardown() while userspace is still accessing the<br /> session we will hit a use after free bug.<br /> <br /> Set the tcp_sw_host-&gt;session after we have completed session creation and<br /> can no longer fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress<br /> <br /> Bug report and analysis from Ding Hui.<br /> <br /> During iSCSI session logout, if another task accesses the shost ipaddress<br /> attr, we can get a KASAN UAF report like this:<br /> <br /> [ 276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0<br /> [ 276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088<br /> [ 276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G E 6.1.0-rc8+ #3<br /> [ 276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020<br /> [ 276.944470] Call Trace:<br /> [ 276.944943] <br /> [ 276.945397] dump_stack_lvl+0x34/0x48<br /> [ 276.945887] print_address_description.constprop.0+0x86/0x1e7<br /> [ 276.946421] print_report+0x36/0x4f<br /> [ 276.947358] kasan_report+0xad/0x130<br /> [ 276.948234] kasan_check_range+0x35/0x1c0<br /> [ 276.948674] _raw_spin_lock_bh+0x78/0xe0<br /> [ 276.949989] iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp]<br /> [ 276.951765] show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi]<br /> [ 276.952185] dev_attr_show+0x3f/0x80<br /> [ 276.953005] sysfs_kf_seq_show+0x1fb/0x3e0<br /> [ 276.953401] seq_read_iter+0x402/0x1020<br /> [ 276.954260] vfs_read+0x532/0x7b0<br /> [ 276.955113] ksys_read+0xed/0x1c0<br /> [ 276.955952] do_syscall_64+0x38/0x90<br /> [ 276.956347] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 276.956769] RIP: 0033:0x7f5d3a679222<br /> [ 276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24<br /> [ 276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> [ 276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222<br /> [ 276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003<br /> [ 276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000<br /> [ 276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000<br /> [ 276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58<br /> [ 276.960536] <br /> [ 276.961357] Allocated by task 2209:<br /> [ 276.961756] kasan_save_stack+0x1e/0x40<br /> [ 276.962170] kasan_set_track+0x21/0x30<br /> [ 276.962557] __kasan_kmalloc+0x7e/0x90<br /> [ 276.962923] __kmalloc+0x5b/0x140<br /> [ 276.963308] iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi]<br /> [ 276.963712] iscsi_session_setup+0xda/0xba0 [libiscsi]<br /> [ 276.964078] iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp]<br /> [ 276.964431] iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi]<br /> [ 276.964793] iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi]<br /> [ 276.965153] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]<br /> [ 276.965546] netlink_unicast+0x4d5/0x7b0<br /> [ 276.965905] netlink_sendmsg+0x78d/0xc30<br /> [ 276.966236] sock_sendmsg+0xe5/0x120<br /> [ 276.966576] ____sys_sendmsg+0x5fe/0x860<br /> [ 276.966923] ___sys_sendmsg+0xe0/0x170<br /> [ 276.967300] __sys_sendmsg+0xc8/0x170<br /> [ 276.967666] do_syscall_64+0x38/0x90<br /> [ 276.968028] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 276.968773] Freed by task 2209:<br /> [ 276.969111] kasan_save_stack+0x1e/0x40<br /> [ 276.969449] kasan_set_track+0x21/0x30<br /> [ 276.969789] kasan_save_free_info+0x2a/0x50<br /> [ 276.970146] __kasan_slab_free+0x106/0x190<br /> [ 276.970470] __kmem_cache_free+0x133/0x270<br /> [ 276.970816] device_release+0x98/0x210<br /> [ 276.971145] kobject_cleanup+0x101/0x360<br /> [ 276.971462] iscsi_session_teardown+0x3fb/0x530 [libiscsi]<br /> [ 276.971775] iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp]<br /> [ 276.972143] iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi]<br /> [ 276.972485] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]<br /> [ 276.972808] netlink_unicast+0x4d5/0x7b0<br /> [ 276.973201] netlink_sendmsg+0x78d/0xc30<br /> [ 276.973544] sock_sendmsg+0xe5/0x120<br /> [ 276.973864] ____sys_sendmsg+0x5fe/0x860<br /> [ 276.974248] ___sys_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: multi-gen LRU: fix crash during cgroup migration<br /> <br /> lru_gen_migrate_mm() assumes lru_gen_add_mm() runs prior to itself. This<br /> isn&amp;#39;t true for the following scenario:<br /> <br /> CPU 1 CPU 2<br /> <br /> clone()<br /> cgroup_can_fork()<br /> cgroup_procs_write()<br /> cgroup_post_fork()<br /> task_lock()<br /> lru_gen_migrate_mm()<br /> task_unlock()<br /> task_lock()<br /> lru_gen_add_mm()<br /> task_unlock()<br /> <br /> And when the above happens, kernel crashes because of linked list<br /> corruption (mm_struct-&gt;lru_gen.list).