Vulnerabilidades

*** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().<br /> <br /> syzkaller reported a null-ptr-deref in sock_omalloc() while allocating<br /> a CALIPSO option. [0]<br /> <br /> The NULL is of struct sock, which was fetched by sk_to_full_sk() in<br /> calipso_req_setattr().<br /> <br /> Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),<br /> reqsk-&gt;rsk_listener could be NULL when SYN Cookie is returned to its<br /> client, as hinted by the leading SYN Cookie log.<br /> <br /> Here are 3 options to fix the bug:<br /> <br /> 1) Return 0 in calipso_req_setattr()<br /> 2) Return an error in calipso_req_setattr()<br /> 3) Alaways set rsk_listener<br /> <br /> 1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie<br /> for CALIPSO. 3) is also no go as there have been many efforts to reduce<br /> atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35<br /> ("tcp/dccp: do not touch listener sk_refcnt under synflood").<br /> <br /> As of the blamed commit, SYN Cookie already did not need refcounting,<br /> and no one has stumbled on the bug for 9 years, so no CALIPSO user will<br /> care about SYN Cookie.<br /> <br /> Let&amp;#39;s return an error in calipso_req_setattr() and calipso_req_delattr()<br /> in the SYN Cookie case.<br /> <br /> This can be reproduced by [1] on Fedora and now connect() of nc times out.<br /> <br /> [0]:<br /> TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]<br /> RIP: 0010:sock_net include/net/sock.h:655 [inline]<br /> RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806<br /> Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b<br /> RSP: 0018:ffff88811af89038 EFLAGS: 00010216<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400<br /> RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030<br /> RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e<br /> R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000<br /> R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050<br /> FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0<br /> PKRU: 80000000<br /> Call Trace:<br /> <br /> ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288<br /> calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204<br /> calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597<br /> netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249<br /> selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342<br /> selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551<br /> security_inet_conn_request+0x50/0xa0 security/security.c:4945<br /> tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825<br /> tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275<br /> tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328<br /> tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781<br /> tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667<br /> tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904<br /> ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436<br /> ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> NF_HOOK include/linux/netfilter.h:308 [inline]<br /> ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491<br /> dst_input include/net/dst.h:469 [inline]<br /> ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]<br /> ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> NF_HOOK include/linux/netf<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: santizize the arguments from userspace when adding a device<br /> <br /> Sanity check the values for queue depth and number of queues<br /> we get from userspace when adding a device.

*** Pendiente de traducción *** CHMLib through 2bef8d0, as used in SumatraPDF and other products, has a chm_lib.c _chm_decompress_block integer overflow. There is a resultant heap-based buffer overflow in _chm_fetch_bytes.

*** Pendiente de traducción *** mtr through 0.95, in certain privileged contexts, mishandles execution of a program specified by the MTR_PACKET environment variable. NOTE: mtr on macOS may often have Sudo rules, as an indirect consequence of Homebrew not installing setuid binaries.