Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Fix possible memory leak for rq_wb on add_disk failure<br /> <br /> kmemleak reported memory leaks in device_add_disk():<br /> <br /> kmemleak: 3 new suspected memory leaks<br /> <br /> unreferenced object 0xffff88800f420800 (size 512):<br /> comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s)<br /> hex dump (first 32 bytes):<br /> 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................<br /> 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x26/0x60<br /> [] wbt_init+0x50/0x6f0<br /> [] wbt_enable_default+0x157/0x1c0<br /> [] blk_register_queue+0x2a4/0x420<br /> [] device_add_disk+0x6fd/0xe40<br /> [] nbd_dev_add+0x828/0xbf0 [nbd]<br /> ...<br /> <br /> It is because the memory allocated in wbt_enable_default() is not<br /> released in device_add_disk() error path.<br /> Normally, these memory are freed in:<br /> <br /> del_gendisk()<br /> rq_qos_exit()<br /> rqos-&gt;ops-&gt;exit(rqos);<br /> wbt_exit()<br /> <br /> So rq_qos_exit() is called to free the rq_wb memory for wbt_init().<br /> However in the error path of device_add_disk(), only<br /> blk_unregister_queue() is called and make rq_wb memory leaked.<br /> <br /> Add rq_qos_exit() to the error path to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net, neigh: Fix null-ptr-deref in neigh_table_clear()<br /> <br /> When IPv6 module gets initialized but hits an error in the middle,<br /> kenel panic with:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]<br /> CPU: 1 PID: 361 Comm: insmod<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370<br /> RSP: 0018:ffff888012677908 EFLAGS: 00000202<br /> ...<br /> Call Trace:<br /> <br /> neigh_table_clear+0x94/0x2d0<br /> ndisc_cleanup+0x27/0x40 [ipv6]<br /> inet6_init+0x21c/0x2cb [ipv6]<br /> do_one_initcall+0xd3/0x4d0<br /> do_init_module+0x1ae/0x670<br /> ...<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> When ipv6 initialization fails, it will try to cleanup and calls:<br /> <br /> neigh_table_clear()<br /> neigh_ifdown(tbl, NULL)<br /> pneigh_queue_purge(&amp;tbl-&gt;proxy_queue, dev_net(dev == NULL))<br /> # dev_net(NULL) triggers null-ptr-deref.<br /> <br /> Fix it by passing NULL to pneigh_queue_purge() in neigh_ifdown() if dev<br /> is NULL, to make kernel not panic immediately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: Free rwi on reset success<br /> <br /> Free the rwi structure in the event that the last rwi in the list<br /> processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic:<br /> retry reset if there are no other resets") introduces an issue that<br /> results in a 32 byte memory leak whenever the last rwi in the list<br /> gets processed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix memory leak in vhci_write<br /> <br /> Syzkaller reports a memory leak as follows:<br /> ====================================<br /> BUG: memory leak<br /> unreferenced object 0xffff88810d81ac00 (size 240):<br /> [...]<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 /> [] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418<br /> [] alloc_skb include/linux/skbuff.h:1257 [inline]<br /> [] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [inline]<br /> [] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [inline]<br /> [] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511<br /> [] call_write_iter include/linux/fs.h:2192 [inline]<br /> [] new_sync_write fs/read_write.c:491 [inline]<br /> [] vfs_write+0x42d/0x540 fs/read_write.c:578<br /> [] ksys_write+0x9d/0x160 fs/read_write.c:631<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> ====================================<br /> <br /> HCI core will uses hci_rx_work() to process frame, which is queued to<br /> the hdev-&gt;rx_q tail in hci_recv_frame() by HCI driver.<br /> <br /> Yet the problem is that, HCI core may not free the skb after handling<br /> ACL data packets. To be more specific, when start fragment does not<br /> contain the L2CAP length, HCI core just copies skb into conn-&gt;rx_skb and<br /> finishes frame process in l2cap_recv_acldata(), without freeing the skb,<br /> which triggers the above memory leak.<br /> <br /> This patch solves it by releasing the relative skb, after processing<br /> the above case in l2cap_recv_acldata().