CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52618 – block/rnbd-srv: Check for unlikely string overflow
https://notcve.org/view.php?id=CVE-2023-52618
In the Linux kernel, the following vulnerability has been resolved: block/rnbd-srv: Check for unlikely string overflow Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: block/rnbd-srv: Comprueba si hay un desbordamiento de cadena improbable. Dado que "dev_search_path" técnicamente puede ser tan grande como PATH_MAX, existía el riesgo de truncamiento al copiarlo y una segunda cadena en " full_path" ya que también tenía un tamaño PATH_MAX. Las compilaciones W=1 informaban esta advertencia: drivers/block/rnbd/rnbd-srv.c: En función 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: advertencia: '% La salida de la directiva s se puede truncar escribiendo hasta 254 bytes en una región de tamaño entre 0 y 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ En la función 'rnbd_srv_get_full_path', insertada desde 'process_msg_open.isra' en drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block /rnbd/rnbd-srv.c:616:17: nota: 'snprintf' genera entre 2 y 4351 bytes en un destino de tamaño 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~ ~~~~~~~~~~~~~~~~~~~ Para solucionar este problema, verifique incondicionalmente el truncamiento (como ya se hizo en el caso en el que "%SESSNAME%" estaba presente). • https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7 https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7 https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827 https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339 https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52617 – PCI: switchtec: Fix stdev_release() crash after surprise hot remove
https://notcve.org/view.php?id=CVE-2023-52617
In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). • https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355 https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8 https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3 https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693 https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26636 – llc: make llc_ui_sendmsg() more robust against bonding changes
https://notcve.org/view.php?id=CVE-2024-26636
In the Linux kernel, the following vulnerability has been resolved: llc: make llc_ui_sendmsg() more robust against bonding changes syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1] Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed. This fix: - Uses LL_RESERVED_SPACE() to reserve space. - Check all conditions again after socket lock is held again. - Do not account Ethernet header for mtu limitation. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: hacer que llc_ui_sendmsg() sea más robusto contra cambios de vinculación syzbot pudo engañar a llc_ui_sendmsg(), asignando un skb sin espacio libre, pero posteriormente intentó enviar 14 bytes de encabezado Ethernet [ 1] Como otros, llc_ui_sendmsg() libera el bloqueo del socket antes de llamar a sock_alloc_send_skb(). Luego lo adquiere nuevamente, pero no rehace todas las comprobaciones de cordura que se realizaron. Esta solución: - Utiliza LL_RESERVED_SPACE() para reservar espacio. - Verifique todas las condiciones nuevamente después de mantener nuevamente el bloqueo del casquillo. - No tenga en cuenta el encabezado Ethernet para la limitación de mtu. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 ERROR del kernel en net/core/skbuff.c:193. Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 6875 Comm: syz-executor.0 No contaminado 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Nombre del hardware : Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: skb_panic net/core/skbuff.c:189 [en línea] pc: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr: skb_panic net/core/skbuff.c:189 [en línea] lr: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp: ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c 9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x1 7: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9: e28a51f1087e8400 x8: e28a 51f1087e8400 x7: ffff80008028f8d0 x6: 0000000000000000 x5: 0000000000000001 x4: 0000000000000001 x3: ffff800082b78714 x2: 00000000000000 001 x1: 0000000100000000 x0: 0000000000000089 Rastreo de llamadas: skb_panic net/core /skbuff.c:189 [en línea] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c: 83 dev_hard_header include/linux/netdevice.h:3188 [en línea] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_ acciones net/llc/llc_sap.c :153 [en línea] llc_sap_next_state net/llc/llc_sap.c:182 [en línea] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ ui_sendmsg+0x7bc/ 0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs /splice.c:881 do_splice_from fs/splice.c:933 [en línea] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice. c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [en línea] __se_sys_sendfile64 fs/read_write.c:1308 [en línea] __arm64_sys_sendfile64+0x160/0x3b4 fs /read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/ 0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+ 0x190/0x194 arch/arm64/kernel/entry.S:595 Código: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249 https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4 https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565f •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47119 – ext4: fix memory leak in ext4_fill_super
https://notcve.org/view.php?id=CVE-2021-47119
In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_fill_super Buffer head references must be released before calling kill_bdev(); otherwise the buffer head (and its page referenced by b_data) will not be freed by kill_bdev, and subsequently that bh will be leaked. If blocksizes differ, sb_set_blocksize() will kill current buffers and page cache by using kill_bdev(). And then super block will be reread again but using correct blocksize this time. sb_set_blocksize() didn't fully free superblock page and buffer head, and being busy, they were not freed and instead leaked. This can easily be reproduced by calling an infinite loop of: systemctl start <ext4_on_lvm>.mount, and systemctl stop <ext4_on_lvm>.mount ... since systemd creates a cgroup for each slice which it mounts, and the bh leak get amplified by a dying memory cgroup that also never gets freed, and memory consumption is much more easily noticed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige la pérdida de memoria en ext4_fill_super Las referencias del encabezado del búfer deben liberarse antes de llamar a kill_bdev(); de lo contrario, kill_bdev no liberará el encabezado del búfer (y su página a la que hace referencia b_data) y, posteriormente, se filtrará ese bh. Si los tamaños de los bloques difieren, sb_set_blocksize() eliminará los búferes actuales y el caché de la página usando kill_bdev(). Y luego el superbloque se volverá a leer, pero esta vez utilizando el tamaño de bloque correcto. sb_set_blocksize() no liberó completamente la página del superbloque y el encabezado del búfer y, al estar ocupados, no se liberaron y en su lugar se filtraron. • https://git.kernel.org/stable/c/ac27a0ec112a089f1a5102bc8dffc79c8c815571 https://git.kernel.org/stable/c/01d349a481f0591230300a9171330136f9159bcd https://git.kernel.org/stable/c/1385b23396d511d5233b8b921ac3058b3f86a5e1 https://git.kernel.org/stable/c/afd09b617db3786b6ef3dc43e28fe728cfea84df •
CVSS: 4.1EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47118 – pid: take a reference when initializing `cad_pid`
https://notcve.org/view.php?id=CVE-2021-47118
In the Linux kernel, the following vulnerability has been resolved: pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`. Full KASAN splat below. ================================================================== BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270: slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pid: toma una referencia al inicializar `cad_pid` Durante el arranque, kernel_init_freeable() inicializa `cad_pid` en la estructura pid de la tarea de inicio. • https://git.kernel.org/stable/c/9ec52099e4b8678a60e9f93e41ad87885d64f3e6 https://git.kernel.org/stable/c/764c2e892d1fe895392aff62fb353fdce43bb529 https://git.kernel.org/stable/c/f86c80515a8a3703e0ca2e56deb50fc2879c5ea4 https://git.kernel.org/stable/c/4dbd8808a591b49b717862e6e0081bcf14a87788 https://git.kernel.org/stable/c/d106f05432e60f9f62d456ef017687f5c73cb414 https://git.kernel.org/stable/c/2cd6eedfa6344f5ef5c3dac3aee57a39b5b46dff https://git.kernel.org/stable/c/7178be006d495ffb741c329012da289b62dddfe6 https://git.kernel.org/stable/c/b8ff869f20152fbe66b6c2e2715d26a2f • CWE-416: Use After Free •