Vulnerabilities

In tmu_reset_tmu_trip_counter of , there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

In tmu_set_gov_active of tmu.c, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

OOB read in the TMU plugin that allows for memory disclosure in the power management subsystem of the device.

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 /> wifi: iwlwifi: fix a memory corruption<br /> <br /> iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that<br /> if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in<br /> bytes, we&amp;#39;ll write past the buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: fix usage of multi-buffer BPF helpers for ZC XDP<br /> <br /> Currently when packet is shrunk via bpf_xdp_adjust_tail() and memory<br /> type is set to MEM_TYPE_XSK_BUFF_POOL, null ptr dereference happens:<br /> <br /> [1136314.192256] BUG: kernel NULL pointer dereference, address:<br /> 0000000000000034<br /> [1136314.203943] #PF: supervisor read access in kernel mode<br /> [1136314.213768] #PF: error_code(0x0000) - not-present page<br /> [1136314.223550] PGD 0 P4D 0<br /> [1136314.230684] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [1136314.239621] CPU: 8 PID: 54203 Comm: xdpsock Not tainted 6.6.0+ #257<br /> [1136314.250469] Hardware name: Intel Corporation S2600WFT/S2600WFT,<br /> BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019<br /> [1136314.265615] RIP: 0010:__xdp_return+0x6c/0x210<br /> [1136314.274653] Code: ad 00 48 8b 47 08 49 89 f8 a8 01 0f 85 9b 01 00 00 0f 1f 44 00 00 f0 41 ff 48 34 75 32 4c 89 c7 e9 79 cd 80 ff 83 fe 03 75 17 41 34 01 0f 85 02 01 00 00 48 89 cf e9 22 cc 1e 00 e9 3d d2 86<br /> [1136314.302907] RSP: 0018:ffffc900089f8db0 EFLAGS: 00010246<br /> [1136314.312967] RAX: ffffc9003168aed0 RBX: ffff8881c3300000 RCX:<br /> 0000000000000000<br /> [1136314.324953] RDX: 0000000000000000 RSI: 0000000000000003 RDI:<br /> ffffc9003168c000<br /> [1136314.336929] RBP: 0000000000000ae0 R08: 0000000000000002 R09:<br /> 0000000000010000<br /> [1136314.348844] R10: ffffc9000e495000 R11: 0000000000000040 R12:<br /> 0000000000000001<br /> [1136314.360706] R13: 0000000000000524 R14: ffffc9003168aec0 R15:<br /> 0000000000000001<br /> [1136314.373298] FS: 00007f8df8bbcb80(0000) GS:ffff8897e0e00000(0000)<br /> knlGS:0000000000000000<br /> [1136314.386105] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [1136314.396532] CR2: 0000000000000034 CR3: 00000001aa912002 CR4:<br /> 00000000007706f0<br /> [1136314.408377] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [1136314.420173] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [1136314.431890] PKRU: 55555554<br /> [1136314.439143] Call Trace:<br /> [1136314.446058] <br /> [1136314.452465] ? __die+0x20/0x70<br /> [1136314.459881] ? page_fault_oops+0x15b/0x440<br /> [1136314.468305] ? exc_page_fault+0x6a/0x150<br /> [1136314.476491] ? asm_exc_page_fault+0x22/0x30<br /> [1136314.484927] ? __xdp_return+0x6c/0x210<br /> [1136314.492863] bpf_xdp_adjust_tail+0x155/0x1d0<br /> [1136314.501269] bpf_prog_ccc47ae29d3b6570_xdp_sock_prog+0x15/0x60<br /> [1136314.511263] ice_clean_rx_irq_zc+0x206/0xc60 [ice]<br /> [1136314.520222] ? ice_xmit_zc+0x6e/0x150 [ice]<br /> [1136314.528506] ice_napi_poll+0x467/0x670 [ice]<br /> [1136314.536858] ? ttwu_do_activate.constprop.0+0x8f/0x1a0<br /> [1136314.546010] __napi_poll+0x29/0x1b0<br /> [1136314.553462] net_rx_action+0x133/0x270<br /> [1136314.561619] __do_softirq+0xbe/0x28e<br /> [1136314.569303] do_softirq+0x3f/0x60<br /> <br /> This comes from __xdp_return() call with xdp_buff argument passed as<br /> NULL which is supposed to be consumed by xsk_buff_free() call.<br /> <br /> To address this properly, in ZC case, a node that represents the frag<br /> being removed has to be pulled out of xskb_list. Introduce<br /> appropriate xsk helpers to do such node operation and use them<br /> accordingly within bpf_xdp_adjust_tail().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs, fscache: Prevent Oops in fscache_put_cache()<br /> <br /> This function dereferences "cache" and then checks if it&amp;#39;s<br /> IS_ERR_OR_NULL(). Check first, then dereference.

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 /> tcp: make sure init the accept_queue&amp;#39;s spinlocks once<br /> <br /> When I run syz&amp;#39;s reproduction C program locally, it causes the following<br /> issue:<br /> pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!<br /> WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)<br /> Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011<br /> RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)<br /> Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7<br /> 30 20 ce 8f e8 ad 56 42 ff 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90<br /> RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908<br /> RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900<br /> RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff<br /> R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000<br /> R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000<br /> FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> _raw_spin_unlock (kernel/locking/spinlock.c:186)<br /> inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)<br /> inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)<br /> tcp_check_req (net/ipv4/tcp_minisocks.c:868)<br /> tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)<br /> ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)<br /> ip_local_deliver_finish (net/ipv4/ip_input.c:234)<br /> __netif_receive_skb_one_core (net/core/dev.c:5529)<br /> process_backlog (./include/linux/rcupdate.h:779)<br /> __napi_poll (net/core/dev.c:6533)<br /> net_rx_action (net/core/dev.c:6604)<br /> __do_softirq (./arch/x86/include/asm/jump_label.h:27)<br /> do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)<br /> <br /> <br /> __local_bh_enable_ip (kernel/softirq.c:381)<br /> __dev_queue_xmit (net/core/dev.c:4374)<br /> ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)<br /> __ip_queue_xmit (net/ipv4/ip_output.c:535)<br /> __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)<br /> tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)<br /> tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)<br /> tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)<br /> __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)<br /> release_sock (net/core/sock.c:3536)<br /> inet_wait_for_connect (net/ipv4/af_inet.c:609)<br /> __inet_stream_connect (net/ipv4/af_inet.c:702)<br /> inet_stream_connect (net/ipv4/af_inet.c:748)<br /> __sys_connect (./include/linux/file.h:45 net/socket.c:2064)<br /> __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)<br /> do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)<br /> RIP: 0033:0x7fa10ff05a3d<br /> Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89<br /> c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d<br /> RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003<br /> RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640<br /> R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20<br /> <br /> <br /> The issue triggering process is analyzed as follows:<br /> Thread A Thread B<br /> tcp_v4_rcv //receive ack TCP packet inet_shutdown<br /> tcp_check_req tcp_disconnect //disconnect sock<br /> ... tcp_set_state(sk, TCP_CLOSE)<br /> inet_csk_complete_hashdance ...<br /> inet_csk_reqsk_queue_add <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix illegal rmb_desc access in SMC-D connection dump<br /> <br /> A crash was found when dumping SMC-D connections. It can be reproduced<br /> by following steps:<br /> <br /> - run nginx/wrk test:<br /> smc_run nginx<br /> smc_run wrk -t 16 -c 1000 -d -H &amp;#39;Connection: Close&amp;#39; <br /> <br /> - continuously dump SMC-D connections in parallel:<br /> watch -n 1 &amp;#39;smcss -D&amp;#39;<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000030<br /> CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55<br /> RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]<br /> Call Trace:<br /> <br /> ? __die+0x24/0x70<br /> ? page_fault_oops+0x66/0x150<br /> ? exc_page_fault+0x69/0x140<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]<br /> ? __kmalloc_node_track_caller+0x35d/0x430<br /> ? __alloc_skb+0x77/0x170<br /> smc_diag_dump_proto+0xd0/0xf0 [smc_diag]<br /> smc_diag_dump+0x26/0x60 [smc_diag]<br /> netlink_dump+0x19f/0x320<br /> __netlink_dump_start+0x1dc/0x300<br /> smc_diag_handler_dump+0x6a/0x80 [smc_diag]<br /> ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]<br /> sock_diag_rcv_msg+0x121/0x140<br /> ? __pfx_sock_diag_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x5a/0x110<br /> sock_diag_rcv+0x28/0x40<br /> netlink_unicast+0x22a/0x330<br /> netlink_sendmsg+0x1f8/0x420<br /> __sock_sendmsg+0xb0/0xc0<br /> ____sys_sendmsg+0x24e/0x300<br /> ? copy_msghdr_from_user+0x62/0x80<br /> ___sys_sendmsg+0x7c/0xd0<br /> ? __do_fault+0x34/0x160<br /> ? do_read_fault+0x5f/0x100<br /> ? do_fault+0xb0/0x110<br /> ? __handle_mm_fault+0x2b0/0x6c0<br /> __sys_sendmsg+0x4d/0x80<br /> do_syscall_64+0x69/0x180<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> It is possible that the connection is in process of being established<br /> when we dump it. Assumed that the connection has been registered in a<br /> link group by smc_conn_create() but the rmb_desc has not yet been<br /> initialized by smc_buf_create(), thus causing the illegal access to<br /> conn-&gt;rmb_desc. So fix it by checking before dump.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: scrub: avoid use-after-free when chunk length is not 64K aligned<br /> <br /> [BUG]<br /> There is a bug report that, on a ext4-converted btrfs, scrub leads to<br /> various problems, including:<br /> <br /> - "unable to find chunk map" errors<br /> BTRFS info (device vdb): scrub: started on devid 1<br /> BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096<br /> BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056<br /> <br /> This would lead to unrepariable errors.<br /> <br /> - Use-after-free KASAN reports:<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x7c0<br /> Read of size 8 at addr ffff8881013c9040 by task btrfs/909<br /> CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-2 12/24/2023<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x43/0x60<br /> print_report+0xcf/0x640<br /> kasan_report+0xa6/0xd0<br /> __blk_rq_map_sg+0x18f/0x7c0<br /> virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]<br /> virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]<br /> blk_mq_flush_plug_list.part.0+0x780/0x860<br /> __blk_flush_plug+0x1ba/0x220<br /> blk_finish_plug+0x3b/0x60<br /> submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> flush_scrub_stripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> __x64_sys_ioctl+0xbd/0x100<br /> do_syscall_64+0x5d/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> RIP: 0033:0x7f47e5e0952b<br /> <br /> - Crash, mostly due to above use-after-free<br /> <br /> [CAUSE]<br /> The converted fs has the following data chunk layout:<br /> <br /> item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80<br /> length 86016 owner 2 stripe_len 65536 type DATA|single<br /> <br /> For above logical bytenr 2214744064, it&amp;#39;s at the chunk end<br /> (2214658048 + 86016 = 2214744064).<br /> <br /> This means btrfs_submit_bio() would split the bio, and trigger endio<br /> function for both of the two halves.<br /> <br /> However scrub_submit_initial_read() would only expect the endio function<br /> to be called once, not any more.<br /> This means the first endio function would already free the bbio::bio,<br /> leaving the bvec freed, thus the 2nd endio call would lead to<br /> use-after-free.<br /> <br /> [FIX]<br /> - Make sure scrub_read_endio() only updates bits in its range<br /> Since we may read less than 64K at the end of the chunk, we should not<br /> touch the bits beyond chunk boundary.<br /> <br /> - Make sure scrub_submit_initial_read() only to read the chunk range<br /> This is done by calculating the real number of sectors we need to<br /> read, and add sector-by-sector to the bio.<br /> <br /> Thankfully the scrub read repair path won&amp;#39;t need extra fixes:<br /> <br /> - scrub_stripe_submit_repair_read()<br /> With above fixes, we won&amp;#39;t update error bit for range beyond chunk,<br /> thus scrub_stripe_submit_repair_read() should never submit any read<br /> beyond the chunk.