Vulnerabilities

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)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: enforce documented limit to prevent allocating huge memory<br /> <br /> Daniel Xu reported that the hash:net,iface type of the ipset subsystem does<br /> not limit adding the same network with different interfaces to a set, which<br /> can lead to huge memory usage or allocation failure.<br /> <br /> The quick reproducer is<br /> <br /> $ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0<br /> $ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done<br /> <br /> The backtrace when vmalloc fails:<br /> <br /> [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages<br /> <br /> [Tue Oct 25 00:13:08 2022] Call Trace:<br /> [Tue Oct 25 00:13:08 2022] <br /> [Tue Oct 25 00:13:08 2022] dump_stack_lvl+0x48/0x60<br /> [Tue Oct 25 00:13:08 2022] warn_alloc+0x155/0x180<br /> [Tue Oct 25 00:13:08 2022] __vmalloc_node_range+0x72a/0x760<br /> [Tue Oct 25 00:13:08 2022] ? hash_netiface4_add+0x7c0/0xb20<br /> [Tue Oct 25 00:13:08 2022] ? __kmalloc_large_node+0x4a/0x90<br /> [Tue Oct 25 00:13:08 2022] kvmalloc_node+0xa6/0xd0<br /> [Tue Oct 25 00:13:08 2022] ? hash_netiface4_resize+0x99/0x710<br /> <br /> <br /> The fix is to enforce the limit documented in the ipset(8) manpage:<br /> <br /> &gt; The internal restriction of the hash:net,iface set type is that the same<br /> &gt; network prefix cannot be stored with more than 64 different interfaces<br /> &gt; in a single set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu<br /> <br /> Fix the race condition between the following two flows that run in<br /> parallel:<br /> <br /> 1. l2cap_reassemble_sdu -&gt; chan-&gt;ops-&gt;recv (l2cap_sock_recv_cb) -&gt;<br /> __sock_queue_rcv_skb.<br /> <br /> 2. bt_sock_recvmsg -&gt; skb_recv_datagram, skb_free_datagram.<br /> <br /> An SKB can be queued by the first flow and immediately dequeued and<br /> freed by the second flow, therefore the callers of l2cap_reassemble_sdu<br /> can&amp;#39;t use the SKB after that function returns. However, some places<br /> continue accessing struct l2cap_ctrl that resides in the SKB&amp;#39;s CB for a<br /> short time after l2cap_reassemble_sdu returns, leading to a<br /> use-after-free condition (the stack trace is below, line numbers for<br /> kernel 5.19.8).<br /> <br /> Fix it by keeping a local copy of struct l2cap_ctrl.<br /> <br /> BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth<br /> Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169<br /> <br /> Workqueue: hci0 hci_rx_work [bluetooth]<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))<br /> print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)<br /> ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth<br /> kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)<br /> ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth<br /> l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth<br /> l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth<br /> ret_from_fork (arch/x86/entry/entry_64.S:306)<br /> <br /> <br /> Allocated by task 43169:<br /> kasan_save_stack (mm/kasan/common.c:39)<br /> __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)<br /> kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)<br /> __alloc_skb (net/core/skbuff.c:414)<br /> l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth<br /> l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth<br /> hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth<br /> process_one_work (kernel/workqueue.c:2289)<br /> worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)<br /> kthread (kernel/kthread.c:376)<br /> ret_from_fork (arch/x86/entry/entry_64.S:306)<br /> <br /> Freed by task 27920:<br /> kasan_save_stack (mm/kasan/common.c:39)<br /> kasan_set_track (mm/kasan/common.c:45)<br /> kasan_set_free_info (mm/kasan/generic.c:372)<br /> ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)<br /> slab_free_freelist_hook (mm/slub.c:1780)<br /> kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)<br /> skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)<br /> bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth<br /> l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth<br /> sock_read_iter (net/socket.c:1087)<br /> new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)<br /> vfs_read (fs/read_write.c:482)<br /> ksys_read (fs/read_write.c:620)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix inode list leak during backref walking at find_parent_nodes()<br /> <br /> During backref walking, at find_parent_nodes(), if we are dealing with a<br /> data extent and we get an error while resolving the indirect backrefs, at<br /> resolve_indirect_refs(), or in the while loop that iterates over the refs<br /> in the direct refs rbtree, we end up leaking the inode lists attached to<br /> the direct refs we have in the direct refs rbtree that were not yet added<br /> to the refs ulist passed as argument to find_parent_nodes(). Since they<br /> were not yet added to the refs ulist and prelim_release() does not free<br /> the lists, on error the caller can only free the lists attached to the<br /> refs that were added to the refs ulist, all the remaining refs get their<br /> inode lists never freed, therefore leaking their memory.<br /> <br /> Fix this by having prelim_release() always free any attached inode list<br /> to each ref found in the rbtree, and have find_parent_nodes() set the<br /> ref&amp;#39;s inode list to NULL once it transfers ownership of the inode list<br /> to a ref added to the refs ulist passed to find_parent_nodes().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix ulist leaks in error paths of qgroup self tests<br /> <br /> In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests,<br /> if we fail to add the tree ref, remove the extent item or remove the<br /> extent ref, we are returning from the test function without freeing the<br /> "old_roots" ulist that was allocated by the previous calls to<br /> btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: fix WARNING in ip_vs_app_net_cleanup()<br /> <br /> During the initialization of ip_vs_app_net_init(), if file ip_vs_app<br /> fails to be created, the initialization is successful by default.<br /> Therefore, the ip_vs_app file doesn&amp;#39;t be found during the remove in<br /> ip_vs_app_net_cleanup(). It will cause WRNING.<br /> <br /> The following is the stack information:<br /> name &amp;#39;ip_vs_app&amp;#39;<br /> WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 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 /> 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 /> btrfs: fix inode list leak during backref walking at resolve_indirect_refs()<br /> <br /> During backref walking, at resolve_indirect_refs(), if we get an error<br /> we jump to the &amp;#39;out&amp;#39; label and call ulist_free() on the &amp;#39;parents&amp;#39; ulist,<br /> which frees all the elements in the ulist - however that does not free<br /> any inode lists that may be attached to elements, through the &amp;#39;aux&amp;#39; field<br /> of a ulist node, so we end up leaking lists if we have any attached to<br /> the unodes.<br /> <br /> Fix this by calling free_leaf_list() instead of ulist_free() when we exit<br /> from resolve_indirect_refs(). The static function free_leaf_list() is<br /> moved up for this to be possible and it&amp;#39;s slightly simplified by removing<br /> unnecessary code.

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 /> blk-mq: Fix kmemleak in blk_mq_init_allocated_queue<br /> <br /> There is a kmemleak caused by modprobe null_blk.ko<br /> <br /> unreferenced object 0xffff8881acb1f000 (size 1024):<br /> comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S......<br /> backtrace:<br /> [] kmalloc_node_trace+0x22/0x60<br /> [] blk_mq_alloc_and_init_hctx+0x289/0x350<br /> [] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0<br /> [] blk_mq_init_allocated_queue+0x48c/0x1440<br /> [] __blk_mq_alloc_disk+0xc8/0x1c0<br /> [] 0xffffffffc450d69d<br /> [] 0xffffffffc4538392<br /> [] do_one_initcall+0xd0/0x4f0<br /> [] do_init_module+0x1a4/0x680<br /> [] load_module+0x6249/0x7110<br /> [] __do_sys_finit_module+0x140/0x200<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> That is because q-&gt;ma_ops is set to NULL before blk_release_queue is<br /> called.<br /> <br /> blk_mq_init_queue_data<br /> blk_mq_init_allocated_queue<br /> blk_mq_realloc_hw_ctxs<br /> for (i = 0; i nr_hw_queues; i++) {<br /> old_hctx = xa_load(&amp;q-&gt;hctx_table, i);<br /> if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1]<br /> if (!old_hctx)<br /> break;<br /> <br /> xa_for_each_start(&amp;q-&gt;hctx_table, j, hctx, j)<br /> blk_mq_exit_hctx(q, set, hctx, j); [2]<br /> <br /> if (!q-&gt;nr_hw_queues) [3]<br /> goto err_hctxs;<br /> <br /> err_exit:<br /> q-&gt;mq_ops = NULL; [4]<br /> <br /> blk_put_queue<br /> blk_release_queue<br /> if (queue_is_mq(q)) [5]<br /> blk_mq_release(q);<br /> <br /> [1]: blk_mq_alloc_and_init_hctx failed at i != 0.<br /> [2]: The hctxs allocated by [1] are moved to q-&gt;unused_hctx_list and<br /> will be cleaned up in blk_mq_release.<br /> [3]: q-&gt;nr_hw_queues is 0.<br /> [4]: Set q-&gt;mq_ops to NULL.<br /> [5]: queue_is_mq returns false due to [4]. And blk_mq_release<br /> will not be called. The hctxs in q-&gt;unused_hctx_list are leaked.<br /> <br /> To fix it, call blk_release_queue in exception path.