Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: validate buffer count with offset for cloning<br /> <br /> syzbot reports that it can trigger a WARN_ON() for kmalloc() attempt<br /> that&amp;#39;s too big:<br /> <br /> WARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024<br /> lr : __do_kmalloc_node mm/slub.c:-1 [inline]<br /> lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012<br /> sp : ffff80009cfd7a90<br /> x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0<br /> x26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000<br /> x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8<br /> x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff<br /> x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005<br /> x14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938<br /> x8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000<br /> x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001<br /> Call trace:<br /> __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)<br /> kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]<br /> io_rsrc_data_alloc io_uring/rsrc.c:206 [inline]<br /> io_clone_buffers io_uring/rsrc.c:1178 [inline]<br /> io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287<br /> __io_uring_register io_uring/register.c:815 [inline]<br /> __do_sys_io_uring_register io_uring/register.c:926 [inline]<br /> __se_sys_io_uring_register io_uring/register.c:903 [inline]<br /> __arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767<br /> el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600<br /> <br /> which is due to offset + buffer_count being too large. The registration<br /> code checks only the total count of buffers, but given that the indexing<br /> is an array, it should also check offset + count. That can&amp;#39;t exceed<br /> IORING_MAX_REG_BUFFERS either, as there&amp;#39;s no way to reach buffers beyond<br /> that limit.<br /> <br /> There&amp;#39;s no issue with registrering a table this large, outside of the<br /> fact that it&amp;#39;s pointless to register buffers that cannot be reached, and<br /> that it can trigger this kmalloc() warning for attempting an allocation<br /> that is too large.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell_rbu: Fix list usage<br /> <br /> Pass the correct list head to list_for_each_entry*() when looping through<br /> the packet list.<br /> <br /> Without this patch, reading the packet data via sysfs will show the data<br /> incorrectly (because it starts at the wrong packet), and clearing the<br /> packet list will result in a NULL pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get()<br /> <br /> Before calling lan743x_ptp_io_event_clock_get(), the &amp;#39;channel&amp;#39; value<br /> is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8).<br /> This seems correct and aligns with the PTP interrupt status register<br /> (PTP_INT_STS) specifications.<br /> <br /> However, lan743x_ptp_io_event_clock_get() writes to ptp-&gt;extts[] with<br /> only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index:<br /> <br /> lan743x_ptp_io_event_clock_get(..., u8 channel,...)<br /> {<br /> ...<br /> /* Update Local timestamp */<br /> extts = &amp;ptp-&gt;extts[channel];<br /> extts-&gt;ts.tv_sec = sec;<br /> ...<br /> }<br /> <br /> To avoid an out-of-bounds write and utilize all the supported GPIO<br /> inputs, set LAN743X_PTP_N_EXTTS to 8.<br /> <br /> Detected using the static analysis tool - Svace.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer<br /> <br /> The reproduction steps:<br /> 1. create a tun interface<br /> 2. enable l2 bearer<br /> 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun<br /> <br /> tipc: Started in network mode<br /> tipc: Node identity 8af312d38a21, cluster identity 4711<br /> tipc: Enabled bearer , priority 1<br /> Oops: general protection fault<br /> KASAN: null-ptr-deref in range<br /> CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT<br /> Hardware name: QEMU Ubuntu 24.04 PC<br /> RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0<br /> <br /> the ub was in fact a struct dev.<br /> <br /> when bid != 0 &amp;&amp; skip_cnt != 0, bearer_list[bid] may be NULL or<br /> other media when other thread changes it.<br /> <br /> fix this by checking media_id.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: atmtcp: Free invalid length skb in atmtcp_c_send().<br /> <br /> syzbot reported the splat below. [0]<br /> <br /> vcc_sendmsg() copies data passed from userspace to skb and passes<br /> it to vcc-&gt;dev-&gt;ops-&gt;send().<br /> <br /> atmtcp_c_send() accesses skb-&gt;data as struct atmtcp_hdr after<br /> checking if skb-&gt;len is 0, but it&amp;#39;s not enough.<br /> <br /> Also, when skb-&gt;len == 0, skb and sk (vcc) were leaked because<br /> dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing<br /> to revert atm_account_tx() in vcc_sendmsg(), which is expected<br /> to be done in atm_pop_raw().<br /> <br /> Let&amp;#39;s properly free skb with an invalid length in atmtcp_c_send().<br /> <br /> [0]:<br /> BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294<br /> atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294<br /> vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x330/0x3d0 net/socket.c:727<br /> ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620<br /> __sys_sendmsg net/socket.c:2652 [inline]<br /> __do_sys_sendmsg net/socket.c:2657 [inline]<br /> __se_sys_sendmsg net/socket.c:2655 [inline]<br /> __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655<br /> x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4154 [inline]<br /> slab_alloc_node mm/slub.c:4197 [inline]<br /> kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249<br /> kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579<br /> __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670<br /> alloc_skb include/linux/skbuff.h:1336 [inline]<br /> vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x330/0x3d0 net/socket.c:727<br /> ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620<br /> __sys_sendmsg net/socket.c:2652 [inline]<br /> __do_sys_sendmsg net/socket.c:2657 [inline]<br /> __se_sys_sendmsg net/socket.c:2655 [inline]<br /> __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655<br /> x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix double invocation of bnxt_ulp_stop()/bnxt_ulp_start()<br /> <br /> Before the commit under the Fixes tag below, bnxt_ulp_stop() and<br /> bnxt_ulp_start() were always invoked in pairs. After that commit,<br /> the new bnxt_ulp_restart() can be invoked after bnxt_ulp_stop()<br /> has been called. This may result in the RoCE driver&amp;#39;s aux driver<br /> .suspend() method being invoked twice. The 2nd bnxt_re_suspend()<br /> call will crash when it dereferences a NULL pointer:<br /> <br /> (NULL ib_device): Handle device suspend call<br /> BUG: kernel NULL pointer dereference, address: 0000000000000b78<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> CPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S 6.15.0-rc1 #4 PREEMPT(voluntary)<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017<br /> Workqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en]<br /> RIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re]<br /> Code: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00<br /> RSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001<br /> RDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffff<br /> RBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfff<br /> R10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070<br /> R13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> bnxt_ulp_stop+0x69/0x90 [bnxt_en]<br /> bnxt_sp_task+0x678/0x920 [bnxt_en]<br /> ? __schedule+0x514/0xf50<br /> process_scheduled_works+0x9d/0x400<br /> worker_thread+0x11c/0x260<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xfe/0x1e0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2b/0x40<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Check the BNXT_EN_FLAG_ULP_STOPPED flag and do not proceed if the flag<br /> is already set. This will preserve the original symmetrical<br /> bnxt_ulp_stop() and bnxt_ulp_start().<br /> <br /> Also, inside bnxt_ulp_start(), clear the BNXT_EN_FLAG_ULP_STOPPED<br /> flag after taking the mutex to avoid any race condition. And for<br /> symmetry, only proceed in bnxt_ulp_start() if the<br /> BNXT_EN_FLAG_ULP_STOPPED is set.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()<br /> <br /> The RPC container is released after being passed to r535_gsp_rpc_send().<br /> <br /> When sending the initial fragment of a large RPC and passing the<br /> caller&amp;#39;s RPC container, the container will be freed prematurely. Subsequent<br /> attempts to send remaining fragments will therefore result in a<br /> use-after-free.<br /> <br /> Allocate a temporary RPC container for holding the initial fragment of a<br /> large RPC when sending. Free the caller&amp;#39;s container when all fragments<br /> are successfully sent.<br /> <br /> [ Rebase onto Blackwell changes. - Danilo ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE<br /> <br /> Calling this packet is necessary when we switch contexts because there<br /> are various pieces of state used by userspace to synchronize between BR<br /> and BV that are persistent across submits and we need to make sure that<br /> they are in a "safe" state when switching contexts. Otherwise a<br /> userspace submission in one context could cause another context to<br /> function incorrectly and hang, effectively a denial of service (although<br /> without leaking data). This was missed during initial a7xx bringup.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/654924/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Avoid NULL pointer dereference in `v3d_job_update_stats()`<br /> <br /> The following kernel Oops was recently reported by Mesa CI:<br /> <br /> [ 800.139824] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000588<br /> [ 800.148619] Mem abort info:<br /> [ 800.151402] ESR = 0x0000000096000005<br /> [ 800.155141] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 800.160444] SET = 0, FnV = 0<br /> [ 800.163488] EA = 0, S1PTW = 0<br /> [ 800.166619] FSC = 0x05: level 1 translation fault<br /> [ 800.171487] Data abort info:<br /> [ 800.174357] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 800.179832] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 800.184873] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 800.190176] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001014c2000<br /> [ 800.196607] [0000000000000588] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 800.205305] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> [ 800.211564] Modules linked in: vc4 snd_soc_hdmi_codec drm_display_helper v3d cec gpu_sched drm_dma_helper drm_shmem_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm i2c_brcmstb snd_timer snd backlight<br /> [ 800.234448] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1<br /> [ 800.244182] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)<br /> [ 800.250005] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 800.256959] pc : v3d_job_update_stats+0x60/0x130 [v3d]<br /> [ 800.262112] lr : v3d_job_update_stats+0x48/0x130 [v3d]<br /> [ 800.267251] sp : ffffffc080003e60<br /> [ 800.270555] x29: ffffffc080003e60 x28: ffffffd842784980 x27: 0224012000000000<br /> [ 800.277687] x26: ffffffd84277f630 x25: ffffff81012fd800 x24: 0000000000000020<br /> [ 800.284818] x23: ffffff8040238b08 x22: 0000000000000570 x21: 0000000000000158<br /> [ 800.291948] x20: 0000000000000000 x19: ffffff8040238000 x18: 0000000000000000<br /> [ 800.299078] x17: ffffffa8c1bd2000 x16: ffffffc080000000 x15: 0000000000000000<br /> [ 800.306208] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 800.313338] x11: 0000000000000040 x10: 0000000000001a40 x9 : ffffffd83b39757c<br /> [ 800.320468] x8 : ffffffd842786420 x7 : 7fffffffffffffff x6 : 0000000000ef32b0<br /> [ 800.327598] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : ffffffd842784980<br /> [ 800.334728] x2 : 0000000000000004 x1 : 0000000000010002 x0 : 000000ba4c0ca382<br /> [ 800.341859] Call trace:<br /> [ 800.344294] v3d_job_update_stats+0x60/0x130 [v3d]<br /> [ 800.349086] v3d_irq+0x124/0x2e0 [v3d]<br /> [ 800.352835] __handle_irq_event_percpu+0x58/0x218<br /> [ 800.357539] handle_irq_event+0x54/0xb8<br /> [ 800.361369] handle_fasteoi_irq+0xac/0x240<br /> [ 800.365458] handle_irq_desc+0x48/0x68<br /> [ 800.369200] generic_handle_domain_irq+0x24/0x38<br /> [ 800.373810] gic_handle_irq+0x48/0xd8<br /> [ 800.377464] call_on_irq_stack+0x24/0x58<br /> [ 800.381379] do_interrupt_handler+0x88/0x98<br /> [ 800.385554] el1_interrupt+0x34/0x68<br /> [ 800.389123] el1h_64_irq_handler+0x18/0x28<br /> [ 800.393211] el1h_64_irq+0x64/0x68<br /> [ 800.396603] default_idle_call+0x3c/0x168<br /> [ 800.400606] do_idle+0x1fc/0x230<br /> [ 800.403827] cpu_startup_entry+0x40/0x50<br /> [ 800.407742] rest_init+0xe4/0xf0<br /> [ 800.410962] start_kernel+0x5e8/0x790<br /> [ 800.414616] __primary_switched+0x80/0x90<br /> [ 800.418622] Code: 8b170277 8b160296 11000421 b9000861 (b9401ac1)<br /> [ 800.424707] ---[ end trace 0000000000000000 ]---<br /> [ 800.457313] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---<br /> <br /> This issue happens when the file descriptor is closed before the jobs<br /> submitted by it are completed. When the job completes, we update the<br /> global GPU stats and the per-fd GPU stats, which are exposed through<br /> fdinfo. If the file descriptor was closed, then the struct `v3d_file_priv`<br /> and its stats were already freed and we can&amp;#39;t update the per-fd stats.<br /> <br /> Therefore, if the file descriptor was already closed, don&amp;#39;t u<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/igen6: Fix NULL pointer dereference<br /> <br /> A kernel panic was reported with the following kernel log:<br /> <br /> EDAC igen6: Expected 2 mcs, but only 1 detected.<br /> BUG: unable to handle page fault for address: 000000000000d570<br /> ...<br /> Hardware name: Notebook V54x_6x_TU/V54x_6x_TU, BIOS Dasharo (coreboot+UEFI) v0.9.0 07/17/2024<br /> RIP: e030:ecclog_handler+0x7e/0xf0 [igen6_edac]<br /> ...<br /> igen6_probe+0x2a0/0x343 [igen6_edac]<br /> ...<br /> igen6_init+0xc5/0xff0 [igen6_edac]<br /> ...<br /> <br /> This issue occurred because one memory controller was disabled by<br /> the BIOS but the igen6_edac driver still checked all the memory<br /> controllers, including this absent one, to identify the source of<br /> the error. Accessing the null MMIO for the absent memory controller<br /> resulted in the oops above.<br /> <br /> Fix this issue by reverting the configuration structure to non-const<br /> and updating the field &amp;#39;res_cfg-&gt;num_imc&amp;#39; to reflect the number of<br /> detected memory controllers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix max_sge overflow in smb_extract_folioq_to_rdma()<br /> <br /> This fixes the following problem:<br /> <br /> [ 749.901015] [ T8673] run fstests cifs/001 at 2025-06-17 09:40:30<br /> [ 750.346409] [ T9870] ==================================================================<br /> [ 750.346814] [ T9870] BUG: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs]<br /> [ 750.347330] [ T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870<br /> [ 750.347705] [ T9870]<br /> [ 750.348077] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Not tainted 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary)<br /> [ 750.348082] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006<br /> [ 750.348085] [ T9870] Call Trace:<br /> [ 750.348086] [ T9870] <br /> [ 750.348088] [ T9870] dump_stack_lvl+0x76/0xa0<br /> [ 750.348106] [ T9870] print_report+0xd1/0x640<br /> [ 750.348116] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 750.348120] [ T9870] ? kasan_complete_mode_report_info+0x26/0x210<br /> [ 750.348124] [ T9870] kasan_report+0xe7/0x130<br /> [ 750.348128] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]<br /> [ 750.348262] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]<br /> [ 750.348377] [ T9870] __asan_report_store8_noabort+0x17/0x30<br /> [ 750.348381] [ T9870] smb_set_sge+0x2cc/0x3b0 [cifs]<br /> [ 750.348496] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs]<br /> [ 750.348625] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs]<br /> [ 750.348741] [ T9870] ? update_stack_state+0x2a0/0x670<br /> [ 750.348749] [ T9870] ? cifs_flush+0x153/0x320 [cifs]<br /> [ 750.348870] [ T9870] ? cifs_flush+0x153/0x320 [cifs]<br /> [ 750.348990] [ T9870] ? update_stack_state+0x2a0/0x670<br /> [ 750.348995] [ T9870] smbd_send+0x58c/0x9c0 [cifs]<br /> [ 750.349117] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs]<br /> [ 750.349231] [ T9870] ? unwind_get_return_address+0x65/0xb0<br /> [ 750.349235] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10<br /> [ 750.349242] [ T9870] ? arch_stack_walk+0xa7/0x100<br /> [ 750.349250] [ T9870] ? stack_trace_save+0x92/0xd0<br /> [ 750.349254] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs]<br /> [ 750.349374] [ T9870] ? kernel_text_address+0x173/0x190<br /> [ 750.349379] [ T9870] ? kasan_save_stack+0x39/0x70<br /> [ 750.349382] [ T9870] ? kasan_save_track+0x18/0x70<br /> [ 750.349385] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0<br /> [ 750.349389] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs]<br /> [ 750.349508] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs]<br /> [ 750.349626] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs]<br /> [ 750.349746] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]<br /> [ 750.349867] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs]<br /> [ 750.349900] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs]<br /> [ 750.349929] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs]<br /> [ 750.349958] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs]<br /> [ 750.349987] [ T9870] ? do_writepages+0x21f/0x590<br /> [ 750.349993] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140<br /> [ 750.349997] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 750.350002] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs]<br /> [ 750.350131] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs]<br /> [ 750.350255] [ T9870] ? local_clock_noinstr+0xe/0xd0<br /> [ 750.350261] [ T9870] ? kasan_save_alloc_info+0x37/0x60<br /> [ 750.350268] [ T9870] ? __kasan_check_write+0x14/0x30<br /> [ 750.350271] [ T9870] ? _raw_spin_lock+0x81/0xf0<br /> [ 750.350275] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 750.350278] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs]<br /> [ 750.350398] [ T9870] cifs_call_async+0x477/0xb00 [cifs]<br /> [ 750.350518] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]<br /> [ 750.350636] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs]<br /> [ 750.350756] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 750.350760] [ T9870] ? __kasan_check_write+0x14/0x30<br /> [ 750.350763] [ T98<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: atm: fix /proc/net/atm/lec handling<br /> <br /> /proc/net/atm/lec must ensure safety against dev_lec[] changes.<br /> <br /> It appears it had dev_put() calls without prior dev_hold(),<br /> leading to imbalance and UAF.