Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: avoid format-overflow warning<br /> <br /> With gcc and W=1 option, there&amp;#39;s a warning like this:<br /> <br /> fs/f2fs/compress.c: In function ‘f2fs_init_page_array_cache’:<br /> fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between<br /> 1 and 7 bytes into a region of size between 5 and 8<br /> [-Werror=format-overflow=]<br /> 1984 | sprintf(slab_name, "f2fs_page_array_entry-%u:%u", MAJOR(dev),<br /> MINOR(dev));<br /> | ^~<br /> <br /> String "f2fs_page_array_entry-%u:%u" can up to 35. The first "%u" can up<br /> to 4 and the second "%u" can up to 7, so total size is "24 + 4 + 7 = 35".<br /> slab_name&amp;#39;s size should be 35 rather than 32.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: Fix null dereference on suspend<br /> <br /> A race condition exists where a synchronous (noqueue) transfer can be<br /> active during a system suspend. This can cause a null pointer<br /> dereference exception to occur when the system resumes.<br /> <br /> Example order of events leading to the exception:<br /> 1. spi_sync() calls __spi_transfer_message_noqueue() which sets<br /> ctlr-&gt;cur_msg<br /> 2. Spi transfer begins via spi_transfer_one_message()<br /> 3. System is suspended interrupting the transfer context<br /> 4. System is resumed<br /> 6. spi_controller_resume() calls spi_start_queue() which resets cur_msg<br /> to NULL<br /> 7. Spi transfer context resumes and spi_finalize_current_message() is<br /> called which dereferences cur_msg (which is now NULL)<br /> <br /> Wait for synchronous transfers to complete before suspending by<br /> acquiring the bus mutex and setting/checking a suspend flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer<br /> <br /> Prior to LLVM 15.0.0, LLVM&amp;#39;s integrated assembler would incorrectly<br /> byte-swap NOP when compiling for big-endian, and the resulting series of<br /> bytes happened to match the encoding of FNMADD S21, S30, S0, S0.<br /> <br /> This went unnoticed until commit:<br /> <br /> 34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")<br /> <br /> Prior to that commit, the kernel would always enable the use of FPSIMD<br /> early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of<br /> FNMADD within the kernel was not detected, but could result in the<br /> corruption of user or kernel FPSIMD state.<br /> <br /> After that commit, the instructions happen to trap during boot prior to<br /> FPSIMD being detected and enabled, e.g.<br /> <br /> | Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD<br /> | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : __pi_strcmp+0x1c/0x150<br /> | lr : populate_properties+0xe4/0x254<br /> | sp : ffffd014173d3ad0<br /> | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000<br /> | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008<br /> | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044<br /> | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005<br /> | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000<br /> | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000<br /> | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000<br /> | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000<br /> | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a<br /> | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8<br /> | Kernel panic - not syncing: Unhandled exception<br /> | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1<br /> | Hardware name: linux,dummy-virt (DT)<br /> | Call trace:<br /> | dump_backtrace+0xec/0x108<br /> | show_stack+0x18/0x2c<br /> | dump_stack_lvl+0x50/0x68<br /> | dump_stack+0x18/0x24<br /> | panic+0x13c/0x340<br /> | el1t_64_irq_handler+0x0/0x1c<br /> | el1_abort+0x0/0x5c<br /> | el1h_64_sync+0x64/0x68<br /> | __pi_strcmp+0x1c/0x150<br /> | unflatten_dt_nodes+0x1e8/0x2d8<br /> | __unflatten_device_tree+0x5c/0x15c<br /> | unflatten_device_tree+0x38/0x50<br /> | setup_arch+0x164/0x1e0<br /> | start_kernel+0x64/0x38c<br /> | __primary_switched+0xbc/0xc4<br /> <br /> Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is<br /> either GNU as or LLVM&amp;#39;s IAS 15.0.0 and newer, which contains the linked<br /> commit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix use-after-free in smb2_query_info_compound()<br /> <br /> The following UAF was triggered when running fstests generic/072 with<br /> KASAN enabled against Windows Server 2022 and mount options<br /> &amp;#39;multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm&amp;#39;<br /> <br /> BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> Read of size 8 at addr ffff888014941048 by task xfs_io/27534<br /> <br /> CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> Call Trace:<br /> dump_stack_lvl+0x4a/0x80<br /> print_report+0xcf/0x650<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? __phys_addr+0x46/0x90<br /> kasan_report+0xda/0x110<br /> ? smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> ? smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs]<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? __stack_depot_save+0x39/0x480<br /> ? kasan_save_stack+0x33/0x60<br /> ? kasan_set_track+0x25/0x30<br /> ? ____kasan_slab_free+0x126/0x170<br /> smb2_queryfs+0xc2/0x2c0 [cifs]<br /> ? __pfx_smb2_queryfs+0x10/0x10 [cifs]<br /> ? __pfx___lock_acquire+0x10/0x10<br /> smb311_queryfs+0x210/0x220 [cifs]<br /> ? __pfx_smb311_queryfs+0x10/0x10 [cifs]<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? __lock_acquire+0x480/0x26c0<br /> ? lock_release+0x1ed/0x640<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? do_raw_spin_unlock+0x9b/0x100<br /> cifs_statfs+0x18c/0x4b0 [cifs]<br /> statfs_by_dentry+0x9b/0xf0<br /> fd_statfs+0x4e/0xb0<br /> __do_sys_fstatfs+0x7f/0xe0<br /> ? __pfx___do_sys_fstatfs+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? lockdep_hardirqs_on_prepare+0x136/0x200<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Allocated by task 27534:<br /> kasan_save_stack+0x33/0x60<br /> kasan_set_track+0x25/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> open_cached_dir+0x71b/0x1240 [cifs]<br /> smb2_query_info_compound+0x5c3/0x6d0 [cifs]<br /> smb2_queryfs+0xc2/0x2c0 [cifs]<br /> smb311_queryfs+0x210/0x220 [cifs]<br /> cifs_statfs+0x18c/0x4b0 [cifs]<br /> statfs_by_dentry+0x9b/0xf0<br /> fd_statfs+0x4e/0xb0<br /> __do_sys_fstatfs+0x7f/0xe0<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Freed by task 27534:<br /> kasan_save_stack+0x33/0x60<br /> kasan_set_track+0x25/0x30<br /> kasan_save_free_info+0x2b/0x50<br /> ____kasan_slab_free+0x126/0x170<br /> slab_free_freelist_hook+0xd0/0x1e0<br /> __kmem_cache_free+0x9d/0x1b0<br /> open_cached_dir+0xff5/0x1240 [cifs]<br /> smb2_query_info_compound+0x5c3/0x6d0 [cifs]<br /> smb2_queryfs+0xc2/0x2c0 [cifs]<br /> <br /> This is a race between open_cached_dir() and cached_dir_lease_break()<br /> where the cache entry for the open directory handle receives a lease<br /> break while creating it. And before returning from open_cached_dir(),<br /> we put the last reference of the new @cfid because of<br /> !@cfid-&gt;has_lease.<br /> <br /> Besides the UAF, while running xfstests a lot of missed lease breaks<br /> have been noticed in tests that run several concurrent statfs(2) calls<br /> on those cached fids<br /> <br /> CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...<br /> CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...<br /> CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108<br /> CIFS: VFS: Dump pending requests:<br /> CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...<br /> CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...<br /> CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108<br /> ...<br /> <br /> To fix both, in open_cached_dir() ensure that @cfid-&gt;has_lease is set<br /> right before sending out compounded request so that any potential<br /> lease break will be get processed by demultiplex thread while we&amp;#39;re<br /> still caching @cfid. And, if open failed for some reason, re-check<br /> @cfid-&gt;has_lease to decide whether or not put lease reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid NULL dereference of timing generator<br /> <br /> [Why &amp; How]<br /> Check whether assigned timing generator is NULL or not before<br /> accessing its funcs to prevent NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imon: fix access to invalid resource for the second interface<br /> <br /> imon driver probes two USB interfaces, and at the probe of the second<br /> interface, the driver assumes blindly that the first interface got<br /> bound with the same imon driver. It&amp;#39;s usually true, but it&amp;#39;s still<br /> possible that the first interface is bound with another driver via a<br /> malformed descriptor. Then it may lead to a memory corruption, as<br /> spotted by syzkaller; imon driver accesses the data from drvdata as<br /> struct imon_context object although it&amp;#39;s a completely different one<br /> that was assigned by another driver.<br /> <br /> This patch adds a sanity check -- whether the first interface is<br /> really bound with the imon driver or not -- for avoiding the problem<br /> above at the probe time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix use-after-free bug in cifs_debug_data_proc_show()<br /> <br /> Skip SMB sessions that are being teared down<br /> (e.g. @ses-&gt;ses_status == SES_EXITING) in cifs_debug_data_proc_show()<br /> to avoid use-after-free in @ses.<br /> <br /> This fixes the following GPF when reading from /proc/fs/cifs/DebugData<br /> while mounting and umounting<br /> <br /> [ 816.251274] general protection fault, probably for non-canonical<br /> address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI<br /> ...<br /> [ 816.260138] Call Trace:<br /> [ 816.260329] <br /> [ 816.260499] ? die_addr+0x36/0x90<br /> [ 816.260762] ? exc_general_protection+0x1b3/0x410<br /> [ 816.261126] ? asm_exc_general_protection+0x26/0x30<br /> [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs]<br /> [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs]<br /> [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs]<br /> [ 816.262689] ? seq_read_iter+0x379/0x470<br /> [ 816.262995] seq_read_iter+0x118/0x470<br /> [ 816.263291] proc_reg_read_iter+0x53/0x90<br /> [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 816.263945] vfs_read+0x201/0x350<br /> [ 816.264211] ksys_read+0x75/0x100<br /> [ 816.264472] do_syscall_64+0x3f/0x90<br /> [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 816.265135] RIP: 0033:0x7fd5e669d381

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: mmc_spi: fix error handling in mmc_spi_probe()<br /> <br /> If mmc_add_host() fails, it doesn&amp;#39;t need to call mmc_remove_host(),<br /> or it will cause null-ptr-deref, because of deleting a not added<br /> device in mmc_remove_host().<br /> <br /> To fix this, goto label &amp;#39;fail_glue_init&amp;#39;, if mmc_add_host() fails,<br /> and change the label &amp;#39;fail_add_host&amp;#39; to &amp;#39;fail_gpiod_request&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sdio: fix possible resource leaks in some error paths<br /> <br /> If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can<br /> not release the resources, because the sdio function is not presented<br /> in these two cases, it won&amp;#39;t call of_node_put() or put_device().<br /> <br /> To fix these leaks, make sdio_func_present() only control whether<br /> device_del() needs to be called or not, then always call of_node_put()<br /> and put_device().<br /> <br /> In error case in sdio_init_func(), the reference of &amp;#39;card-&gt;dev&amp;#39; is<br /> not get, to avoid redundant put in sdio_free_func_cis(), move the<br /> get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),<br /> it can keep the get/put function be balanced.<br /> <br /> Without this patch, while doing fault inject test, it can get the<br /> following leak reports, after this fix, the leak is gone.<br /> <br /> unreferenced object 0xffff888112514000 (size 2048):<br /> comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s)<br /> hex dump (first 32 bytes):<br /> 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......<br /> 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....<br /> backtrace:<br /> [] kmalloc_trace+0x21/0x110<br /> [] mmc_alloc_card+0x38/0xb0 [mmc_core]<br /> [] mmc_sdio_init_card+0xde/0x170 [mmc_core]<br /> [] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]<br /> [] mmc_rescan+0x54a/0x640 [mmc_core]<br /> <br /> unreferenced object 0xffff888112511000 (size 2048):<br /> comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s)<br /> hex dump (first 32 bytes):<br /> 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......<br /> 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....<br /> backtrace:<br /> [] kmalloc_trace+0x21/0x110<br /> [] sdio_alloc_func+0x35/0x100 [mmc_core]<br /> [] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]<br /> [] mmc_rescan+0x54a/0x640 [mmc_core]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Fix invalid page access after closing deferred I/O devices<br /> <br /> When a fbdev with deferred I/O is once opened and closed, the dirty<br /> pages still remain queued in the pageref list, and eventually later<br /> those may be processed in the delayed work. This may lead to a<br /> corruption of pages, hitting an Oops.<br /> <br /> This patch makes sure to cancel the delayed work and clean up the<br /> pageref list at closing the device for addressing the bug. A part of<br /> the cleanup code is factored out as a new helper function that is<br /> called from the common fb_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: blocklist the kclient when receiving corrupted snap trace<br /> <br /> When received corrupted snap trace we don&amp;#39;t know what exactly has<br /> happened in MDS side. And we shouldn&amp;#39;t continue IOs and metadatas<br /> access to MDS, which may corrupt or get incorrect contents.<br /> <br /> This patch will just block all the further IO/MDS requests<br /> immediately and then evict the kclient itself.<br /> <br /> The reason why we still need to evict the kclient just after<br /> blocking all the further IOs is that the MDS could revoke the caps<br /> faster.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.