Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost_vdpa: fix the crash in unmap a large memory<br /> <br /> While testing in vIOMMU, sometimes Guest will unmap very large memory,<br /> which will cause the crash. To fix this, add a new function<br /> vhost_vdpa_general_unmap(). This function will only unmap the memory<br /> that saved in iotlb.<br /> <br /> Call Trace:<br /> [ 647.820144] ------------[ cut here ]------------<br /> [ 647.820848] kernel BUG at drivers/iommu/intel/iommu.c:1174!<br /> [ 647.821486] invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> [ 647.822082] CPU: 10 PID: 1181 Comm: qemu-system-x86 Not tainted 6.0.0-rc1home_lulu_2452_lulu7_vhost+ #62<br /> [ 647.823139] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qem4<br /> [ 647.824365] RIP: 0010:domain_unmap+0x48/0x110<br /> [ 647.825424] Code: 48 89 fb 8d 4c f6 1e 39 c1 0f 4f c8 83 e9 0c 83 f9 3f 7f 18 48 89 e8 48 d3 e8 48 85 c0 75 59<br /> [ 647.828064] RSP: 0018:ffffae5340c0bbf0 EFLAGS: 00010202<br /> [ 647.828973] RAX: 0000000000000001 RBX: ffff921793d10540 RCX: 000000000000001b<br /> [ 647.830083] RDX: 00000000080000ff RSI: 0000000000000001 RDI: ffff921793d10540<br /> [ 647.831214] RBP: 0000000007fc0100 R08: ffffae5340c0bcd0 R09: 0000000000000003<br /> [ 647.832388] R10: 0000007fc0100000 R11: 0000000000100000 R12: 00000000080000ff<br /> [ 647.833668] R13: ffffae5340c0bcd0 R14: ffff921793d10590 R15: 0000008000100000<br /> [ 647.834782] FS: 00007f772ec90640(0000) GS:ffff921ce7a80000(0000) knlGS:0000000000000000<br /> [ 647.836004] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 647.836990] CR2: 00007f02c27a3a20 CR3: 0000000101b0c006 CR4: 0000000000372ee0<br /> [ 647.838107] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 647.839283] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 647.840666] Call Trace:<br /> [ 647.841437] <br /> [ 647.842107] intel_iommu_unmap_pages+0x93/0x140<br /> [ 647.843112] __iommu_unmap+0x91/0x1b0<br /> [ 647.844003] iommu_unmap+0x6a/0x95<br /> [ 647.844885] vhost_vdpa_unmap+0x1de/0x1f0 [vhost_vdpa]<br /> [ 647.845985] vhost_vdpa_process_iotlb_msg+0xf0/0x90b [vhost_vdpa]<br /> [ 647.847235] ? _raw_spin_unlock+0x15/0x30<br /> [ 647.848181] ? _copy_from_iter+0x8c/0x580<br /> [ 647.849137] vhost_chr_write_iter+0xb3/0x430 [vhost]<br /> [ 647.850126] vfs_write+0x1e4/0x3a0<br /> [ 647.850897] ksys_write+0x53/0xd0<br /> [ 647.851688] do_syscall_64+0x3a/0x90<br /> [ 647.852508] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 647.853457] RIP: 0033:0x7f7734ef9f4f<br /> [ 647.854408] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 29 76 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c8<br /> [ 647.857217] RSP: 002b:00007f772ec8f040 EFLAGS: 00000293 ORIG_RAX: 0000000000000001<br /> [ 647.858486] RAX: ffffffffffffffda RBX: 00000000fef00000 RCX: 00007f7734ef9f4f<br /> [ 647.859713] RDX: 0000000000000048 RSI: 00007f772ec8f090 RDI: 0000000000000010<br /> [ 647.860942] RBP: 00007f772ec8f1a0 R08: 0000000000000000 R09: 0000000000000000<br /> [ 647.862206] R10: 0000000000000001 R11: 0000000000000293 R12: 0000000000000010<br /> [ 647.863446] R13: 0000000000000002 R14: 0000000000000000 R15: ffffffff01100000<br /> [ 647.864692] <br /> [ 647.865458] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs v]<br /> [ 647.874688] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix use after free in mt7921_acpi_read()<br /> <br /> Don&amp;#39;t dereference "sar_root" after it has been freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix type of second parameter in odn_edit_dpm_table() callback<br /> <br /> With clang&amp;#39;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),<br /> indirect call targets are validated against the expected function<br /> pointer prototype to make sure the call target is valid to help mitigate<br /> ROP attacks. If they are not identical, there is a failure at run time,<br /> which manifests as either a kernel panic or thread getting killed. A<br /> proposed warning in clang aims to catch these at compile time, which<br /> reveals:<br /> <br /> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpu_smu.c:3008:29: error: incompatible function pointer types initializing &amp;#39;int (*)(void *, uint32_t, long *, uint32_t)&amp;#39; (aka &amp;#39;int (*)(void *, unsigned int, long *, unsigned int)&amp;#39;) with an expression of type &amp;#39;int (void *, enum PP_OD_DPM_TABLE_COMMAND, long *, uint32_t)&amp;#39; (aka &amp;#39;int (void *, enum PP_OD_DPM_TABLE_COMMAND, long *, unsigned int)&amp;#39;) [-Werror,-Wincompatible-function-pointer-types-strict]<br /> .odn_edit_dpm_table = smu_od_edit_dpm_table,<br /> ^~~~~~~~~~~~~~~~~~~~~<br /> 1 error generated.<br /> <br /> There are only two implementations of -&gt;odn_edit_dpm_table() in &amp;#39;struct<br /> amd_pm_funcs&amp;#39;: smu_od_edit_dpm_table() and pp_odn_edit_dpm_table(). One<br /> has a second parameter type of &amp;#39;enum PP_OD_DPM_TABLE_COMMAND&amp;#39; and the<br /> other uses &amp;#39;u32&amp;#39;. Ultimately, smu_od_edit_dpm_table() calls<br /> -&gt;od_edit_dpm_table() from &amp;#39;struct pptable_funcs&amp;#39; and<br /> pp_odn_edit_dpm_table() calls -&gt;odn_edit_dpm_table() from &amp;#39;struct<br /> pp_hwmgr_func&amp;#39;, which both have a second parameter type of &amp;#39;enum<br /> PP_OD_DPM_TABLE_COMMAND&amp;#39;.<br /> <br /> Update the type parameter in both the prototype in &amp;#39;struct amd_pm_funcs&amp;#39;<br /> and pp_odn_edit_dpm_table() to &amp;#39;enum PP_OD_DPM_TABLE_COMMAND&amp;#39;, which<br /> cleans up the warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: add miss release buffer head in fc_do_one_pass()<br /> <br /> In fc_do_one_pass() miss release buffer head after use which will lead<br /> to reference count leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: sysmon: fix memory leak in qcom_add_sysmon_subdev()<br /> <br /> The kfree() should be called when of_irq_get_byname() fails or<br /> devm_request_threaded_irq() fails in qcom_add_sysmon_subdev(),<br /> otherwise there will be a memory leak, so add kfree() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: tag_8021q: avoid leaking ctx on dsa_tag_8021q_register() error path<br /> <br /> If dsa_tag_8021q_setup() fails, for example due to the inability of the<br /> device to install a VLAN, the tag_8021q context of the switch will leak.<br /> Make sure it is freed on the error path.

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