Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs4: Fix kmemleak when allocate slot failed<br /> <br /> If one of the slot allocate failed, should cleanup all the other<br /> allocated slots, otherwise, the allocated slots will leak:<br /> <br /> unreferenced object 0xffff8881115aa100 (size 64):<br /> comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)<br /> hex dump (first 32 bytes):<br /> 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] nfs4_find_or_create_slot+0x8e/0x130<br /> [] nfs4_realloc_slot_table+0x23f/0x270<br /> [] nfs40_init_client+0x4a/0x90<br /> [] nfs4_init_client+0xce/0x270<br /> [] nfs4_set_client+0x1a2/0x2b0<br /> [] nfs4_create_server+0x300/0x5f0<br /> [] nfs4_try_get_tree+0x65/0x110<br /> [] vfs_get_tree+0x41/0xf0<br /> [] path_mount+0x9b3/0xdd0<br /> [] __x64_sys_mount+0x190/0x1d0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed<br /> <br /> There is a null-ptr-deref when xps sysfs alloc failed:<br /> BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0<br /> Read of size 8 at addr 0000000000000030 by task gssproxy/457<br /> <br /> CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> kasan_report+0xa3/0x120<br /> sysfs_do_create_link_sd+0x40/0xd0<br /> rpc_sysfs_client_setup+0x161/0x1b0<br /> rpc_new_client+0x3fc/0x6e0<br /> rpc_create_xprt+0x71/0x220<br /> rpc_create+0x1d4/0x350<br /> gssp_rpc_create+0xc3/0x160<br /> set_gssp_clnt+0xbc/0x140<br /> write_gssp+0x116/0x1a0<br /> proc_reg_write+0xd6/0x130<br /> vfs_write+0x177/0x690<br /> ksys_write+0xb9/0x150<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> When the xprt_switch sysfs alloc failed, should not add xprt and<br /> switch sysfs to it, otherwise, maybe null-ptr-deref; also initialize<br /> the &amp;#39;xps_sysfs&amp;#39; to NULL to avoid oops when destroy it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix NULL pointer problem in free_mr_init()<br /> <br /> Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL<br /> pointer. It should be init mutex_init() first before use the lock.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Call trace:<br /> __mutex_lock.constprop.0+0xd0/0x5c0<br /> __mutex_lock_slowpath+0x1c/0x2c<br /> mutex_lock+0x44/0x50<br /> free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2]<br /> hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2]<br /> hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2]<br /> ib_dereg_mr_user+0x54/0x124<br /> uverbs_free_mr+0x24/0x30<br /> destroy_hw_idr_uobject+0x38/0x74<br /> uverbs_destroy_uobject+0x48/0x1c4<br /> uobj_destroy+0x74/0xcc<br /> ib_uverbs_cmd_verbs+0x368/0xbb0<br /> ib_uverbs_ioctl+0xec/0x1a4<br /> __arm64_sys_ioctl+0xb4/0x100<br /> invoke_syscall+0x50/0x120<br /> el0_svc_common.constprop.0+0x58/0x190<br /> do_el0_svc+0x30/0x90<br /> el0_svc+0x2c/0xb4<br /> el0t_64_sync_handler+0x1a4/0x1b0<br /> el0t_64_sync+0x19c/0x1a0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix mr leak in RESPST_ERR_RNR<br /> <br /> rxe_recheck_mr() will increase mr&amp;#39;s ref_cnt, so we should call rxe_put(mr)<br /> to drop mr&amp;#39;s ref_cnt in RESPST_ERR_RNR to avoid below warning:<br /> <br /> WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxe_pool.c:259 __rxe_cleanup+0x1df/0x240 [rdma_rxe]<br /> ...<br /> Call Trace:<br /> rxe_dereg_mr+0x4c/0x60 [rdma_rxe]<br /> ib_dereg_mr_user+0xa8/0x200 [ib_core]<br /> ib_mr_pool_destroy+0x77/0xb0 [ib_core]<br /> nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma]<br /> nvme_rdma_free_queue+0x40/0x50 [nvme_rdma]<br /> nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma]<br /> nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma]<br /> process_one_work+0x582/0xa40<br /> ? pwq_dec_nr_in_flight+0x100/0x100<br /> ? rwlock_bug.part.0+0x60/0x60<br /> worker_thread+0x2a9/0x700<br /> ? process_one_work+0xa40/0xa40<br /> kthread+0x168/0x1a0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: release flow rule object from commit path<br /> <br /> No need to postpone this to the commit release path, since no packets<br /> are walking over this object, this is accessed from control plane only.<br /> This helped uncovered UAF triggered by races with the netlink notifier.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: netlink notifier might race to release objects<br /> <br /> commit release path is invoked via call_rcu and it runs lockless to<br /> release the objects after rcu grace period. The netlink notifier handler<br /> might win race to remove objects that the transaction context is still<br /> referencing from the commit release path.<br /> <br /> Call rcu_barrier() to ensure pending rcu callbacks run to completion<br /> if the list of transactions to be destroyed is not empty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: Fix use after free in red_enqueue()<br /> <br /> We can&amp;#39;t use "skb" again after passing it to qdisc_enqueue(). This is<br /> basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb<br /> len before calling child enqueue").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()<br /> <br /> nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb<br /> should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()<br /> will only free skb when i2c_master_send() return &gt;=0, which means skb<br /> will memleak when i2c_master_send() failed. Free skb no matter whether<br /> i2c_master_send() succeeds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nxp-nci: Fix potential memory leak in nxp_nci_send()<br /> <br /> nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when<br /> nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()<br /> run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the<br /> result, the skb will memleak. nxp_nci_send() should also free the skb<br /> when nxp_nci_i2c_write() succeeds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: fix WARNING in __ip_vs_cleanup_batch()<br /> <br /> During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn<br /> or ip_vs_conn_sync fails to be created, the initialization is successful<br /> by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn&amp;#39;t<br /> be found during the remove.<br /> <br /> The following is the stack information:<br /> name &amp;#39;ip_vs_conn_sync&amp;#39;<br /> WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712<br /> remove_proc_entry+0x389/0x460<br /> Modules linked in:<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:remove_proc_entry+0x389/0x460<br /> Call Trace:<br /> <br /> __ip_vs_cleanup_batch+0x7d/0x120<br /> ops_exit_list+0x125/0x170<br /> cleanup_net+0x4ea/0xb00<br /> process_one_work+0x9bf/0x1710<br /> worker_thread+0x665/0x1080<br /> kthread+0x2e4/0x3a0<br /> ret_from_fork+0x1f/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: fix possible memory leak in mISDN_register_device()<br /> <br /> Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device&amp;#39;s<br /> bus_id string array"), the name of device is allocated dynamically,<br /> add put_device() to give up the reference, so that the name can be<br /> freed in kobject_cleanup() when the refcount is 0.<br /> <br /> Set device class before put_device() to avoid null release() function<br /> WARN message in device_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rose: Fix NULL pointer dereference in rose_send_frame()<br /> <br /> The syzkaller reported an issue:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]<br /> CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> Workqueue: rcu_gp srcu_invoke_callbacks<br /> RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101<br /> Call Trace:<br /> <br /> rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255<br /> rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009<br /> rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111<br /> call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474<br /> expire_timers kernel/time/timer.c:1519 [inline]<br /> __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790<br /> __run_timers kernel/time/timer.c:1768 [inline]<br /> run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803<br /> __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571<br /> [...]<br /> <br /> <br /> It triggers NULL pointer dereference when &amp;#39;neigh-&gt;dev-&gt;dev_addr&amp;#39; is<br /> called in the rose_send_frame(). It&amp;#39;s the first occurrence of the<br /> `neigh` is in rose_loopback_timer() as `rose_loopback_neigh&amp;#39;, and<br /> the &amp;#39;dev&amp;#39; in &amp;#39;rose_loopback_neigh&amp;#39; is initialized sa nullptr.<br /> <br /> It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf<br /> ("rose: Fix Null pointer dereference in rose_send_frame()") ever.<br /> But it&amp;#39;s introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8<br /> ("rose: check NULL rose_loopback_neigh-&gt;loopback") again.<br /> <br /> We fix it by add NULL check in rose_transmit_clear_request(). When<br /> the &amp;#39;dev&amp;#39; in &amp;#39;neigh&amp;#39; is NULL, we don&amp;#39;t reply the request and just<br /> clear it.<br /> <br /> syzkaller don&amp;#39;t provide repro, and I provide a syz repro like:<br /> r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)<br /> ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &amp;(0x7f0000000180)={&amp;#39;rose0\x00&amp;#39;, 0x201})<br /> r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)<br /> bind$rose(r1, &amp;(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40)<br /> connect$rose(r1, &amp;(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)