Vulnerabilities

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 /> Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del()<br /> <br /> When l2cap_recv_frame() is invoked to receive data, and the cid is<br /> L2CAP_CID_A2MP, if the channel does not exist, it will create a channel.<br /> However, after a channel is created, the hold operation of the channel<br /> is not performed. In this case, the value of channel reference counting<br /> is 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del()<br /> invokes the close hook function of A2MP to release the channel. Then<br /> l2cap_chan_unlock(chan) will trigger UAF issue.<br /> <br /> The process is as follows:<br /> Receive data:<br /> l2cap_data_channel()<br /> a2mp_channel_create() ---&gt;channel ref is 2<br /> l2cap_chan_put() ---&gt;channel ref is 1<br /> <br /> Triger event:<br /> hci_error_reset()<br /> hci_dev_do_close()<br /> ...<br /> l2cap_disconn_cfm()<br /> l2cap_conn_del()<br /> l2cap_chan_hold() ---&gt;channel ref is 2<br /> l2cap_chan_del() ---&gt;channel ref is 1<br /> a2mp_chan_close_cb() ---&gt;channel ref is 0, release channel<br /> l2cap_chan_unlock() ---&gt;UAF of channel<br /> <br /> The detailed Call Trace is as follows:<br /> BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0xa6/0x5e0<br /> Read of size 8 at addr ffff8880160664b8 by task kworker/u11:1/7593<br /> Workqueue: hci0 hci_error_reset<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xcd/0x134<br /> print_report.cold+0x2ba/0x719<br /> kasan_report+0xb1/0x1e0<br /> kasan_check_range+0x140/0x190<br /> __mutex_unlock_slowpath+0xa6/0x5e0<br /> l2cap_conn_del+0x404/0x7b0<br /> l2cap_disconn_cfm+0x8c/0xc0<br /> hci_conn_hash_flush+0x11f/0x260<br /> hci_dev_close_sync+0x5f5/0x11f0<br /> hci_dev_do_close+0x2d/0x70<br /> hci_error_reset+0x9e/0x140<br /> process_one_work+0x98a/0x1620<br /> worker_thread+0x665/0x1080<br /> kthread+0x2e4/0x3a0<br /> ret_from_fork+0x1f/0x30<br /> <br /> <br /> Allocated by task 7593:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0xa9/0xd0<br /> l2cap_chan_create+0x40/0x930<br /> amp_mgr_create+0x96/0x990<br /> a2mp_channel_create+0x7d/0x150<br /> l2cap_recv_frame+0x51b8/0x9a70<br /> l2cap_recv_acldata+0xaa3/0xc00<br /> hci_rx_work+0x702/0x1220<br /> process_one_work+0x98a/0x1620<br /> worker_thread+0x665/0x1080<br /> kthread+0x2e4/0x3a0<br /> ret_from_fork+0x1f/0x30<br /> <br /> Freed by task 7593:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_set_free_info+0x20/0x30<br /> ____kasan_slab_free+0x167/0x1c0<br /> slab_free_freelist_hook+0x89/0x1c0<br /> kfree+0xe2/0x580<br /> l2cap_chan_put+0x22a/0x2d0<br /> l2cap_conn_del+0x3fc/0x7b0<br /> l2cap_disconn_cfm+0x8c/0xc0<br /> hci_conn_hash_flush+0x11f/0x260<br /> hci_dev_close_sync+0x5f5/0x11f0<br /> hci_dev_do_close+0x2d/0x70<br /> hci_error_reset+0x9e/0x140<br /> process_one_work+0x98a/0x1620<br /> worker_thread+0x665/0x1080<br /> kthread+0x2e4/0x3a0<br /> ret_from_fork+0x1f/0x30<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_record_aux_stack+0xbe/0xd0<br /> call_rcu+0x99/0x740<br /> netlink_release+0xe6a/0x1cf0<br /> __sock_release+0xcd/0x280<br /> sock_close+0x18/0x20<br /> __fput+0x27c/0xa90<br /> task_work_run+0xdd/0x1a0<br /> exit_to_user_mode_prepare+0x23c/0x250<br /> syscall_exit_to_user_mode+0x19/0x50<br /> do_syscall_64+0x42/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Second to last potentially related work creation:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_record_aux_stack+0xbe/0xd0<br /> call_rcu+0x99/0x740<br /> netlink_release+0xe6a/0x1cf0<br /> __sock_release+0xcd/0x280<br /> sock_close+0x18/0x20<br /> __fput+0x27c/0xa90<br /> task_work_run+0xdd/0x1a0<br /> exit_to_user_mode_prepare+0x23c/0x250<br /> syscall_exit_to_user_mode+0x19/0x50<br /> do_syscall_64+0x42/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: piix4: Fix adapter not be removed in piix4_remove()<br /> <br /> In piix4_probe(), the piix4 adapter will be registered in:<br /> <br /> piix4_probe()<br /> piix4_add_adapters_sb800() / piix4_add_adapter()<br /> i2c_add_adapter()<br /> <br /> Based on the probed device type, piix4_add_adapters_sb800() or single<br /> piix4_add_adapter() will be called.<br /> For the former case, piix4_adapter_count is set as the number of adapters,<br /> while for antoher case it is not set and kept default *zero*.<br /> <br /> When piix4 is removed, piix4_remove() removes the adapters added in<br /> piix4_probe(), basing on the piix4_adapter_count value.<br /> Because the count is zero for the single adapter case, the adapter won&amp;#39;t<br /> be removed and makes the sources allocated for adapter leaked, such as<br /> the i2c client and device.<br /> <br /> These sources can still be accessed by i2c or bus and cause problems.<br /> An easily reproduced case is that if a new adapter is registered, i2c<br /> will get the leaked adapter and try to call smbus_algorithm, which was<br /> already freed:<br /> <br /> Triggered by: rmmod i2c_piix4 &amp;&amp; modprobe max31730<br /> <br /> BUG: unable to handle page fault for address: ffffffffc053d860<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> Oops: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 3752 Comm: modprobe Tainted: G<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core<br /> RSP: 0018:ffff888107477710 EFLAGS: 00000246<br /> ...<br /> <br /> i2c_detect (drivers/i2c/i2c-core-base.c:2302) i2c_core<br /> __process_new_driver (drivers/i2c/i2c-core-base.c:1336) i2c_core<br /> bus_for_each_dev (drivers/base/bus.c:301)<br /> i2c_for_each_dev (drivers/i2c/i2c-core-base.c:1823) i2c_core<br /> i2c_register_driver (drivers/i2c/i2c-core-base.c:1861) i2c_core<br /> do_one_initcall (init/main.c:1296)<br /> do_init_module (kernel/module/main.c:2455)<br /> ...<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Fix this problem by correctly set piix4_adapter_count as 1 for the<br /> single adapter so it can be normally removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix WARNING in ip6_route_net_exit_late()<br /> <br /> During the initialization of ip6_route_net_init_late(), if file<br /> ipv6_route or rt6_stats fails to be created, the initialization is<br /> successful by default. Therefore, the ipv6_route or rt6_stats file<br /> doesn&amp;#39;t be found during the remove in ip6_route_net_exit_late(). It<br /> will cause WRNING.<br /> <br /> The following is the stack information:<br /> name &amp;#39;rt6_stats&amp;#39;<br /> WARNING: CPU: 0 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 /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ops_exit_list+0xb0/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 /> net/smc: Fix possible leaked pernet namespace in smc_init()<br /> <br /> In smc_init(), register_pernet_subsys(&amp;smc_net_stat_ops) is called<br /> without any error handling.<br /> If it fails, registering of &amp;smc_net_ops won&amp;#39;t be reverted.<br /> And if smc_nl_init() fails, &amp;smc_net_stat_ops itself won&amp;#39;t be reverted.<br /> <br /> This leaves wild ops in subsystem linkedlist and when another module<br /> tries to call register_pernet_operations() it triggers page fault:<br /> <br /> BUG: unable to handle page fault for address: fffffbfff81b964c<br /> RIP: 0010:register_pernet_operations+0x1b9/0x5f0<br /> Call Trace:<br /> <br /> register_pernet_subsys+0x29/0x40<br /> ebtables_init+0x58/0x1000 [ebtables]<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mdio: fix undefined behavior in bit shift for __mdiobus_register<br /> <br /> Shifting signed 32-bit value by 31 bits is undefined, so changing<br /> significant bit to unsigned. The UBSAN warning calltrace like below:<br /> <br /> UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27<br /> left shift of 1 by 31 places cannot be represented in type &amp;#39;int&amp;#39;<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7d/0xa5<br /> dump_stack+0x15/0x1b<br /> ubsan_epilogue+0xe/0x4e<br /> __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c<br /> __mdiobus_register+0x49d/0x4e0<br /> fixed_mdio_bus_init+0xd8/0x12d<br /> do_one_initcall+0x76/0x430<br /> kernel_init_freeable+0x3b3/0x422<br /> kernel_init+0x24/0x1e0<br /> ret_from_fork+0x1f/0x30<br />

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().

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 /> 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 /> 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 /> 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.