Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: dio: fix possible memory leak in dio_init()<br /> <br /> If device_register() returns error, the &amp;#39;dev&amp;#39; and name needs be<br /> freed. Add a release function, and then call put_device() in the<br /> error path, so the name is freed in kobject_cleanup() and to the<br /> &amp;#39;dev&amp;#39; is freed in release function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP<br /> <br /> An oops can be induced by running &amp;#39;cat /proc/kcore &gt; /dev/null&amp;#39; on<br /> devices using pstore with the ram backend because kmap_atomic() assumes<br /> lowmem pages are accessible with __va().<br /> <br /> Unable to handle kernel paging request at virtual address ffffff807ff2b000<br /> Mem abort info:<br /> ESR = 0x96000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000006<br /> CM = 0, WnR = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000<br /> [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000<br /> Internal error: Oops: 96000006 [#1] PREEMPT SMP<br /> Modules linked in: dm_integrity<br /> CPU: 7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba<br /> Hardware name: Google Lazor (rev3 - 8) (DT)<br /> pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __memcpy+0x110/0x260<br /> lr : vread+0x194/0x294<br /> sp : ffffffc013ee39d0<br /> x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000<br /> x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000<br /> x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21: ffffffc0085a2000<br /> x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60<br /> x14: ffffffffad588000 x13: 0000000000000000 x12: 0000000000000001<br /> x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b<br /> x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 : ffffffc013ee3a78<br /> x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000<br /> Call trace:<br /> __memcpy+0x110/0x260<br /> read_kcore+0x584/0x778<br /> proc_reg_read+0xb4/0xe4<br /> <br /> During early boot, memblock reserves the pages for the ramoops reserved<br /> memory node in DT that would otherwise be part of the direct lowmem<br /> mapping. Pstore&amp;#39;s ram backend reuses those reserved pages to change the<br /> memory type (writeback or non-cached) by passing the pages to vmap()<br /> (see pfn_to_page() usage in persistent_ram_vmap() for more details) with<br /> specific flags. When read_kcore() starts iterating over the vmalloc<br /> region, it runs over the virtual address that vmap() returned for<br /> ramoops. In aligned_vread() the virtual address is passed to<br /> vmalloc_to_page() which returns the page struct for the reserved lowmem<br /> area. That lowmem page is passed to kmap_atomic(), which effectively<br /> calls page_to_virt() that assumes a lowmem page struct must be directly<br /> accessible with __va() and friends. These pages are mapped via vmap()<br /> though, and the lowmem mapping was never made, so accessing them via the<br /> lowmem virtual address oopses like above.<br /> <br /> Let&amp;#39;s side-step this problem by passing VM_IOREMAP to vmap(). This will<br /> tell vread() to not include the ramoops region in the kcore. Instead the<br /> area will look like a bunch of zeros. The alternative is to teach kmap()<br /> about vmalloc areas that intersect with lowmem. Presumably such a change<br /> isn&amp;#39;t a one-liner, and there isn&amp;#39;t much interest in inspecting the<br /> ramoops region in kcore files anyway, so the most expedient route is<br /> taken for now.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ipr: Fix WARNING in ipr_init()<br /> <br /> ipr_init() will not call unregister_reboot_notifier() when<br /> pci_register_driver() fails, which causes a WARNING. Call<br /> unregister_reboot_notifier() when pci_register_driver() fails.<br /> <br /> notifier callback ipr_halt [ipr] already registered<br /> WARNING: CPU: 3 PID: 299 at kernel/notifier.c:29<br /> notifier_chain_register+0x16d/0x230<br /> Modules linked in: ipr(+) xhci_pci_renesas xhci_hcd ehci_hcd usbcore<br /> led_class gpu_sched drm_buddy video wmi drm_ttm_helper ttm<br /> drm_display_helper drm_kms_helper drm drm_panel_orientation_quirks<br /> agpgart cfbft<br /> CPU: 3 PID: 299 Comm: modprobe Tainted: G W<br /> 6.1.0-rc1-00190-g39508d23b672-dirty #332<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:notifier_chain_register+0x16d/0x230<br /> Call Trace:<br /> <br /> __blocking_notifier_chain_register+0x73/0xb0<br /> ipr_init+0x30/0x1000 [ipr]<br /> do_one_initcall+0xdb/0x480<br /> do_init_module+0x1cf/0x680<br /> load_module+0x6a50/0x70a0<br /> __do_sys_finit_module+0x12f/0x1c0<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

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