Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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---

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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.