Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()<br /> <br /> Fix a NULL pointer crash that occurs when we are freeing the socket at the<br /> same time we access it via sysfs.<br /> <br /> The problem is that:<br /> <br /> 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take<br /> the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold()<br /> does a get on the "struct sock".<br /> <br /> 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put<br /> on the "struct socket" and that does __sock_release() which sets the<br /> sock-&gt;ops to NULL.<br /> <br /> 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then<br /> call kernel_getpeername() which accesses the NULL sock-&gt;ops.<br /> <br /> Above we do a get on the "struct sock", but we needed a get on the "struct<br /> socket". Originally, we just held the frwd_lock the entire time but in<br /> commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while<br /> calling getpeername()") we switched to refcount based because the network<br /> layer changed and started taking a mutex in that path, so we could no<br /> longer hold the frwd_lock.<br /> <br /> Instead of trying to maintain multiple refcounts, this just has us use a<br /> mutex for accessing the socket in the interface code paths.

*** 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 /> fs/ntfs3: Fix memory leak on ntfs_fill_super() error path<br /> <br /> syzbot reported kmemleak as below:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8880122f1540 (size 32):<br /> comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s)<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 ed ff ed ff 00 00 00 00 ................<br /> backtrace:<br /> [] ntfs_init_fs_context+0x22/0x1c0<br /> [] alloc_fs_context+0x217/0x430<br /> [] path_mount+0x704/0x1080<br /> [] __x64_sys_mount+0x18c/0x1d0<br /> [] do_syscall_64+0x34/0xb0<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> This patch fixes this issue by freeing mount options on error path of<br /> ntfs_fill_super().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: cake: fix null pointer access issue when cake_init() fails<br /> <br /> When the default qdisc is cake, if the qdisc of dev_queue fails to be<br /> inited during mqprio_init(), cake_reset() is invoked to clear<br /> resources. In this case, the tins is NULL, and it will cause gpf issue.<br /> <br /> The process is as follows:<br /> qdisc_create_dflt()<br /> cake_init()<br /> q-&gt;tins = kvcalloc(...) ---&gt;failed, q-&gt;tins is NULL<br /> ...<br /> qdisc_put()<br /> ...<br /> cake_reset()<br /> ...<br /> cake_dequeue_one()<br /> b = &amp;q-&gt;tins[...] ---&gt;q-&gt;tins is NULL<br /> <br /> The following is the Call Trace information:<br /> general protection fault, probably for non-canonical address<br /> 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:cake_dequeue_one+0xc9/0x3c0<br /> Call Trace:<br /> <br /> cake_reset+0xb1/0x140<br /> qdisc_reset+0xed/0x6f0<br /> qdisc_destroy+0x82/0x4c0<br /> qdisc_put+0x9e/0xb0<br /> qdisc_create_dflt+0x2c3/0x4a0<br /> mqprio_init+0xa71/0x1760<br /> qdisc_create+0x3eb/0x1000<br /> tc_modify_qdisc+0x408/0x1720<br /> rtnetlink_rcv_msg+0x38e/0xac0<br /> netlink_rcv_skb+0x12d/0x3a0<br /> netlink_unicast+0x4a2/0x740<br /> netlink_sendmsg+0x826/0xcc0<br /> sock_sendmsg+0xc5/0x100<br /> ____sys_sendmsg+0x583/0x690<br /> ___sys_sendmsg+0xe8/0x160<br /> __sys_sendmsg+0xbf/0x160<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f89e5122d04<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: cdev: fix NULL-pointer dereferences<br /> <br /> There are several places where we can crash the kernel by requesting<br /> lines, unbinding the GPIO device, then calling any of the system calls<br /> relevant to the GPIO character device&amp;#39;s annonymous file descriptors:<br /> ioctl(), read(), poll().<br /> <br /> While I observed it with the GPIO simulator, it will also happen for any<br /> of the GPIO devices that can be hot-unplugged - for instance any HID GPIO<br /> expander (e.g. CP2112).<br /> <br /> This affects both v1 and v2 uAPI.<br /> <br /> This fixes it partially by checking if gdev-&gt;chip is not NULL but it<br /> doesn&amp;#39;t entirely remedy the situation as we still have a race condition<br /> in which another thread can remove the device after the check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: fix a use-after-free in nouveau_gem_prime_import_sg_table()<br /> <br /> nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code<br /> back to the caller. On failures, ttm will call nouveau_bo_del_ttm() and<br /> free the memory.Thus, when nouveau_bo_init() returns an error, the gem<br /> object has already been released. Then the call to nouveau_bo_ref() will<br /> use the freed "nvbo-&gt;bo" and lead to a use-after-free bug.<br /> <br /> We should delete the call to nouveau_bo_ref() to avoid the use-after-free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix resolving backrefs for inline extent followed by prealloc<br /> <br /> If a file consists of an inline extent followed by a regular or prealloc<br /> extent, then a legitimate attempt to resolve a logical address in the<br /> non-inline region will result in add_all_parents reading the invalid<br /> offset field of the inline extent. If the inline extent item is placed<br /> in the leaf eb s.t. it is the first item, attempting to access the<br /> offset field will not only be meaningless, it will go past the end of<br /> the eb and cause this panic:<br /> <br /> [17.626048] BTRFS warning (device dm-2): bad eb member end: ptr 0x3fd4 start 30834688 member offset 16377 size 8<br /> [17.631693] general protection fault, probably for non-canonical address 0x5088000000000: 0000 [#1] SMP PTI<br /> [17.635041] CPU: 2 PID: 1267 Comm: btrfs Not tainted 5.12.0-07246-g75175d5adc74-dirty #199<br /> [17.637969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [17.641995] RIP: 0010:btrfs_get_64+0xe7/0x110<br /> [17.649890] RSP: 0018:ffffc90001f73a08 EFLAGS: 00010202<br /> [17.651652] RAX: 0000000000000001 RBX: ffff88810c42d000 RCX: 0000000000000000<br /> [17.653921] RDX: 0005088000000000 RSI: ffffc90001f73a0f RDI: 0000000000000001<br /> [17.656174] RBP: 0000000000000ff9 R08: 0000000000000007 R09: c0000000fffeffff<br /> [17.658441] R10: ffffc90001f73790 R11: ffffc90001f73788 R12: ffff888106afe918<br /> [17.661070] R13: 0000000000003fd4 R14: 0000000000003f6f R15: cdcdcdcdcdcdcdcd<br /> [17.663617] FS: 00007f64e7627d80(0000) GS:ffff888237c80000(0000) knlGS:0000000000000000<br /> [17.666525] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [17.668664] CR2: 000055d4a39152e8 CR3: 000000010c596002 CR4: 0000000000770ee0<br /> [17.671253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [17.673634] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [17.676034] PKRU: 55555554<br /> [17.677004] Call Trace:<br /> [17.677877] add_all_parents+0x276/0x480<br /> [17.679325] find_parent_nodes+0xfae/0x1590<br /> [17.680771] btrfs_find_all_leafs+0x5e/0xa0<br /> [17.682217] iterate_extent_inodes+0xce/0x260<br /> [17.683809] ? btrfs_inode_flags_to_xflags+0x50/0x50<br /> [17.685597] ? iterate_inodes_from_logical+0xa1/0xd0<br /> [17.687404] iterate_inodes_from_logical+0xa1/0xd0<br /> [17.689121] ? btrfs_inode_flags_to_xflags+0x50/0x50<br /> [17.691010] btrfs_ioctl_logical_to_ino+0x131/0x190<br /> [17.692946] btrfs_ioctl+0x104a/0x2f60<br /> [17.694384] ? selinux_file_ioctl+0x182/0x220<br /> [17.695995] ? __x64_sys_ioctl+0x84/0xc0<br /> [17.697394] __x64_sys_ioctl+0x84/0xc0<br /> [17.698697] do_syscall_64+0x33/0x40<br /> [17.700017] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [17.701753] RIP: 0033:0x7f64e72761b7<br /> [17.709355] RSP: 002b:00007ffefb067f58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> [17.712088] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f64e72761b7<br /> [17.714667] RDX: 00007ffefb067fb0 RSI: 00000000c0389424 RDI: 0000000000000003<br /> [17.717386] RBP: 00007ffefb06d188 R08: 000055d4a390d2b0 R09: 00007f64e7340a60<br /> [17.719938] R10: 0000000000000231 R11: 0000000000000246 R12: 0000000000000001<br /> [17.722383] R13: 0000000000000000 R14: 00000000c0389424 R15: 000055d4a38fd2a0<br /> [17.724839] Modules linked in:<br /> <br /> Fix the bug by detecting the inline extent item in add_all_parents and<br /> skipping to the next extent item.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: core: Fix refcount error in del_mtd_device()<br /> <br /> del_mtd_device() will call of_node_put() to mtd_get_of_node(mtd), which<br /> is mtd-&gt;dev.of_node. However, memset(&amp;mtd-&gt;dev, 0) is called before<br /> of_node_put(). As the result, of_node_put() won&amp;#39;t do anything in<br /> del_mtd_device(), and causes the refcount leak.<br /> <br /> del_mtd_device()<br /> memset(&amp;mtd-&gt;dev, 0, sizeof(mtd-&gt;dev) # clear mtd-&gt;dev<br /> of_node_put()<br /> mtd_get_of_node(mtd) # mtd-&gt;dev is cleared, can&amp;#39;t locate of_node<br /> # of_node_put(NULL) won&amp;#39;t do anything<br /> <br /> Fix the error by caching the pointer of the device_node.<br /> <br /> OF: ERROR: memory leak, expected refcount 1 instead of 2,<br /> of_node_get()/of_node_put() unbalanced - destroy cset entry: attach<br /> overlay node /spi/spi-sram@0<br /> CPU: 3 PID: 275 Comm: python3 Tainted: G N 6.1.0-rc3+ #54<br /> 0d8a1edddf51f172ff5226989a7565c6313b08e2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x67/0x83<br /> kobject_get+0x155/0x160<br /> of_node_get+0x1f/0x30<br /> of_fwnode_get+0x43/0x70<br /> fwnode_handle_get+0x54/0x80<br /> fwnode_get_nth_parent+0xc9/0xe0<br /> fwnode_full_name_string+0x3f/0xa0<br /> device_node_string+0x30f/0x750<br /> pointer+0x598/0x7a0<br /> vsnprintf+0x62d/0x9b0<br /> ...<br /> cfs_overlay_release+0x30/0x90<br /> config_item_release+0xbe/0x1a0<br /> config_item_put+0x5e/0x80<br /> configfs_rmdir+0x3bd/0x540<br /> vfs_rmdir+0x18c/0x320<br /> do_rmdir+0x198/0x330<br /> __x64_sys_rmdir+0x2c/0x40<br /> do_syscall_64+0x37/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> [: Light reword of the commit log]

*** 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 /> ARC: mm: fix leakage of memory allocated for PTE<br /> <br /> Since commit d9820ff ("ARC: mm: switch pgtable_t back to struct page *")<br /> a memory leakage problem occurs. Memory allocated for page table entries<br /> not released during process termination. This issue can be reproduced by<br /> a small program that allocates a large amount of memory. After several<br /> runs, you&amp;#39;ll see that the amount of free memory has reduced and will<br /> continue to reduce after each run. All ARC CPUs are effected by this<br /> issue. The issue was introduced since the kernel stable release v5.15-rc1.<br /> <br /> As described in commit d9820ff after switch pgtable_t back to struct<br /> page *, a pointer to "struct page" and appropriate functions are used to<br /> allocate and free a memory page for PTEs, but the pmd_pgtable macro hasn&amp;#39;t<br /> changed and returns the direct virtual address from the PMD (PGD) entry.<br /> Than this address used as a parameter in the __pte_free() and as a result<br /> this function couldn&amp;#39;t release memory page allocated for PTEs.<br /> <br /> Fix this issue by changing the pmd_pgtable macro and returning pointer to<br /> struct page.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_conn: Fix crash on hci_create_cis_sync<br /> <br /> When attempting to connect multiple ISO sockets without using<br /> DEFER_SETUP may result in the following crash:<br /> <br /> BUG: KASAN: null-ptr-deref in hci_create_cis_sync+0x18b/0x2b0<br /> Read of size 2 at addr 0000000000000036 by task kworker/u3:1/50<br /> <br /> CPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted<br /> 6.0.0-rc7-02243-gb84a13ff4eda #4373<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),<br /> BIOS 1.16.0-1.fc36 04/01/2014<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x19/0x27<br /> kasan_report+0xbc/0xf0<br /> ? hci_create_cis_sync+0x18b/0x2b0<br /> hci_create_cis_sync+0x18b/0x2b0<br /> ? get_link_mode+0xd0/0xd0<br /> ? __ww_mutex_lock_slowpath+0x10/0x10<br /> ? mutex_lock+0xe0/0xe0<br /> ? get_link_mode+0xd0/0xd0<br /> hci_cmd_sync_work+0x111/0x190<br /> process_one_work+0x427/0x650<br /> worker_thread+0x87/0x750<br /> ? process_one_work+0x650/0x650<br /> kthread+0x14e/0x180<br /> ? kthread_exit+0x50/0x50<br /> ret_from_fork+0x22/0x30<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/uffd: fix warning without PTE_MARKER_UFFD_WP compiled in<br /> <br /> When PTE_MARKER_UFFD_WP not configured, it&amp;#39;s still possible to reach pte<br /> marker code and trigger an warning. Add a few CONFIG_PTE_MARKER_UFFD_WP<br /> ifdefs to make sure the code won&amp;#39;t be reached when not compiled in.