Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stream: purge sk_error_queue in sk_stream_kill_queues()<br /> <br /> Changheon Lee reported TCP socket leaks, with a nice repro.<br /> <br /> It seems we leak TCP sockets with the following sequence:<br /> <br /> 1) SOF_TIMESTAMPING_TX_ACK is enabled on the socket.<br /> <br /> Each ACK will cook an skb put in error queue, from __skb_tstamp_tx().<br /> __skb_tstamp_tx() is using skb_clone(), unless<br /> SOF_TIMESTAMPING_OPT_TSONLY was also requested.<br /> <br /> 2) If the application is also using MSG_ZEROCOPY, then we put in the<br /> error queue cloned skbs that had a struct ubuf_info attached to them.<br /> <br /> Whenever an struct ubuf_info is allocated, sock_zerocopy_alloc()<br /> does a sock_hold().<br /> <br /> As long as the cloned skbs are still in sk_error_queue,<br /> socket refcount is kept elevated.<br /> <br /> 3) Application closes the socket, while error queue is not empty.<br /> <br /> Since tcp_close() no longer purges the socket error queue,<br /> we might end up with a TCP socket with at least one skb in<br /> error queue keeping the socket alive forever.<br /> <br /> This bug can be (ab)used to consume all kernel memory<br /> and freeze the host.<br /> <br /> We need to purge the error queue, with proper synchronization<br /> against concurrent writers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: fix potential buffer head reference count leak<br /> <br /> As in &amp;#39;jbd2_fc_wait_bufs&amp;#39; if buffer isn&amp;#39;t uptodate, will return -EIO without<br /> update &amp;#39;journal-&gt;j_fc_off&amp;#39;. But &amp;#39;jbd2_fc_release_bufs&amp;#39; will release buffer head<br /> from ‘j_fc_off - 1’ if &amp;#39;bh&amp;#39; is NULL will terminal release which will lead to<br /> buffer head buffer head reference count leak.<br /> To solve above issue, update &amp;#39;journal-&gt;j_fc_off&amp;#39; before return -EIO.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: snic: Fix possible UAF in snic_tgt_create()<br /> <br /> Smatch reports a warning as follows:<br /> <br /> drivers/scsi/snic/snic_disc.c:307 snic_tgt_create() warn:<br /> &amp;#39;&amp;tgt-&gt;list&amp;#39; not removed from list<br /> <br /> If device_add() fails in snic_tgt_create(), tgt will be freed, but<br /> tgt-&gt;list will not be removed from snic-&gt;disc.tgt_list, then list traversal<br /> may cause UAF.<br /> <br /> Remove from snic-&gt;disc.tgt_list before free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add overflow check for attribute size<br /> <br /> The offset addition could overflow and pass the used size check given an<br /> attribute with very large size (e.g., 0xffffff7f) while parsing MFT<br /> attributes. This could lead to out-of-bound memory R/W if we try to<br /> access the next attribute derived by Add2Ptr(attr, asize)<br /> <br /> [ 32.963847] BUG: unable to handle page fault for address: ffff956a83c76067<br /> [ 32.964301] #PF: supervisor read access in kernel mode<br /> [ 32.964526] #PF: error_code(0x0000) - not-present page<br /> [ 32.964893] PGD 4dc01067 P4D 4dc01067 PUD 0<br /> [ 32.965316] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 32.965727] CPU: 0 PID: 243 Comm: mount Not tainted 5.19.0+ #6<br /> [ 32.966050] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 32.966628] RIP: 0010:mi_enum_attr+0x44/0x110<br /> [ 32.967239] Code: 89 f0 48 29 c8 48 89 c1 39 c7 0f 86 94 00 00 00 8b 56 04 83 fa 17 0f 86 88 00 00 00 89 d0 01 ca 48 01 f0 8d 4a 08 39 f9a<br /> [ 32.968101] RSP: 0018:ffffba15c06a7c38 EFLAGS: 00000283<br /> [ 32.968364] RAX: ffff956a83c76067 RBX: ffff956983c76050 RCX: 000000000000006f<br /> [ 32.968651] RDX: 0000000000000067 RSI: ffff956983c760e8 RDI: 00000000000001c8<br /> [ 32.968963] RBP: ffffba15c06a7c38 R08: 0000000000000064 R09: 00000000ffffff7f<br /> [ 32.969249] R10: 0000000000000007 R11: ffff956983c760e8 R12: ffff95698225e000<br /> [ 32.969870] R13: 0000000000000000 R14: ffffba15c06a7cd8 R15: ffff95698225e170<br /> [ 32.970655] FS: 00007fdab8189e40(0000) GS:ffff9569fdc00000(0000) knlGS:0000000000000000<br /> [ 32.971098] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 32.971378] CR2: ffff956a83c76067 CR3: 0000000002c58000 CR4: 00000000000006f0<br /> [ 32.972098] Call Trace:<br /> [ 32.972842] <br /> [ 32.973341] ni_enum_attr_ex+0xda/0xf0<br /> [ 32.974087] ntfs_iget5+0x1db/0xde0<br /> [ 32.974386] ? slab_post_alloc_hook+0x53/0x270<br /> [ 32.974778] ? ntfs_fill_super+0x4c7/0x12a0<br /> [ 32.975115] ntfs_fill_super+0x5d6/0x12a0<br /> [ 32.975336] get_tree_bdev+0x175/0x270<br /> [ 32.975709] ? put_ntfs+0x150/0x150<br /> [ 32.975956] ntfs_fs_get_tree+0x15/0x20<br /> [ 32.976191] vfs_get_tree+0x2a/0xc0<br /> [ 32.976374] ? capable+0x19/0x20<br /> [ 32.976572] path_mount+0x484/0xaa0<br /> [ 32.977025] ? putname+0x57/0x70<br /> [ 32.977380] do_mount+0x80/0xa0<br /> [ 32.977555] __x64_sys_mount+0x8b/0xe0<br /> [ 32.978105] do_syscall_64+0x3b/0x90<br /> [ 32.978830] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 32.979311] RIP: 0033:0x7fdab72e948a<br /> [ 32.980015] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 32.981251] RSP: 002b:00007ffd15b87588 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5<br /> [ 32.981832] RAX: ffffffffffffffda RBX: 0000557de0aaf060 RCX: 00007fdab72e948a<br /> [ 32.982234] RDX: 0000557de0aaf260 RSI: 0000557de0aaf2e0 RDI: 0000557de0ab7ce0<br /> [ 32.982714] RBP: 0000000000000000 R08: 0000557de0aaf280 R09: 0000000000000020<br /> [ 32.983046] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000557de0ab7ce0<br /> [ 32.983494] R13: 0000557de0aaf260 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 32.984094] <br /> [ 32.984352] Modules linked in:<br /> [ 32.984753] CR2: ffff956a83c76067<br /> [ 32.985911] ---[ end trace 0000000000000000 ]---<br /> [ 32.986555] RIP: 0010:mi_enum_attr+0x44/0x110<br /> [ 32.987217] Code: 89 f0 48 29 c8 48 89 c1 39 c7 0f 86 94 00 00 00 8b 56 04 83 fa 17 0f 86 88 00 00 00 89 d0 01 ca 48 01 f0 8d 4a 08 39 f9a<br /> [ 32.988232] RSP: 0018:ffffba15c06a7c38 EFLAGS: 00000283<br /> [ 32.988532] RAX: ffff956a83c76067 RBX: ffff956983c76050 RCX: 000000000000006f<br /> [ 32.988916] RDX: 0000000000000067 RSI: ffff956983c760e8 RDI: 00000000000001c8<br /> [ 32.989356] RBP: ffffba15c06a7c38 R08: 0000000000000064 R09: 00000000ffffff7f<br /> [ 32.989994] R10: 0000000000000007 R11: ffff956983c760e8 R12: ffff95698225e000<br /> [ 32.990415] R13: 0000000000000000 R14: ffffba15c06a7cd8 R15: ffff95698225e170<br /> [ 32.991011] FS: <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: Check whether transferred 2D BO is shmem<br /> <br /> Transferred 2D BO always must be a shmem BO. Add check for that to prevent<br /> NULL dereference if userspace passes a VRAM BO.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm clone: Fix UAF in clone_dtr()<br /> <br /> Dm_clone also has the same UAF problem when dm_resume()<br /> and dm_destroy() are concurrent.<br /> <br /> Therefore, cancelling timer again in clone_dtr().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipu3-imgu: Fix NULL pointer dereference in imgu_subdev_set_selection()<br /> <br /> Calling v4l2_subdev_get_try_crop() and v4l2_subdev_get_try_compose()<br /> with a subdev state of NULL leads to a NULL pointer dereference. This<br /> can currently happen in imgu_subdev_set_selection() when the state<br /> passed in is NULL, as this method first gets pointers to both the "try"<br /> and "active" states and only then decides which to use.<br /> <br /> The same issue has been addressed for imgu_subdev_get_selection() with<br /> commit 30d03a0de650 ("ipu3-imgu: Fix NULL pointer dereference in active<br /> selection access"). However the issue still persists in<br /> imgu_subdev_set_selection().<br /> <br /> Therefore, apply a similar fix as done in the aforementioned commit to<br /> imgu_subdev_set_selection(). To keep things a bit cleaner, introduce<br /> helper functions for "crop" and "compose" access and use them in both<br /> imgu_subdev_set_selection() and imgu_subdev_get_selection().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix memory leak in lpfc_create_port()<br /> <br /> Commit 5e633302ace1 ("scsi: lpfc: vmid: Add support for VMID in mailbox<br /> command") introduced allocations for the VMID resources in<br /> lpfc_create_port() after the call to scsi_host_alloc(). Upon failure on the<br /> VMID allocations, the new code would branch to the &amp;#39;out&amp;#39; label, which<br /> returns NULL without unwinding anything, thus skipping the call to<br /> scsi_host_put().<br /> <br /> Fix the problem by creating a separate label &amp;#39;out_free_vmid&amp;#39; to unwind the<br /> VMID resources and make the &amp;#39;out_put_shost&amp;#39; label call only<br /> scsi_host_put(), as was done before the introduction of allocations for<br /> VMID.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: zynqmp: Fix stack-out-of-bounds in strncpy`<br /> <br /> "BUG: KASAN: stack-out-of-bounds in strncpy+0x30/0x68"<br /> <br /> Linux-ATF interface is using 16 bytes of SMC payload. In case clock name is<br /> longer than 15 bytes, string terminated NULL character will not be received<br /> by Linux. Add explicit NULL character at last byte to fix issues when clock<br /> name is longer.<br /> <br /> This fixes below bug reported by KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: stack-out-of-bounds in strncpy+0x30/0x68<br /> Read of size 1 at addr ffff0008c89a7410 by task swapper/0/1<br /> <br /> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.0-00396-g81ef9e7-dirty #3<br /> Hardware name: Xilinx Versal vck190 Eval board revA (QSPI) (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x1e8<br /> show_stack+0x14/0x20<br /> dump_stack+0xd4/0x108<br /> print_address_description.isra.0+0xbc/0x37c<br /> __kasan_report+0x144/0x198<br /> kasan_report+0xc/0x18<br /> __asan_load1+0x5c/0x68<br /> strncpy+0x30/0x68<br /> zynqmp_clock_probe+0x238/0x7b8<br /> platform_drv_probe+0x6c/0xc8<br /> really_probe+0x14c/0x418<br /> driver_probe_device+0x74/0x130<br /> __device_attach_driver+0xc4/0xe8<br /> bus_for_each_drv+0xec/0x150<br /> __device_attach+0x160/0x1d8<br /> device_initial_probe+0x10/0x18<br /> bus_probe_device+0xe0/0xf0<br /> device_add+0x528/0x950<br /> of_device_add+0x5c/0x80<br /> of_platform_device_create_pdata+0x120/0x168<br /> of_platform_bus_create+0x244/0x4e0<br /> of_platform_populate+0x50/0xe8<br /> zynqmp_firmware_probe+0x370/0x3a8<br /> platform_drv_probe+0x6c/0xc8<br /> really_probe+0x14c/0x418<br /> driver_probe_device+0x74/0x130<br /> device_driver_attach+0x94/0xa0<br /> __driver_attach+0x70/0x108<br /> bus_for_each_dev+0xe4/0x158<br /> driver_attach+0x30/0x40<br /> bus_add_driver+0x21c/0x2b8<br /> driver_register+0xbc/0x1d0<br /> __platform_driver_register+0x7c/0x88<br /> zynqmp_firmware_driver_init+0x1c/0x24<br /> do_one_initcall+0xa4/0x234<br /> kernel_init_freeable+0x1b0/0x24c<br /> kernel_init+0x10/0x110<br /> ret_from_fork+0x10/0x18<br /> <br /> The buggy address belongs to the page:<br /> page:ffff0008f9be1c88 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0<br /> raw: 0008d00000000000 ffff0008f9be1c90 ffff0008f9be1c90 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff<br /> page dumped because: kasan: bad access detected<br /> <br /> addr ffff0008c89a7410 is located in stack of task swapper/0/1 at offset 112 in frame:<br /> zynqmp_clock_probe+0x0/0x7b8<br /> <br /> this frame has 3 objects:<br /> [32, 44) &amp;#39;response&amp;#39;<br /> [64, 80) &amp;#39;ret_payload&amp;#39;<br /> [96, 112) &amp;#39;name&amp;#39;<br /> <br /> Memory state around the buggy address:<br /> ffff0008c89a7300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff0008c89a7380: 00 00 00 00 f1 f1 f1 f1 00 04 f2 f2 00 00 f2 f2<br /> &gt;ffff0008c89a7400: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00<br /> ^<br /> ffff0008c89a7480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff0008c89a7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: hif_usb: Fix use-after-free in ath9k_hif_usb_reg_in_cb()<br /> <br /> It is possible that skb is freed in ath9k_htc_rx_msg(), then<br /> usb_submit_urb() fails and we try to free skb again. It causes<br /> use-after-free bug. Moreover, if alloc_skb() fails, urb-&gt;context becomes<br /> NULL but rx_buf is not freed and there can be a memory leak.<br /> <br /> The patch removes unnecessary nskb and makes skb processing more clear: it<br /> is supposed that ath9k_htc_rx_msg() either frees old skb or passes its<br /> managing to another callback function.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> auxdisplay: hd44780: Fix potential memory leak in hd44780_remove()<br /> <br /> hd44780_probe() allocates a memory chunk for hd with kzalloc() and<br /> makes "lcd-&gt;drvdata-&gt;hd44780" point to it. When we call hd44780_remove(),<br /> we should release all relevant memory and resource. But "lcd-&gt;drvdata<br /> -&gt;hd44780" is not released, which will lead to a memory leak.<br /> <br /> We should release the "lcd-&gt;drvdata-&gt;hd44780" in hd44780_remove() to fix<br /> the memory leak bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix potential memory leak in wilc_mac_xmit()<br /> <br /> The wilc_mac_xmit() returns NETDEV_TX_OK without freeing skb, add<br /> dev_kfree_skb() to fix it. Compile tested only.