Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix a possible null-pointer dereference in ni_clear()<br /> <br /> In a previous commit c1006bd13146, ni-&gt;mi.mrec in ni_write_inode()<br /> could be NULL, and thus a NULL check is added for this variable.<br /> <br /> However, in the same call stack, ni-&gt;mi.mrec can be also dereferenced<br /> in ni_clear():<br /> <br /> ntfs_evict_inode(inode)<br /> ni_write_inode(inode, ...)<br /> ni = ntfs_i(inode);<br /> is_rec_inuse(ni-&gt;mi.mrec) -&gt; Add a NULL check by previous commit<br /> ni_clear(ntfs_i(inode))<br /> is_rec_inuse(ni-&gt;mi.mrec) -&gt; No check<br /> <br /> Thus, a possible null-pointer dereference may exist in ni_clear().<br /> To fix it, a NULL check is added in this function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Fix leak of dev tracker<br /> <br /> At the stage of direction checks, the netdev reference tracker is<br /> already initialized, but released with wrong *_put() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srpt: Add a check for valid &amp;#39;mad_agent&amp;#39; pointer<br /> <br /> When unregistering MAD agent, srpt module has a non-null check<br /> for &amp;#39;mad_agent&amp;#39; pointer before invoking ib_unregister_mad_agent().<br /> This check can pass if &amp;#39;mad_agent&amp;#39; variable holds an error value.<br /> The &amp;#39;mad_agent&amp;#39; can have an error value for a short window when<br /> srpt_add_one() and srpt_remove_one() is executed simultaneously.<br /> <br /> In srpt module, added a valid pointer check for &amp;#39;sport-&gt;mad_agent&amp;#39;<br /> before unregistering MAD agent.<br /> <br /> This issue can hit when RoCE driver unregisters ib_device<br /> <br /> Stack Trace:<br /> ------------<br /> BUG: kernel NULL pointer dereference, address: 000000000000004d<br /> PGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> CPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: P<br /> Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020<br /> Workqueue: bnxt_re bnxt_re_task [bnxt_re]<br /> RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40<br /> Call Trace:<br /> ib_unregister_mad_agent+0x46/0x2f0 [ib_core]<br /> IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready<br /> ? __schedule+0x20b/0x560<br /> srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt]<br /> srpt_remove_one+0x20/0x150 [ib_srpt]<br /> remove_client_context+0x88/0xd0 [ib_core]<br /> bond0: (slave p2p1): link status definitely up, 100000 Mbps full duplex<br /> disable_device+0x8a/0x160 [ib_core]<br /> bond0: active interface up!<br /> ? kernfs_name_hash+0x12/0x80<br /> (NULL device *): Bonding Info Received: rdev: 000000006c0b8247<br /> __ib_unregister_device+0x42/0xb0 [ib_core]<br /> (NULL device *): Master: mode: 4 num_slaves:2<br /> ib_unregister_device+0x22/0x30 [ib_core]<br /> (NULL device *): Slave: id: 105069936 name:p2p1 link:0 state:0<br /> bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re]<br /> bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]

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.

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.

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.

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.

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.

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.

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.

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.

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.