Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix null pointer panic in tracepoint in __replace_atomic_write_block<br /> <br /> We got a kernel panic if old_addr is NULL.<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=217266<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> Call Trace:<br /> <br /> f2fs_commit_atomic_write+0x619/0x990 [f2fs a1b985b80f5babd6f3ea778384908880812bfa43]<br /> __f2fs_ioctl+0xd8e/0x4080 [f2fs a1b985b80f5babd6f3ea778384908880812bfa43]<br /> ? vfs_write+0x2ae/0x3f0<br /> ? vfs_write+0x2ae/0x3f0<br /> __x64_sys_ioctl+0x91/0xd0<br /> do_syscall_64+0x5c/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7f69095fe53f

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_api: remove block_cb from driver_list before freeing<br /> <br /> Error handler of tcf_block_bind() frees the whole bo-&gt;cb_list on error.<br /> However, by that time the flow_block_cb instances are already in the driver<br /> list because driver ndo_setup_tc() callback is called before that up the<br /> call chain in tcf_block_offload_cmd(). This leaves dangling pointers to<br /> freed objects in the list and causes use-after-free[0]. Fix it by also<br /> removing flow_block_cb instances from driver_list before deallocating them.<br /> <br /> [0]:<br /> [ 279.868433] ==================================================================<br /> [ 279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963<br /> <br /> [ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4<br /> [ 279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 279.876295] Call Trace:<br /> [ 279.876882] <br /> [ 279.877413] dump_stack_lvl+0x33/0x50<br /> [ 279.878198] print_report+0xc2/0x610<br /> [ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.879994] kasan_report+0xae/0xe0<br /> [ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.881744] ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core]<br /> [ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0<br /> [ 279.885037] ? tcf_block_setup+0x6b0/0x6b0<br /> [ 279.885901] ? mutex_lock+0x7d/0xd0<br /> [ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0<br /> [ 279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress]<br /> [ 279.888846] tcf_block_get_ext+0x61c/0x1200<br /> [ 279.889711] ingress_init+0x112/0x1c0 [sch_ingress]<br /> [ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress]<br /> [ 279.891701] qdisc_create+0x401/0xea0<br /> [ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470<br /> [ 279.893473] tc_modify_qdisc+0x6f7/0x16d0<br /> [ 279.894344] ? tc_get_qdisc+0xac0/0xac0<br /> [ 279.895213] ? mutex_lock+0x7d/0xd0<br /> [ 279.896005] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0<br /> [ 279.897770] ? rtnl_calcit.isra.0+0x2b0/0x2b0<br /> [ 279.898672] ? __sys_sendmsg+0xb5/0x140<br /> [ 279.899494] ? do_syscall_64+0x3d/0x90<br /> [ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 279.901337] ? kasan_save_stack+0x2e/0x40<br /> [ 279.902177] ? kasan_save_stack+0x1e/0x40<br /> [ 279.903058] ? kasan_set_track+0x21/0x30<br /> [ 279.903913] ? kasan_save_free_info+0x2a/0x40<br /> [ 279.904836] ? ____kasan_slab_free+0x11a/0x1b0<br /> [ 279.905741] ? kmem_cache_free+0x179/0x400<br /> [ 279.906599] netlink_rcv_skb+0x12c/0x360<br /> [ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0<br /> [ 279.908360] ? netlink_ack+0x1550/0x1550<br /> [ 279.909192] ? rhashtable_walk_peek+0x170/0x170<br /> [ 279.910135] ? kmem_cache_alloc_node+0x1af/0x390<br /> [ 279.911086] ? _copy_from_iter+0x3d6/0xc70<br /> [ 279.912031] netlink_unicast+0x553/0x790<br /> [ 279.912864] ? netlink_attachskb+0x6a0/0x6a0<br /> [ 279.913763] ? netlink_recvmsg+0x416/0xb50<br /> [ 279.914627] netlink_sendmsg+0x7a1/0xcb0<br /> [ 279.915473] ? netlink_unicast+0x790/0x790<br /> [ 279.916334] ? iovec_from_user.part.0+0x4d/0x220<br /> [ 279.917293] ? netlink_unicast+0x790/0x790<br /> [ 279.918159] sock_sendmsg+0xc5/0x190<br /> [ 279.918938] ____sys_sendmsg+0x535/0x6b0<br /> [ 279.919813] ? import_iovec+0x7/0x10<br /> [ 279.920601] ? kernel_sendmsg+0x30/0x30<br /> [ 279.921423] ? __copy_msghdr+0x3c0/0x3c0<br /> [ 279.922254] ? import_iovec+0x7/0x10<br /> [ 279.923041] ___sys_sendmsg+0xeb/0x170<br /> [ 279.923854] ? copy_msghdr_from_user+0x110/0x110<br /> [ 279.924797] ? ___sys_recvmsg+0xd9/0x130<br /> [ 279.925630] ? __perf_event_task_sched_in+0x183/0x470<br /> [ 279.926656] ? ___sys_sendmsg+0x170/0x170<br /> [ 279.927529] ? ctx_sched_in+0x530/0x530<br /> [ 279.928369] ? update_curr+0x283/0x4f0<br /> [ 279.929185] ? perf_event_update_userpage+0x570/0x570<br /> [ 279.930201] ? __fget_light+0x57/0x520<br /> [ 279.931023] ? __switch_to+0x53d/0xe70<br /> [ 27<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: use kvmalloc_array/kvfree instead of kmalloc_array/kfree<br /> <br /> The call stack shown below is a scenario in the Linux 4.19 kernel.<br /> Allocating memory failed where exfat fs use kmalloc_array due to<br /> system memory fragmentation, while the u-disk was inserted without<br /> recognition.<br /> Devices such as u-disk using the exfat file system are pluggable and<br /> may be insert into the system at any time.<br /> However, long-term running systems cannot guarantee the continuity of<br /> physical memory. Therefore, it&amp;#39;s necessary to address this issue.<br /> <br /> Binder:2632_6: page allocation failure: order:4,<br /> mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)<br /> Call trace:<br /> [242178.097582] dump_backtrace+0x0/0x4<br /> [242178.097589] dump_stack+0xf4/0x134<br /> [242178.097598] warn_alloc+0xd8/0x144<br /> [242178.097603] __alloc_pages_nodemask+0x1364/0x1384<br /> [242178.097608] kmalloc_order+0x2c/0x510<br /> [242178.097612] kmalloc_order_trace+0x40/0x16c<br /> [242178.097618] __kmalloc+0x360/0x408<br /> [242178.097624] load_alloc_bitmap+0x160/0x284<br /> [242178.097628] exfat_fill_super+0xa3c/0xe7c<br /> [242178.097635] mount_bdev+0x2e8/0x3a0<br /> [242178.097638] exfat_fs_mount+0x40/0x50<br /> [242178.097643] mount_fs+0x138/0x2e8<br /> [242178.097649] vfs_kern_mount+0x90/0x270<br /> [242178.097655] do_mount+0x798/0x173c<br /> [242178.097659] ksys_mount+0x114/0x1ac<br /> [242178.097665] __arm64_sys_mount+0x24/0x34<br /> [242178.097671] el0_svc_common+0xb8/0x1b8<br /> [242178.097676] el0_svc_handler+0x74/0x90<br /> [242178.097681] el0_svc+0x8/0x340<br /> <br /> By analyzing the exfat code,we found that continuous physical memory<br /> is not required here,so kvmalloc_array is used can solve this problem.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix timeout of a call that hasn&amp;#39;t yet been granted a channel<br /> <br /> afs_make_call() calls rxrpc_kernel_begin_call() to begin a call (which may<br /> get stalled in the background waiting for a connection to become<br /> available); it then calls rxrpc_kernel_set_max_life() to set the timeouts -<br /> but that starts the call timer so the call timer might then expire before<br /> we get a connection assigned - leading to the following oops if the call<br /> stalled:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> CPU: 1 PID: 5111 Comm: krxrpcio/0 Not tainted 6.3.0-rc7-build3+ #701<br /> RIP: 0010:rxrpc_alloc_txbuf+0xc0/0x157<br /> ...<br /> Call Trace:<br /> <br /> rxrpc_send_ACK+0x50/0x13b<br /> rxrpc_input_call_event+0x16a/0x67d<br /> rxrpc_io_thread+0x1b6/0x45f<br /> ? _raw_spin_unlock_irqrestore+0x1f/0x35<br /> ? rxrpc_input_packet+0x519/0x519<br /> kthread+0xe7/0xef<br /> ? kthread_complete_and_exit+0x1b/0x1b<br /> ret_from_fork+0x22/0x30<br /> <br /> Fix this by noting the timeouts in struct rxrpc_call when the call is<br /> created. The timer will be started when the first packet is transmitted.<br /> <br /> It shouldn&amp;#39;t be possible to trigger this directly from userspace through<br /> AF_RXRPC as sendmsg() will return EBUSY if the call is in the<br /> waiting-for-conn state if it dropped out of the wait due to a signal.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix NULL pointer dereference in &amp;#39;ni_write_inode&amp;#39;<br /> <br /> Syzbot found the following issue:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000016<br /> Mem abort info:<br /> ESR = 0x0000000096000006<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 /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af56000<br /> [0000000000000016] pgd=08000001090da003, p4d=08000001090da003, pud=08000001090ce003, pmd=0000000000000000<br /> Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 1 PID: 3036 Comm: syz-executor206 Not tainted 6.0.0-rc6-syzkaller-17739-g16c9f284e746 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : is_rec_inuse fs/ntfs3/ntfs.h:313 [inline]<br /> pc : ni_write_inode+0xac/0x798 fs/ntfs3/frecord.c:3232<br /> lr : ni_write_inode+0xa0/0x798 fs/ntfs3/frecord.c:3226<br /> sp : ffff8000126c3800<br /> x29: ffff8000126c3860 x28: 0000000000000000 x27: ffff0000c8b02000<br /> x26: ffff0000c7502320 x25: ffff0000c7502288 x24: 0000000000000000<br /> x23: ffff80000cbec91c x22: ffff0000c8b03000 x21: ffff0000c8b02000<br /> x20: 0000000000000001 x19: ffff0000c75024d8 x18: 00000000000000c0<br /> x17: ffff80000dd1b198 x16: ffff80000db59158 x15: ffff0000c4b6b500<br /> x14: 00000000000000b8 x13: 0000000000000000 x12: ffff0000c4b6b500<br /> x11: ff80800008be1b60 x10: 0000000000000000 x9 : ffff0000c4b6b500<br /> x8 : 0000000000000000 x7 : ffff800008be1b50 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000<br /> x2 : 0000000000000008 x1 : 0000000000000001 x0 : 0000000000000000<br /> Call trace:<br /> is_rec_inuse fs/ntfs3/ntfs.h:313 [inline]<br /> ni_write_inode+0xac/0x798 fs/ntfs3/frecord.c:3232<br /> ntfs_evict_inode+0x54/0x84 fs/ntfs3/inode.c:1744<br /> evict+0xec/0x334 fs/inode.c:665<br /> iput_final fs/inode.c:1748 [inline]<br /> iput+0x2c4/0x324 fs/inode.c:1774<br /> ntfs_new_inode+0x7c/0xe0 fs/ntfs3/fsntfs.c:1660<br /> ntfs_create_inode+0x20c/0xe78 fs/ntfs3/inode.c:1278<br /> ntfs_create+0x54/0x74 fs/ntfs3/namei.c:100<br /> lookup_open fs/namei.c:3413 [inline]<br /> open_last_lookups fs/namei.c:3481 [inline]<br /> path_openat+0x804/0x11c4 fs/namei.c:3688<br /> do_filp_open+0xdc/0x1b8 fs/namei.c:3718<br /> do_sys_openat2+0xb8/0x22c fs/open.c:1311<br /> do_sys_open fs/open.c:1327 [inline]<br /> __do_sys_openat fs/open.c:1343 [inline]<br /> __se_sys_openat fs/open.c:1338 [inline]<br /> __arm64_sys_openat+0xb0/0xe0 fs/open.c:1338<br /> __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]<br /> invoke_syscall arch/arm64/kernel/syscall.c:52 [inline]<br /> el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142<br /> do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206<br /> el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636<br /> el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654<br /> el0t_64_sync+0x18c/0x190<br /> Code: 97dafee4 340001b4 f9401328 2a1f03e0 (79402d14)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Above issue may happens as follows:<br /> ntfs_new_inode<br /> mi_init<br /> mi-&gt;mrec = kmalloc(sbi-&gt;record_size, GFP_NOFS); --&gt;failed to allocate memory<br /> if (!mi-&gt;mrec)<br /> return -ENOMEM;<br /> iput<br /> iput_final<br /> evict<br /> ntfs_evict_inode<br /> ni_write_inode<br /> is_rec_inuse(ni-&gt;mi.mrec)-&gt; As &amp;#39;ni-&gt;mi.mrec&amp;#39; is NULL trigger NULL-ptr-deref<br /> <br /> To solve above issue if new inode failed make inode bad before call &amp;#39;iput()&amp;#39; in<br /> &amp;#39;ntfs_new_inode()&amp;#39;.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work"<br /> <br /> This reverts commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f.<br /> <br /> This patch introduces a possible null-ptr-def problem. Revert it. And the<br /> fixed bug by this patch have resolved by commit 73f7b171b7c0 ("Bluetooth:<br /> btsdio: fix use after free bug in btsdio_remove due to race condition").

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: fix out-of-bounds access in tty_driver_lookup_tty()<br /> <br /> When specifying an invalid console= device like console=tty3270,<br /> tty_driver_lookup_tty() returns the tty struct without checking<br /> whether index is a valid number.<br /> <br /> To reproduce:<br /> <br /> qemu-system-x86_64 -enable-kvm -nographic -serial mon:stdio \<br /> -kernel ../linux-build-x86/arch/x86/boot/bzImage \<br /> -append "console=ttyS0 console=tty3270"<br /> <br /> This crashes with:<br /> <br /> [ 0.770599] BUG: kernel NULL pointer dereference, address: 00000000000000ef<br /> [ 0.771265] #PF: supervisor read access in kernel mode<br /> [ 0.771773] #PF: error_code(0x0000) - not-present page<br /> [ 0.772609] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 0.774878] RIP: 0010:tty_open+0x268/0x6f0<br /> [ 0.784013] chrdev_open+0xbd/0x230<br /> [ 0.784444] ? cdev_device_add+0x80/0x80<br /> [ 0.784920] do_dentry_open+0x1e0/0x410<br /> [ 0.785389] path_openat+0xca9/0x1050<br /> [ 0.785813] do_filp_open+0xaa/0x150<br /> [ 0.786240] file_open_name+0x133/0x1b0<br /> [ 0.786746] filp_open+0x27/0x50<br /> [ 0.787244] console_on_rootfs+0x14/0x4d<br /> [ 0.787800] kernel_init_freeable+0x1e4/0x20d<br /> [ 0.788383] ? rest_init+0xc0/0xc0<br /> [ 0.788881] kernel_init+0x11/0x120<br /> [ 0.789356] ret_from_fork+0x22/0x30

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/adreno: Fix null ptr access in adreno_gpu_cleanup()<br /> <br /> Fix the below kernel panic due to null pointer access:<br /> [ 18.504431] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048<br /> [ 18.513464] Mem abort info:<br /> [ 18.516346] ESR = 0x0000000096000005<br /> [ 18.520204] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 18.525706] SET = 0, FnV = 0<br /> [ 18.528878] EA = 0, S1PTW = 0<br /> [ 18.532117] FSC = 0x05: level 1 translation fault<br /> [ 18.537138] Data abort info:<br /> [ 18.540110] ISV = 0, ISS = 0x00000005<br /> [ 18.544060] CM = 0, WnR = 0<br /> [ 18.547109] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000112826000<br /> [ 18.553738] [0000000000000048] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 18.562690] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> **Snip**<br /> [ 18.696758] Call trace:<br /> [ 18.699278] adreno_gpu_cleanup+0x30/0x88<br /> [ 18.703396] a6xx_destroy+0xc0/0x130<br /> [ 18.707066] a6xx_gpu_init+0x308/0x424<br /> [ 18.710921] adreno_bind+0x178/0x288<br /> [ 18.714590] component_bind_all+0xe0/0x214<br /> [ 18.718797] msm_drm_bind+0x1d4/0x614<br /> [ 18.722566] try_to_bring_up_aggregate_device+0x16c/0x1b8<br /> [ 18.728105] __component_add+0xa0/0x158<br /> [ 18.732048] component_add+0x20/0x2c<br /> [ 18.735719] adreno_probe+0x40/0xc0<br /> [ 18.739300] platform_probe+0xb4/0xd4<br /> [ 18.743068] really_probe+0xfc/0x284<br /> [ 18.746738] __driver_probe_device+0xc0/0xec<br /> [ 18.751129] driver_probe_device+0x48/0x110<br /> [ 18.755421] __device_attach_driver+0xa8/0xd0<br /> [ 18.759900] bus_for_each_drv+0x90/0xdc<br /> [ 18.763843] __device_attach+0xfc/0x174<br /> [ 18.767786] device_initial_probe+0x20/0x2c<br /> [ 18.772090] bus_probe_device+0x40/0xa0<br /> [ 18.776032] deferred_probe_work_func+0x94/0xd0<br /> [ 18.780686] process_one_work+0x190/0x3d0<br /> [ 18.784805] worker_thread+0x280/0x3d4<br /> [ 18.788659] kthread+0x104/0x1c0<br /> [ 18.791981] ret_from_fork+0x10/0x20<br /> [ 18.795654] Code: f9400408 aa0003f3 aa1f03f4 91142015 (f9402516)<br /> [ 18.801913] ---[ end trace 0000000000000000 ]---<br /> [ 18.809039] Kernel panic - not syncing: Oops: Fatal exception<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/515605/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix issue in verifying allow_ptr_leaks<br /> <br /> After we converted the capabilities of our networking-bpf program from<br /> cap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf program<br /> failed to start. Because it failed the bpf verifier, and the error log<br /> is "R3 pointer comparison prohibited".<br /> <br /> A simple reproducer as follows,<br /> <br /> SEC("cls-ingress")<br /> int ingress(struct __sk_buff *skb)<br /> {<br /> struct iphdr *iph = (void *)(long)skb-&gt;data + sizeof(struct ethhdr);<br /> <br /> if ((long)(iph + 1) &gt; (long)skb-&gt;data_end)<br /> return TC_ACT_STOLEN;<br /> return TC_ACT_OK;<br /> }<br /> <br /> Per discussion with Yonghong and Alexei [1], comparison of two packet<br /> pointers is not a pointer leak. This patch fixes it.<br /> <br /> Our local kernel is 6.1.y and we expect this fix to be backported to<br /> 6.1.y, so stable is CCed.<br /> <br /> [1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to check readonly condition correctly<br /> <br /> With below case, it can mount multi-device image w/ rw option, however<br /> one of secondary device is set as ro, later update will cause panic, so<br /> let&amp;#39;s introduce f2fs_dev_is_readonly(), and check multi-devices rw status<br /> in f2fs_remount() w/ it in order to avoid such inconsistent mount status.<br /> <br /> mkfs.f2fs -c /dev/zram1 /dev/zram0 -f<br /> blockdev --setro /dev/zram1<br /> mount -t f2fs dev/zram0 /mnt/f2fs<br /> mount: /mnt/f2fs: WARNING: source write-protected, mounted read-only.<br /> mount -t f2fs -o remount,rw mnt/f2fs<br /> dd if=/dev/zero of=/mnt/f2fs/file bs=1M count=8192<br /> <br /> kernel BUG at fs/f2fs/inline.c:258!<br /> RIP: 0010:f2fs_write_inline_data+0x23e/0x2d0 [f2fs]<br /> Call Trace:<br /> f2fs_write_single_data_page+0x26b/0x9f0 [f2fs]<br /> f2fs_write_cache_pages+0x389/0xa60 [f2fs]<br /> __f2fs_write_data_pages+0x26b/0x2d0 [f2fs]<br /> f2fs_write_data_pages+0x2e/0x40 [f2fs]<br /> do_writepages+0xd3/0x1b0<br /> __writeback_single_inode+0x5b/0x420<br /> writeback_sb_inodes+0x236/0x5a0<br /> __writeback_inodes_wb+0x56/0xf0<br /> wb_writeback+0x2a3/0x490<br /> wb_do_writeback+0x2b2/0x330<br /> wb_workfn+0x6a/0x260<br /> process_one_work+0x270/0x5e0<br /> worker_thread+0x52/0x3e0<br /> kthread+0xf4/0x120<br /> ret_from_fork+0x29/0x50

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-core: Fix a potential resource leak in v4l2_fwnode_parse_link()<br /> <br /> If fwnode_graph_get_remote_endpoint() fails, &amp;#39;fwnode&amp;#39; is known to be NULL,<br /> so fwnode_handle_put() is a no-op.<br /> <br /> Release the reference taken from a previous fwnode_graph_get_port_parent()<br /> call instead.<br /> <br /> Also handle fwnode_graph_get_port_parent() failures.<br /> <br /> In order to fix these issues, add an error handling path to the function<br /> and the needed gotos.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: iscsit: Free cmds before session free<br /> <br /> Commands from recovery entries are freed after session has been closed.<br /> That leads to use-after-free at command free or NPE with such call trace:<br /> <br /> Time2Retain timer expired for SID: 1, cleaning up iSCSI session.<br /> BUG: kernel NULL pointer dereference, address: 0000000000000140<br /> RIP: 0010:sbitmap_queue_clear+0x3a/0xa0<br /> Call Trace:<br /> target_release_cmd_kref+0xd1/0x1f0 [target_core_mod]<br /> transport_generic_free_cmd+0xd1/0x180 [target_core_mod]<br /> iscsit_free_cmd+0x53/0xd0 [iscsi_target_mod]<br /> iscsit_free_connection_recovery_entries+0x29d/0x320 [iscsi_target_mod]<br /> iscsit_close_session+0x13a/0x140 [iscsi_target_mod]<br /> iscsit_check_post_dataout+0x440/0x440 [iscsi_target_mod]<br /> call_timer_fn+0x24/0x140<br /> <br /> Move cleanup of recovery enrties to before session freeing.