Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: Fix memory leak in ath11k_peer_rx_frag_setup<br /> <br /> crypto_alloc_shash() allocates resources, which should be released by<br /> crypto_free_shash(). When ath11k_peer_find() fails, there has memory<br /> leak. Add missing crypto_free_shash() to fix this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net<br /> <br /> Commit f5f9d4a314da ("nfsd: move reply cache initialization into nfsd<br /> startup") moved the initialization of the reply cache into nfsd startup,<br /> but didn&amp;#39;t account for the stats counters, which can be accessed before<br /> nfsd is ever started. The result can be a NULL pointer dereference when<br /> someone accesses /proc/fs/nfsd/reply_cache_stats while nfsd is still<br /> shut down.<br /> <br /> This is a regression and a user-triggerable oops in the right situation:<br /> <br /> - non-x86_64 arch<br /> - /proc/fs/nfsd is mounted in the namespace<br /> - nfsd is not started in the namespace<br /> - unprivileged user calls "cat /proc/fs/nfsd/reply_cache_stats"<br /> <br /> Although this is easy to trigger on some arches (like aarch64), on<br /> x86_64, calling this_cpu_ptr(NULL) evidently returns a pointer to the<br /> fixed_percpu_data. That struct looks just enough like a newly<br /> initialized percpu var to allow nfsd_reply_cache_stats_show to access<br /> it without Oopsing.<br /> <br /> Move the initialization of the per-net+per-cpu reply-cache counters<br /> back into nfsd_init_net, while leaving the rest of the reply cache<br /> allocations to be done at nfsd startup time.<br /> <br /> Kudos to Eirik who did most of the legwork to track this down.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: udlfb: Fix endpoint check<br /> <br /> The syzbot fuzzer detected a problem in the udlfb driver, caused by an<br /> endpoint not having the expected type:<br /> <br /> usb 1-1: Read EDID byte 0 failed: -71<br /> usb 1-1: Unable to get valid EDID from device/display<br /> ------------[ cut here ]------------<br /> usb 1-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880<br /> drivers/usb/core/urb.c:504<br /> Modules linked in:<br /> CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted<br /> 6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google<br /> 04/28/2023<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504<br /> ...<br /> Call Trace:<br /> <br /> dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980<br /> dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315<br /> dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111<br /> dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743<br /> <br /> The current approach for this issue failed to catch the problem<br /> because it only checks for the existence of a bulk-OUT endpoint; it<br /> doesn&amp;#39;t check whether this endpoint is the one that the driver will<br /> actually use.<br /> <br /> We can fix the problem by instead checking that the endpoint used by<br /> the driver does exist and is bulk-OUT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vmem: split pages when debug pagealloc is enabled<br /> <br /> Since commit bb1520d581a3 ("s390/mm: start kernel with DAT enabled")<br /> the kernel crashes early during boot when debug pagealloc is enabled:<br /> <br /> mem auto-init: stack:off, heap alloc:off, heap free:off<br /> addressing exception: 0005 ilc:2 [#1] SMP DEBUG_PAGEALLOC<br /> Modules linked in:<br /> CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rc3-09759-gc5666c912155 #630<br /> [..]<br /> Krnl Code: 00000000001325f6: ec5600248064 cgrj %r5,%r6,8,000000000013263e<br /> 00000000001325fc: eb880002000c srlg %r8,%r8,2<br /> #0000000000132602: b2210051 ipte %r5,%r1,%r0,0<br /> &gt;0000000000132606: b90400d1 lgr %r13,%r1<br /> 000000000013260a: 41605008 la %r6,8(%r5)<br /> 000000000013260e: a7db1000 aghi %r13,4096<br /> 0000000000132612: b221006d ipte %r6,%r13,%r0,0<br /> 0000000000132616: e3d0d0000171 lay %r13,4096(%r13)<br /> <br /> Call Trace:<br /> __kernel_map_pages+0x14e/0x320<br /> __free_pages_ok+0x23a/0x5a8)<br /> free_low_memory_core_early+0x214/0x2c8<br /> memblock_free_all+0x28/0x58<br /> mem_init+0xb6/0x228<br /> mm_core_init+0xb6/0x3b0<br /> start_kernel+0x1d2/0x5a8<br /> startup_continue+0x36/0x40<br /> Kernel panic - not syncing: Fatal exception: panic_on_oops<br /> <br /> This is caused by using large mappings on machines with EDAT1/EDAT2. Add<br /> the code to split the mappings into 4k pages if debug pagealloc is enabled<br /> by CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc kernel<br /> command line option.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: fw: Allow firmware to pass a empty env<br /> <br /> fw_getenv will use env entry to determine style of env,<br /> however it is legal for firmware to just pass a empty list.<br /> <br /> Check if first entry exist before running strchr to avoid<br /> null pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix potential race when tree connecting ipc<br /> <br /> Protect access of TCP_Server_Info::hostname when building the ipc tree<br /> name as it might get freed in cifsd thread and thus causing an<br /> use-after-free bug in __tree_connect_dfs_target(). Also, while at it,<br /> update status of IPC tcon on success and then avoid any extra tree<br /> connects.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DP<br /> <br /> Fixes OOPS on boards with ANX9805 DP encoders.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/sysv: Null check to prevent null-ptr-deref bug<br /> <br /> sb_getblk(inode-&gt;i_sb, parent) return a null ptr and taking lock on<br /> that leads to the null-ptr-deref bug.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix an uninit variable access bug in __ip6_make_skb()<br /> <br /> Syzbot reported a bug as following:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]<br /> BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]<br /> BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]<br /> BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956<br /> arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]<br /> arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]<br /> atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]<br /> __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956<br /> ip6_finish_skb include/net/ipv6.h:1122 [inline]<br /> ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987<br /> rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579<br /> rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922<br /> inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476<br /> ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530<br /> __sys_sendmsg net/socket.c:2559 [inline]<br /> __do_sys_sendmsg net/socket.c:2568 [inline]<br /> __se_sys_sendmsg net/socket.c:2566 [inline]<br /> __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:766 [inline]<br /> slab_alloc_node mm/slub.c:3452 [inline]<br /> __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491<br /> __do_kmalloc_node mm/slab_common.c:967 [inline]<br /> __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988<br /> kmalloc_reserve net/core/skbuff.c:492 [inline]<br /> __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565<br /> alloc_skb include/linux/skbuff.h:1270 [inline]<br /> __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684<br /> ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854<br /> rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915<br /> inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476<br /> ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530<br /> __sys_sendmsg net/socket.c:2559 [inline]<br /> __do_sys_sendmsg net/socket.c:2568 [inline]<br /> __se_sys_sendmsg net/socket.c:2566 [inline]<br /> __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> It is because icmp6hdr does not in skb linear region under the scenario<br /> of SOCK_RAW socket. Access icmp6_hdr(skb)-&gt;icmp6_type directly will<br /> trigger the uninit variable access bug.<br /> <br /> Use a local variable icmp6_type to carry the correct value in different<br /> scenarios.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer()<br /> <br /> &amp;#39;read&amp;#39; is freed when it is known to be NULL, but not when a read error<br /> occurs.<br /> <br /> Revert the logic to avoid a small leak, should a m920x_read() call fail.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT<br /> <br /> lppaca_shared_proc() takes a pointer to the lppaca which is typically<br /> accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads<br /> to checking if preemption is enabled, for example:<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693<br /> caller is lparcfg_data+0x408/0x19a0<br /> CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2<br /> Call Trace:<br /> dump_stack_lvl+0x154/0x200 (unreliable)<br /> check_preemption_disabled+0x214/0x220<br /> lparcfg_data+0x408/0x19a0<br /> ...<br /> <br /> This isn&amp;#39;t actually a problem however, as it does not matter which<br /> lppaca is accessed, the shared proc state will be the same.<br /> vcpudispatch_stats_procfs_init() already works around this by disabling<br /> preemption, but the lparcfg code does not, erroring any time<br /> /proc/powerpc/lparcfg is accessed with DEBUG_PREEMPT enabled.<br /> <br /> Instead of disabling preemption on the caller side, rework<br /> lppaca_shared_proc() to not take a pointer and instead directly access<br /> the lppaca, bypassing any potential preemption checks.<br /> <br /> [mpe: Rework to avoid needing a definition in paca.h and lppaca.h]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> debugobjects: Don&amp;#39;t wake up kswapd from fill_pool()<br /> <br /> syzbot is reporting a lockdep warning in fill_pool() because the allocation<br /> from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)<br /> and therefore tries to wake up kswapd, which acquires kswapd_wait::lock.<br /> <br /> Since fill_pool() might be called with arbitrary locks held, fill_pool()<br /> should not assume that acquiring kswapd_wait::lock is safe.<br /> <br /> Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for<br /> !__GFP_DIRECT_RECLAIM allocation.