Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix crypto buffers in non-linear memory<br /> <br /> The crypto API, through the scatterlist API, expects input buffers to be<br /> in linear memory. We handle this with the cifs_sg_set_buf() helper<br /> that converts vmalloc&amp;#39;d memory to their corresponding pages.<br /> <br /> However, when we allocate our aead_request buffer (@creq in<br /> smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly<br /> puts aead_request-&gt;__ctx in vmalloc area.<br /> <br /> AEAD algorithm then uses -&gt;__ctx for its private/internal data and<br /> operations, and uses sg_set_buf() for such data on a few places.<br /> <br /> This works fine as long as @creq falls into kmalloc zone (small<br /> requests) or vmalloc&amp;#39;d memory is still within linear range.<br /> <br /> Tasks&amp;#39; stacks are vmalloc&amp;#39;d by default (CONFIG_VMAP_STACK=y), so too<br /> many tasks will increment the base stacks&amp;#39; addresses to a point where<br /> virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that<br /> happens.<br /> <br /> In practice: too many parallel reads and writes on an encrypted mount<br /> will trigger this bug.<br /> <br /> To fix this, always alloc @creq with kmalloc() instead.<br /> Also drop the @sensitive_size variable/arguments since<br /> kfree_sensitive() doesn&amp;#39;t need it.<br /> <br /> Backtrace:<br /> <br /> [ 945.272081] ------------[ cut here ]------------<br /> [ 945.272774] kernel BUG at include/linux/scatterlist.h:209!<br /> [ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI<br /> [ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)<br /> [ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014<br /> [ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)<br /> [ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220<br /> [ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b<br /> [ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246<br /> [ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030<br /> [ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070<br /> [ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000<br /> [ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070<br /> [ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010<br /> [ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000<br /> [ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0<br /> [ 945.286683] Call Trace:<br /> [ 945.286952] <br /> [ 945.287184] ? crypt_message+0x33f/0xad0 [cifs]<br /> [ 945.287719] crypto_gcm_encrypt+0x36/0xe0<br /> [ 945.288152] crypt_message+0x54a/0xad0 [cifs]<br /> [ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs]<br /> [ 945.289300] smb_send_rqst+0xa3/0x160 [cifs]<br /> [ 945.289944] cifs_call_async+0x178/0x340 [cifs]<br /> [ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]<br /> [ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs]<br /> [ 945.291759] ? find_held_lock+0x32/0x90<br /> [ 945.292212] ? netfs_advance_write+0xf2/0x310<br /> [ 945.292723] netfs_advance_write+0xf2/0x310<br /> [ 945.293210] netfs_write_folio+0x346/0xcc0<br /> [ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10<br /> [ 945.294250] netfs_writepages+0x117/0x460<br /> [ 945.294724] do_writepages+0xbe/0x170<br /> [ 945.295152] ? find_held_lock+0x32/0x90<br /> [ 945.295600] ? kvm_sched_clock_read+0x11/0x20<br /> [ 945.296103] __writeback_single_inode+0x56/0x4b0<br /> [ 945.296643] writeback_sb_inodes+0x229/0x550<br /> [ 945.297140] __writeback_inodes_wb+0x4c/0xe0<br /> [ 945.297642] wb_writeback+0x2f1/0x3f0<br /> [ 945.298069] wb_workfn+0x300/0x490<br /> [ 945.298472] process_one_work+0x1fe/0x590<br /> [ 945.298949] worker_thread+0x1ce/0x3c0<br /> [ 945.299397] ? __pfx_worker_thread+0x10/0x10<br /> [ 945.299900] kthr<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dlink: handle copy_thresh allocation failure<br /> <br /> The driver did not handle failure of `netdev_alloc_skb_ip_align()`.<br /> If the allocation failed, dereferencing `skb-&gt;protocol` could lead to<br /> a NULL pointer dereference.<br /> <br /> This patch tries to allocate `skb`. If the allocation fails, it falls<br /> back to the normal path.<br /> <br /> Tested-on: D-Link DGE-550T Rev-A3

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix UAF issue in f2fs_merge_page_bio()<br /> <br /> As JY reported in bugzilla [1],<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98<br /> lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4<br /> CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P B W OE 6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5<br /> Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Workqueue: writeback wb_workfn (flush-254:49)<br /> Call trace:<br /> f2fs_is_cp_guaranteed+0x70/0x98<br /> f2fs_inplace_write_data+0x174/0x2f4<br /> f2fs_do_write_data_page+0x214/0x81c<br /> f2fs_write_single_data_page+0x28c/0x764<br /> f2fs_write_data_pages+0x78c/0xce4<br /> do_writepages+0xe8/0x2fc<br /> __writeback_single_inode+0x4c/0x4b4<br /> writeback_sb_inodes+0x314/0x540<br /> __writeback_inodes_wb+0xa4/0xf4<br /> wb_writeback+0x160/0x448<br /> wb_workfn+0x2f0/0x5dc<br /> process_scheduled_works+0x1c8/0x458<br /> worker_thread+0x334/0x3f0<br /> kthread+0x118/0x1ac<br /> ret_from_fork+0x10/0x20<br /> <br /> [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575<br /> <br /> The panic was caused by UAF issue w/ below race condition:<br /> <br /> kworker<br /> - writepages<br /> - f2fs_write_cache_pages<br /> - f2fs_write_single_data_page<br /> - f2fs_do_write_data_page<br /> - f2fs_inplace_write_data<br /> - f2fs_merge_page_bio<br /> - add_inu_page<br /> : cache page #1 into bio &amp; cache bio in<br /> io-&gt;bio_list<br /> - f2fs_write_single_data_page<br /> - f2fs_do_write_data_page<br /> - f2fs_inplace_write_data<br /> - f2fs_merge_page_bio<br /> - add_inu_page<br /> : cache page #2 into bio which is linked<br /> in io-&gt;bio_list<br /> write<br /> - f2fs_write_begin<br /> : write page #1<br /> - f2fs_folio_wait_writeback<br /> - f2fs_submit_merged_ipu_write<br /> - f2fs_submit_write_bio<br /> : submit bio which inclues page #1 and #2<br /> <br /> software IRQ<br /> - f2fs_write_end_io<br /> - fscrypt_free_bounce_page<br /> : freed bounced page which belongs to page #2<br /> - inc_page_count( , WB_DATA_TYPE(data_folio), false)<br /> : data_folio points to fio-&gt;encrypted_page<br /> the bounced page can be freed before<br /> accessing it in f2fs_is_cp_guarantee()<br /> <br /> It can reproduce w/ below testcase:<br /> Run below script in shell #1:<br /> for ((i=1;i&gt;0;i++)) do xfs_io -f /mnt/f2fs/enc/file \<br /> -c "pwrite 0 32k" -c "fdatasync"<br /> <br /> Run below script in shell #2:<br /> for ((i=1;i&gt;0;i++)) do xfs_io -f /mnt/f2fs/enc/file \<br /> -c "pwrite 0 32k" -c "fdatasync"<br /> <br /> So, in f2fs_merge_page_bio(), let&amp;#39;s avoid using fio-&gt;encrypted_page after<br /> commit page into internal ipu cache.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix double free in user_cluster_connect()<br /> <br /> user_cluster_disconnect() frees "conn-&gt;cc_private" which is "lc" but then<br /> the error handling frees "lc" a second time. Set "lc" to NULL on this<br /> path to avoid a double free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost: vringh: Fix copy_to_iter return value check<br /> <br /> The return value of copy_to_iter can&amp;#39;t be negative, check whether the<br /> copied length is equal to the requested length instead of checking for<br /> negative values.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Sign-extend struct ops return values properly<br /> <br /> The ns_bpf_qdisc selftest triggers a kernel panic:<br /> <br /> Oops[#1]:<br /> CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4<br /> CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G OE 6.16.0+ #3 PREEMPT(full)<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600<br /> a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008<br /> a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000<br /> t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001<br /> t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d<br /> t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800<br /> s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880<br /> s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000<br /> ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8<br /> ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8<br /> CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> PRMD: 00000004 (PPLV0 +PIE -PWE)<br /> EUEN: 00000007 (+FPE +SXE +ASXE -BTE)<br /> ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> BADV: 0000000000741d58<br /> PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)<br /> Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]<br /> Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956)<br /> Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8<br /> 90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000<br /> 900000010597c400 900000008694a000 0000000000000000 9000000105b59000<br /> 90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c<br /> 9000000086936000 0000000100094d4c fffffff400676208 0000000000000000<br /> 9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000<br /> 9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000<br /> 9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840<br /> 0000000000000000 9000000086be6c40 0000000000000000 0000000000000000<br /> 0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4<br /> ...<br /> Call Trace:<br /> [] __qdisc_run+0xc8/0x8d8<br /> [] __dev_queue_xmit+0x578/0x10f0<br /> [] ip6_finish_output2+0x2f0/0x950<br /> [] ip6_finish_output+0x2b8/0x448<br /> [] ip6_xmit+0x304/0x858<br /> [] inet6_csk_xmit+0x100/0x170<br /> [] __tcp_transmit_skb+0x490/0xdd0<br /> [] tcp_connect+0xbcc/0x1168<br /> [] tcp_v6_connect+0x580/0x8a0<br /> [] __inet_stream_connect+0x170/0x480<br /> [] inet_stream_connect+0x50/0x88<br /> [] __sys_connect+0xe4/0x110<br /> [] sys_connect+0x18/0x28<br /> [] do_syscall+0x94/0x1a0<br /> [] handle_syscall+0xb8/0x158<br /> <br /> Code: 4001ad80 2400873f 2400832d 001137ff 001133ff 6407b41f 001503cc 0280041d<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer<br /> is treated as a 32bit value and sign extend to 64bit in epilogue. This<br /> behavior is right for most bpf prog types but wrong for struct ops which<br /> requires LoongArch ABI.<br /> <br /> So let&amp;#39;s sign extend struct ops return values according to the LoongArch<br /> ABI ([1]) and return value spec in function model.<br /> <br /> [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix race condition in kprobe initialization causing NULL pointer dereference<br /> <br /> There is a critical race condition in kprobe initialization that can lead to<br /> NULL pointer dereference and kernel crash.<br /> <br /> [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000<br /> ...<br /> [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)<br /> [1135630.269239] pc : kprobe_perf_func+0x30/0x260<br /> [1135630.277643] lr : kprobe_dispatcher+0x44/0x60<br /> [1135630.286041] sp : ffffaeff4977fa40<br /> [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400<br /> [1135630.302837] x27: 0000000000000000 x26: 0000000000000000<br /> [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528<br /> [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50<br /> [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50<br /> [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000<br /> [1135630.349985] x17: 0000000000000000 x16: 0000000000000000<br /> [1135630.359285] x15: 0000000000000000 x14: 0000000000000000<br /> [1135630.368445] x13: 0000000000000000 x12: 0000000000000000<br /> [1135630.377473] x11: 0000000000000000 x10: 0000000000000000<br /> [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000<br /> [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000<br /> [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000<br /> [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006<br /> [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000<br /> [1135630.429410] Call trace:<br /> [1135630.434828] kprobe_perf_func+0x30/0x260<br /> [1135630.441661] kprobe_dispatcher+0x44/0x60<br /> [1135630.448396] aggr_pre_handler+0x70/0xc8<br /> [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0<br /> [1135630.462435] brk_handler+0xbc/0xd8<br /> [1135630.468437] do_debug_exception+0x84/0x138<br /> [1135630.475074] el1_dbg+0x18/0x8c<br /> [1135630.480582] security_file_permission+0x0/0xd0<br /> [1135630.487426] vfs_write+0x70/0x1c0<br /> [1135630.493059] ksys_write+0x5c/0xc8<br /> [1135630.498638] __arm64_sys_write+0x24/0x30<br /> [1135630.504821] el0_svc_common+0x78/0x130<br /> [1135630.510838] el0_svc_handler+0x38/0x78<br /> [1135630.516834] el0_svc+0x8/0x1b0<br /> <br /> kernel/trace/trace_kprobe.c: 1308<br /> 0xffff3df8995039ec : ldr x21, [x24,#120]<br /> include/linux/compiler.h: 294<br /> 0xffff3df8995039f0 : ldr x1, [x21,x0]<br /> <br /> kernel/trace/trace_kprobe.c<br /> 1308: head = this_cpu_ptr(call-&gt;perf_events);<br /> 1309: if (hlist_empty(head))<br /> 1310: return 0;<br /> <br /> crash&gt; struct trace_event_call -o<br /> struct trace_event_call {<br /> ...<br /> [120] struct hlist_head *perf_events; //(call-&gt;perf_event)<br /> ...<br /> }<br /> <br /> crash&gt; struct trace_event_call ffffaf015340e528<br /> struct trace_event_call {<br /> ...<br /> perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0<br /> ...<br /> }<br /> <br /> Race Condition Analysis:<br /> <br /> The race occurs between kprobe activation and perf_events initialization:<br /> <br /> CPU0 CPU1<br /> ==== ====<br /> perf_kprobe_init<br /> perf_trace_event_init<br /> tp_event-&gt;perf_events = list;(1)<br /> tp_event-&gt;class-&gt;reg (2)← KPROBE ACTIVE<br /> Debug exception triggers<br /> ...<br /> kprobe_dispatcher<br /> kprobe_perf_func (tk-&gt;tp.flags &amp; TP_FLAG_PROFILE)<br /> head = this_cpu_ptr(call-&gt;perf_events)(3)<br /> (perf_events is still NULL)<br /> <br /> Problem:<br /> 1. CPU0 executes (1) assigning tp_event-&gt;perf_events = list<br /> 2. CPU0 executes (2) enabling kprobe functionality via class-&gt;reg()<br /> 3. CPU1 triggers and reaches kprobe_dispatcher<br /> 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)<br /> 5. CPU1 calls kprobe_perf_func() and crashes at (3) because<br /> call-&gt;perf_events is still NULL<br /> <br /> CPU1 sees that kprobe functionality is enabled but does not see that<br /> perf_events has been assigned.<br /> <br /> Add pairing read an<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nfc: nci: Add parameter validation for packet data<br /> <br /> Syzbot reported an uninitialized value bug in nci_init_req, which was<br /> introduced by commit 5aca7966d2a7 ("Merge tag<br /> &amp;#39;perf-tools-fixes-for-v6.17-2025-09-16&amp;#39; of<br /> git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").<br /> <br /> This bug arises due to very limited and poor input validation<br /> that was done at nic_valid_size(). This validation only<br /> validates the skb-&gt;len (directly reflects size provided at the<br /> userspace interface) with the length provided in the buffer<br /> itself (interpreted as NCI_HEADER). This leads to the processing<br /> of memory content at the address assuming the correct layout<br /> per what opcode requires there. This leads to the accesses to<br /> buffer of `skb_buff-&gt;data` which is not assigned anything yet.<br /> <br /> Following the same silent drop of packets of invalid sizes at<br /> `nic_valid_size()`, add validation of the data in the respective<br /> handlers and return error values in case of failure. Release<br /> the skb if error values are returned from handlers in<br /> `nci_nft_packet` and effectively do a silent drop<br /> <br /> Possible TODO: because we silently drop the packets, the<br /> call to `nci_request` will be waiting for completion of request<br /> and will face timeouts. These timeouts can get excessively logged<br /> in the dmesg. A proper handling of them may require to export<br /> `nci_request_cancel` (or propagate error handling from the<br /> nft packets handlers).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: udf: fix OOB read in lengthAllocDescs handling<br /> <br /> When parsing Allocation Extent Descriptor, lengthAllocDescs comes from<br /> on-disk data and must be validated against the block size. Crafted or<br /> corrupted images may set lengthAllocDescs so that the total descriptor<br /> length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,<br /> leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and<br /> trigger a KASAN use-after-free read.<br /> <br /> BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60<br /> Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309<br /> <br /> CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60<br /> udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261<br /> udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179<br /> extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46<br /> udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106<br /> udf_release_file+0xc1/0x120 fs/udf/file.c:185<br /> __fput+0x23f/0x880 fs/file_table.c:431<br /> task_work_run+0x24f/0x310 kernel/task_work.c:239<br /> exit_task_work include/linux/task_work.h:43 [inline]<br /> do_exit+0xa2f/0x28e0 kernel/exit.c:939<br /> do_group_exit+0x207/0x2c0 kernel/exit.c:1088<br /> __do_sys_exit_group kernel/exit.c:1099 [inline]<br /> __se_sys_exit_group kernel/exit.c:1097 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097<br /> x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Validate the computed total length against epos-&gt;bh-&gt;b_size.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wcd937x: set the comp soundwire port correctly<br /> <br /> For some reason we endup with setting soundwire port for<br /> HPHL_COMP and HPHR_COMP as zero, this can potentially result<br /> in a memory corruption due to accessing and setting -1 th element of<br /> port_map array.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix overshooting recv limit<br /> <br /> It&amp;#39;s reported that sometimes a zcrx request can receive more than was<br /> requested. It&amp;#39;s caused by io_zcrx_recv_skb() adjusting desc-&gt;count for<br /> all received buffers including frag lists, but then doing recursive<br /> calls to process frag list skbs, which leads to desc-&gt;count double<br /> accounting and underflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/waitid: always prune wait queue entry in io_waitid_wait()<br /> <br /> For a successful return, always remove our entry from the wait queue<br /> entry list. Previously this was skipped if a cancelation was in<br /> progress, but this can race with another invocation of the wait queue<br /> entry callback.