In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/memmap: cast nr_pages to size_t before shifting\n\nIf the allocated size exceeds UINT_MAX, then it's necessary to cast\nthe mr->nr_pages value to size_t to prevent it from overflowing. In\npractice this isn't much of a concern as the required memory size will\nhave been validated upfront, and accounted to the user. And > 4GB sizes\nwill be necessary to make the lack of a cast a problem, which greatly\nexceeds normal user locked_vm settings that are generally in the kb to\nmb range. However, if root is used, then accounting isn't done, and\nthen it's possible to hit this issue.

In the Linux kernel, the following vulnerability has been resolved:\n\ndm: Always split write BIOs to zoned device limits\n\nAny zoned DM target that requires zone append emulation will use the\nblock layer zone write plugging. In such case, DM target drivers must\nnot split BIOs using dm_accept_partial_bio() as doing so can potentially\nlead to deadlocks with queue freeze operations. Regular write operations\nused to emulate zone append operations also cannot be split by the\ntarget driver as that would result in an invalid writen sector value\nreturn using the BIO sector.\n\nIn order for zoned DM target drivers to avoid such incorrect BIO\nsplitting, we must ensure that large BIOs are split before being passed\nto the map() function of the target, thus guaranteeing that the\nlimits for the mapped device are not exceeded.\n\ndm-crypt and dm-flakey are the only target drivers supporting zoned\ndevices and using dm_accept_partial_bio().\n\nIn the case of dm-crypt, this function is used to split BIOs to the\ninternal max_write_size limit (which will be suppressed in a different\npatch). However, since crypt_alloc_buffer() uses a bioset allowing only\nup to BIO_MAX_VECS (256) vectors in a BIO. The dm-crypt device\nmax_segments limit, which is not set and so default to BLK_MAX_SEGMENTS\n(128), must thus be respected and write BIOs split accordingly.\n\nIn the case of dm-flakey, since zone append emulation is not required,\nthe block layer zone write plugging is not used and no splitting of BIOs\nrequired.\n\nModify the function dm_zone_bio_needs_split() to use the block layer\nhelper function bio_needs_zone_write_plugging() to force a call to\nbio_split_to_limits() in dm_split_and_process_bio(). This allows DM\ntarget drivers to avoid using dm_accept_partial_bio() for write\noperations on zoned DM devices.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix scheduling while atomic in decompression path\n\n[ 16.945668][ C0] Call trace:\n[ 16.945678][ C0] dump_backtrace+0x110/0x204\n[ 16.945706][ C0] dump_stack_lvl+0x84/0xbc\n[ 16.945735][ C0] __schedule_bug+0xb8/0x1ac\n[ 16.945756][ C0] __schedule+0x724/0xbdc\n[ 16.945778][ C0] schedule+0x154/0x258\n[ 16.945793][ C0] bit_wait_io+0x48/0xa4\n[ 16.945808][ C0] out_of_line_wait_on_bit+0x114/0x198\n[ 16.945824][ C0] __sync_dirty_buffer+0x1f8/0x2e8\n[ 16.945853][ C0] __f2fs_commit_super+0x140/0x1f4\n[ 16.945881][ C0] f2fs_commit_super+0x110/0x28c\n[ 16.945898][ C0] f2fs_handle_error+0x1f4/0x2f4\n[ 16.945917][ C0] f2fs_decompress_cluster+0xc4/0x450\n[ 16.945942][ C0] f2fs_end_read_compressed_page+0xc0/0xfc\n[ 16.945959][ C0] f2fs_handle_step_decompress+0x118/0x1cc\n[ 16.945978][ C0] f2fs_read_end_io+0x168/0x2b0\n[ 16.945993][ C0] bio_endio+0x25c/0x2c8\n[ 16.946015][ C0] dm_io_dec_pending+0x3e8/0x57c\n[ 16.946052][ C0] clone_endio+0x134/0x254\n[ 16.946069][ C0] bio_endio+0x25c/0x2c8\n[ 16.946084][ C0] blk_update_request+0x1d4/0x478\n[ 16.946103][ C0] scsi_end_request+0x38/0x4cc\n[ 16.946129][ C0] scsi_io_completion+0x94/0x184\n[ 16.946147][ C0] scsi_finish_command+0xe8/0x154\n[ 16.946164][ C0] scsi_complete+0x90/0x1d8\n[ 16.946181][ C0] blk_done_softirq+0xa4/0x11c\n[ 16.946198][ C0] _stext+0x184/0x614\n[ 16.946214][ C0] __irq_exit_rcu+0x78/0x144\n[ 16.946234][ C0] handle_domain_irq+0xd4/0x154\n[ 16.946260][ C0] gic_handle_irq.33881+0x5c/0x27c\n[ 16.946281][ C0] call_on_irq_stack+0x40/0x70\n[ 16.946298][ C0] do_interrupt_handler+0x48/0xa4\n[ 16.946313][ C0] el1_interrupt+0x38/0x68\n[ 16.946346][ C0] el1h_64_irq_handler+0x20/0x30\n[ 16.946362][ C0] el1h_64_irq+0x78/0x7c\n[ 16.946377][ C0] finish_task_switch+0xc8/0x3d8\n[ 16.946394][ C0] __schedule+0x600/0xbdc\n[ 16.946408][ C0] preempt_schedule_common+0x34/0x5c\n[ 16.946423][ C0] preempt_schedule+0x44/0x48\n[ 16.946438][ C0] process_one_work+0x30c/0x550\n[ 16.946456][ C0] worker_thread+0x414/0x8bc\n[ 16.946472][ C0] kthread+0x16c/0x1e0\n[ 16.946486][ C0] ret_from_fork+0x10/0x20

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\novl: fix null pointer dereference in ovl_permission()\n\nFollowing process:\n P1 P2\n path_lookupat\n link_path_walk\n inode_permission\n ovl_permission\n ovl_i_path_real(inode, &realpath)\n path->dentry = ovl_i_dentry_upper(inode)\n drop_cache\n __dentry_kill(ovl_dentry)\n iput(ovl_inode)\n ovl_destroy_inode(ovl_inode)\n dput(oi->__upperdentry)\n dentry_kill(upperdentry)\n dentry_unlink_inode\n upperdentry->d_inode = NULL\n realinode = d_inode(realpath.dentry) // return NULL\n inode_permission(realinode)\n inode->i_sb // NULL pointer dereference\n, will trigger an null pointer dereference at realinode:\n [ 335.664979] BUG: kernel NULL pointer dereference,\n address: 0000000000000002\n [ 335.668032] CPU: 0 PID: 2592 Comm: ls Not tainted 6.3.0\n [ 335.669956] RIP: 0010:inode_permission+0x33/0x2c0\n [ 335.678939] Call Trace:\n [ 335.679165] \n [ 335.679371] ovl_permission+0xde/0x320\n [ 335.679723] inode_permission+0x15e/0x2c0\n [ 335.680090] link_path_walk+0x115/0x550\n [ 335.680771] path_lookupat.isra.0+0xb2/0x200\n [ 335.681170] filename_lookup+0xda/0x240\n [ 335.681922] vfs_statx+0xa6/0x1f0\n [ 335.682233] vfs_fstatat+0x7b/0xb0\n\nFetch a reproducer in [Link].\n\nUse the helper ovl_i_path_realinode() to get realinode and then do\nnon-nullptr checking.

In the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF\n\nThe call to get_user_pages_fast() in vmci_host_setup_notify() can return\nNULL context->notify_page causing a GPF. To avoid GPF check if\ncontext->notify_page == NULL and return error if so.\n\ngeneral protection fault, probably for non-canonical address\n 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: maybe wild-memory-access in range [0x0005088000000300-\n 0x0005088000000307]\nCPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1\nHardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014\nRIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0\nCall Trace:\n \n vmci_host_unlocked_ioctl+0x362/0x1f40\n __x64_sys_ioctl+0x1a1/0x230\n do_syscall_64+0x3a/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix possible underflow for displays with large vblank\n\n[Why]\nUnderflow observed when using a display with a large vblank region\nand low refresh rate\n\n[How]\nSimplify calculation of vblank_nom\n\nIncrease value for VBlankNomDefaultUS to 800us

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: check S1G action frame size\n\nBefore checking the action code, check that it even\nexists in the frame.

In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: stratix10-svc: Fix a potential resource leak in svc_create_memory_pool()\n\nsvc_create_memory_pool() is only called from stratix10_svc_drv_probe().\nMost of resources in the probe are managed, but not this memremap() call.\n\nThere is also no memunmap() call in the file.\n\nSo switch to devm_memremap() to avoid a resource leak.

In the Linux kernel, the following vulnerability has been resolved:\n\ncacheinfo: Fix shared_cpu_map to handle shared caches at different levels\n\nThe cacheinfo sets up the shared_cpu_map by checking whether the caches\nwith the same index are shared between CPUs. However, this will trigger\nslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.\nAnother problem is the mismatched shared_cpu_map when the shared cache does\nnot have the same index between CPUs.\n\nCPU0 I D L3\nindex 0 1 2 x\n ^ ^ ^ ^\nindex 0 1 2 3\nCPU1 I D L2 L3\n\nThis patch checks each cache is shared with all caches on other CPUs.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: nvidia-shield: Reference hid_device devm allocation of input_dev name\n\nUse hid_device for devm allocation of the input_dev name to avoid a\nuse-after-free. input_unregister_device would trigger devres cleanup of all\nresources associated with the input_dev, free-ing the name. The name would\nsubsequently be used in a uevent fired at the end of unregistering the\ninput_dev.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: use RCU for hci_conn_params and iterate safely in hci_sync\n\nhci_update_accept_list_sync iterates over hdev->pend_le_conns and\nhdev->pend_le_reports, and waits for controller events in the loop body,\nwithout holding hdev lock.\n\nMeanwhile, these lists and the items may be modified e.g. by\nle_scan_cleanup. This can invalidate the list cursor or any other item\nin the list, resulting to invalid behavior (eg use-after-free).\n\nUse RCU for the hci_conn_params action lists. Since the loop bodies in\nhci_sync block and we cannot use RCU or hdev->lock for the whole loop,\ncopy list items first and then iterate on the copy. Only the flags field\nis written from elsewhere, so READ_ONCE/WRITE_ONCE should guarantee we\nread valid values.\n\nFree params everywhere with hci_conn_params_free so the cleanup is\nguaranteed to be done properly.\n\nThis fixes the following, which can be triggered e.g. by BlueZ new\nmgmt-tester case "Add + Remove Device Nowait - Success", or by changing\nhci_le_set_cig_params to always return false, and running iso-tester:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)\nRead of size 8 at addr ffff888001265018 by task kworker/u3:0/32\n\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n\ndump_stack_lvl (./arch/x86/include/asm/irqflags.h:134 lib/dump_stack.c:107)\nprint_report (mm/kasan/report.c:320 mm/kasan/report.c:430)\n? __virt_addr_valid (./include/linux/mmzone.h:1915 ./include/linux/mmzone.h:2011 arch/x86/mm/physaddr.c:65)\n? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)\nkasan_report (mm/kasan/report.c:538)\n? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)\nhci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841)\n? __pfx_hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2780)\n? mutex_lock (kernel/locking/mutex.c:282)\n? __pfx_mutex_lock (kernel/locking/mutex.c:282)\n? __pfx_mutex_unlock (kernel/locking/mutex.c:538)\n? __pfx_update_passive_scan_sync (net/bluetooth/hci_sync.c:2861)\nhci_cmd_sync_work (net/bluetooth/hci_sync.c:306)\nprocess_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399)\nworker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538)\n? __pfx_worker_thread (kernel/workqueue.c:2480)\nkthread (kernel/kthread.c:376)\n? __pfx_kthread (kernel/kthread.c:331)\nret_from_fork (arch/x86/entry/entry_64.S:314)\n\n\nAllocated by task 31:\nkasan_save_stack (mm/kasan/common.c:46)\nkasan_set_track (mm/kasan/common.c:52)\n__kasan_kmalloc (mm/kasan/common.c:374 mm/kasan/common.c:383)\nhci_conn_params_add (./include/linux/slab.h:580 ./include/linux/slab.h:720 net/bluetooth/hci_core.c:2277)\nhci_connect_le_scan (net/bluetooth/hci_conn.c:1419 net/bluetooth/hci_conn.c:1589)\nhci_connect_cis (net/bluetooth/hci_conn.c:2266)\niso_connect_cis (net/bluetooth/iso.c:390)\niso_sock_connect (net/bluetooth/iso.c:899)\n__sys_connect (net/socket.c:2003 net/socket.c:2020)\n__x64_sys_connect (net/socket.c:2027)\ndo_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)\n\nFreed by task 15:\nkasan_save_stack (mm/kasan/common.c:46)\nkasan_set_track (mm/kasan/common.c:52)\nkasan_save_free_info (mm/kasan/generic.c:523)\n__kasan_slab_free (mm/kasan/common.c:238 mm/kasan/common.c:200 mm/kasan/common.c:244)\n__kmem_cache_free (mm/slub.c:1807 mm/slub.c:3787 mm/slub.c:3800)\nhci_conn_params_del (net/bluetooth/hci_core.c:2323)\nle_scan_cleanup (net/bluetooth/hci_conn.c:202)\nprocess_one_work (./arch/x86/include/asm/preempt.\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: pcie: fix NULL pointer dereference in iwl_pcie_irq_rx_msix_handler()\n\nrxq can be NULL only when trans_pcie->rxq is NULL and entry->entry\nis zero. For the case when entry->entry is not equal to 0, rxq\nwon't be NULL even if trans_pcie->rxq is NULL. Modify checker to\ncheck for trans_pcie->rxq.

In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle\n\nKASAN reported a null-ptr-deref error:\n\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 1373 Comm: modprobe\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:dmi_sysfs_entry_release\n...\nCall Trace:\n \n kobject_put\n dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs\n dmi_decode_table (drivers/firmware/dmi_scan.c:133)\n dmi_walk (drivers/firmware/dmi_scan.c:1115)\n dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs\n do_one_initcall (init/main.c:1296)\n ...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x4000000 from 0xffffffff81000000\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nIt is because previous patch added kobject_put() to release the memory\nwhich will call dmi_sysfs_entry_release() and list_del().\n\nHowever, list_add_tail(entry->list) is called after the error block,\nso the list_head is uninitialized and cannot be deleted.\n\nMove error handling to after list_add_tail to fix this.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: imx: clk-imx8mn: fix memory leak in imx8mn_clocks_probe\n\nUse devm_of_iomap() instead of of_iomap() to automatically handle\nthe unused ioremap region.\n\nIf any error occurs, regions allocated by kzalloc() will leak,\nbut using devm_kzalloc() instead will automatically free the memory\nusing devm_kfree().

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: install stub fence into potential unused fence pointers\n\nWhen using cpu to update page tables, vm update fences are unused.\nInstall stub fence into these fence pointers instead of NULL\nto avoid NULL dereference when calling dma_fence_wait() on them.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand\n\nWhile trying to get the subpage blocksize tests running, I hit the\nfollowing panic on generic/476\n\n assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229\n kernel BUG at fs/btrfs/subpage.c:229!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12\n Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023\n pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : btrfs_subpage_assert+0xbc/0xf0\n lr : btrfs_subpage_assert+0xbc/0xf0\n Call trace:\n btrfs_subpage_assert+0xbc/0xf0\n btrfs_subpage_clear_checked+0x38/0xc0\n btrfs_page_clear_checked+0x48/0x98\n btrfs_truncate_block+0x5d0/0x6a8\n btrfs_cont_expand+0x5c/0x528\n btrfs_write_check.isra.0+0xf8/0x150\n btrfs_buffered_write+0xb4/0x760\n btrfs_do_write_iter+0x2f8/0x4b0\n btrfs_file_write_iter+0x1c/0x30\n do_iter_readv_writev+0xc8/0x158\n do_iter_write+0x9c/0x210\n vfs_iter_write+0x24/0x40\n iter_file_splice_write+0x224/0x390\n direct_splice_actor+0x38/0x68\n splice_direct_to_actor+0x12c/0x260\n do_splice_direct+0x90/0xe8\n generic_copy_file_range+0x50/0x90\n vfs_copy_file_range+0x29c/0x470\n __arm64_sys_copy_file_range+0xcc/0x498\n invoke_syscall.constprop.0+0x80/0xd8\n do_el0_svc+0x6c/0x168\n el0_svc+0x50/0x1b0\n el0t_64_sync_handler+0x114/0x120\n el0t_64_sync+0x194/0x198\n\nThis happens because during btrfs_cont_expand we'll get a page, set it\nas mapped, and if it's not Uptodate we'll read it. However between the\nread and re-locking the page we could have called release_folio() on the\npage, but left the page in the file mapping. release_folio() can clear\nthe page private, and thus further down we blow up when we go to modify\nthe subpage bits.\n\nFix this by putting the set_page_extent_mapped() after the read. This\nis safe because read_folio() will call set_page_extent_mapped() before\nit does the read, and then if we clear page private but leave it on the\nmapping we're completely safe re-setting set_page_extent_mapped(). With\nthis patch I can now run generic/476 without panicing.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix DFS traversal oops without CONFIG_CIFS_DFS_UPCALL\n\nWhen compiled with CONFIG_CIFS_DFS_UPCALL disabled, cifs_dfs_d_automount\nis NULL. cifs.ko logic for mapping CIFS_FATTR_DFS_REFERRAL attributes to\nS_AUTOMOUNT and corresponding dentry flags is retained regardless of\nCONFIG_CIFS_DFS_UPCALL, leading to a NULL pointer dereference in\nVFS follow_automount() when traversing a DFS referral link:\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n ...\n Call Trace:\n \n __traverse_mounts+0xb5/0x220\n ? cifs_revalidate_mapping+0x65/0xc0 [cifs]\n step_into+0x195/0x610\n ? lookup_fast+0xe2/0xf0\n path_lookupat+0x64/0x140\n filename_lookup+0xc2/0x140\n ? __create_object+0x299/0x380\n ? kmem_cache_alloc+0x119/0x220\n ? user_path_at_empty+0x31/0x50\n user_path_at_empty+0x31/0x50\n __x64_sys_chdir+0x2a/0xd0\n ? exit_to_user_mode_prepare+0xca/0x100\n do_syscall_64+0x42/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nThis fix adds an inline cifs_dfs_d_automount() {return -EREMOTE} handler\nwhen CONFIG_CIFS_DFS_UPCALL is disabled. An alternative would be to\navoid flagging S_AUTOMOUNT, etc. without CONFIG_CIFS_DFS_UPCALL. This\napproach was chosen as it provides more control over the error path.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: storvsc: Fix handling of virtual Fibre Channel timeouts\n\nHyper-V provides the ability to connect Fibre Channel LUNs to the host\nsystem and present them in a guest VM as a SCSI device. I/O to the vFC\ndevice is handled by the storvsc driver. The storvsc driver includes a\npartial integration with the FC transport implemented in the generic\nportion of the Linux SCSI subsystem so that FC attributes can be displayed\nin /sys. However, the partial integration means that some aspects of vFC\ndon't work properly. Unfortunately, a full and correct integration isn't\npractical because of limitations in what Hyper-V provides to the guest.\n\nIn particular, in the context of Hyper-V storvsc, the FC transport timeout\nfunction fc_eh_timed_out() causes a kernel panic because it can't find the\nrport and dereferences a NULL pointer. The original patch that added the\ncall from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this\nregard.\n\nIn many cases a timeout is due to a transient condition, so the situation\ncan be improved by just continuing to wait like with other I/O requests\nissued by storvsc, and avoiding the guaranteed panic. For a permanent\nfailure, continuing to wait may result in a hung thread instead of a panic,\nwhich again may be better.\n\nSo fix the panic by removing the storvsc call to fc_eh_timed_out(). This\nallows storvsc to keep waiting for a response. The change has been tested\nby users who experienced a panic in fc_eh_timed_out() due to transient\ntimeouts, and it solves their problem.\n\nIn the future we may want to deprecate the vFC functionality in storvsc\nsince it can't be fully fixed. But it has current users for whom it is\nworking well enough, so it should probably stay for a while longer.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pci: tw68: Fix null-ptr-deref bug in buf prepare and finish\n\nWhen the driver calls tw68_risc_buffer() to prepare the buffer, the\nfunction call dma_alloc_coherent may fail, resulting in a empty buffer\nbuf->cpu. Later when we free the buffer or access the buffer, null ptr\nderef is triggered.\n\nThis bug is similar to the following one:\nhttps://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71.\n\nWe believe the bug can be also dynamically triggered from user side.\nSimilarly, we fix this by checking the return value of tw68_risc_buffer()\nand the value of buf->cpu before buffer free.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profile\n\nCallers of `btrfs_reduce_alloc_profile` expect it to return exactly\none allocation profile flag, and failing to do so may ultimately\nresult in a WARN_ON and remount-ro when allocating new blocks, like\nthe below transaction abort on 6.1.\n\n`btrfs_reduce_alloc_profile` has two ways of determining the profile,\nfirst it checks if a conversion balance is currently running and\nuses the profile we're converting to. If no balance is currently\nrunning, it returns the max-redundancy profile which at least one\nblock in the selected block group has.\n\nThis works by simply checking each known allocation profile bit in\nredundancy order. However, `btrfs_reduce_alloc_profile` has not been\nupdated as new flags have been added - first with the `DUP` profile\nand later with the RAID1C34 profiles.\n\nBecause of the way it checks, if we have blocks with different\nprofiles and at least one is known, that profile will be selected.\nHowever, if none are known we may return a flag set with multiple\nallocation profiles set.\n\nThis is currently only possible when a balance from one of the three\nunhandled profiles to another of the unhandled profiles is canceled\nafter allocating at least one block using the new profile.\n\nIn that case, a transaction abort like the below will occur and the\nfilesystem will need to be mounted with -o skip_balance to get it\nmounted rw again (but the balance cannot be resumed without a\nsimilar abort).\n\n [770.648] ------------[ cut here ]------------\n [770.648] BTRFS: Transaction aborted (error -22)\n [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs]\n [770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G W 6.1.0-0.deb11.7-powerpc64le #1 Debian 6.1.20-2~bpo11+1a~test\n [770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV\n [770.648] NIP: c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0\n [770.648] REGS: c000200089afe9a0 TRAP: 0700 Tainted: G W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test)\n [770.648] MSR: 9000000002029033 CR: 28848282 XER: 20040000\n [770.648] CFAR: c000000000135110 IRQMASK: 0\n GPR00: c00800000f6784f8 c000200089afec40 c00800000f7ea800 0000000000000026\n GPR04: 00000001004820c2 c000200089afea00 c000200089afe9f8 0000000000000027\n GPR08: c000200ffbfe7f98 c000000002127f90 ffffffffffffffd8 0000000026d6a6e8\n GPR12: 0000000028848282 c000200fff7f3800 5deadbeef0000122 c00000002269d000\n GPR16: c0002008c7797c40 c000200089afef17 0000000000000000 0000000000000000\n GPR20: 0000000000000000 0000000000000001 c000200008bc5a98 0000000000000001\n GPR24: 0000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800\n GPR28: c0000003c7308800 c00000002269d000 ffffffffffffffea 0000000000000001\n [770.648] NIP [c00800000f6784fc] find_free_extent+0x1d94/0x1e00 [btrfs]\n [770.648] LR [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs]\n [770.648] Call Trace:\n [770.648] [c000200089afec40] [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] (unreliable)\n [770.648] [c000200089afed30] [c00800000f681398] btrfs_reserve_extent+0x1a0/0x2f0 [btrfs]\n [770.648] [c000200089afeea0] [c00800000f681bf0] btrfs_alloc_tree_block+0x108/0x670 [btrfs]\n [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs]\n [770.648] [c000200089aff100] [c00800000f66c58c] btrfs_cow_block+0x144/0x288 [btrfs]\n [770.648] [c000200089aff1b0] [c00800000f67113c] btrfs_search_slot+0x6b4/0xcb0 [btrfs]\n [770.648] [c000200089aff2a0] [c00800000f679f60] lookup_inline_extent_backref+0x128/0x7c0 [btrfs]\n [770.648] [c000200089aff3b0] [c00800000f67b338] lookup_extent_backref+0x70/0x190 [btrfs]\n [770.648] [c000200089aff470] [c00800000f67b54c] __btrfs_free_extent+0xf4/0x1490 [btrfs]\n [770.648] [\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/drivers/hisi: Drop second sensor hi3660\n\nThe commit 74c8e6bffbe1 ("driver core: Add __alloc_size hint to devm\nallocators") exposes a panic "BRK handler: Fatal exception" on the\nhi3660_thermal_probe funciton.\nThis is because the function allocates memory for only one\nsensors array entry, but tries to fill up a second one.\n\nFix this by removing the unneeded second access.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: check IFF_UP earlier in Tx path\n\nXsk Tx can be triggered via either sendmsg() or poll() syscalls. These\ntwo paths share a call to common function xsk_xmit() which has two\nsanity checks within. A pseudo code example to show the two paths:\n\n__xsk_sendmsg() : xsk_poll():\nif (unlikely(!xsk_is_bound(xs))) if (unlikely(!xsk_is_bound(xs)))\n return -ENXIO; return mask;\nif (unlikely(need_wait)) (...)\n return -EOPNOTSUPP; xsk_xmit()\nmark napi id\n(...)\nxsk_xmit()\n\nxsk_xmit():\nif (unlikely(!(xs->dev->flags & IFF_UP)))\n return -ENETDOWN;\nif (unlikely(!xs->tx))\n return -ENOBUFS;\n\nAs it can be observed above, in sendmsg() napi id can be marked on\ninterface that was not brought up and this causes a NULL ptr\ndereference:\n\n[31757.505631] BUG: kernel NULL pointer dereference, address: 0000000000000018\n[31757.512710] #PF: supervisor read access in kernel mode\n[31757.517936] #PF: error_code(0x0000) - not-present page\n[31757.523149] PGD 0 P4D 0\n[31757.525726] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[31757.530154] CPU: 26 PID: 95641 Comm: xdpsock Not tainted 6.2.0-rc5+ #40\n[31757.536871] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[31757.547457] RIP: 0010:xsk_sendmsg+0xde/0x180\n[31757.551799] Code: 00 75 a2 48 8b 00 a8 04 75 9b 84 d2 74 69 8b 85 14 01 00 00 85 c0 75 1b 48 8b 85 28 03 00 00 48 8b 80 98 00 00 00 48 8b 40 20 <8b> 40 18 89 85 14 01 00 00 8b bd 14 01 00 00 81 ff 00 01 00 00 0f\n[31757.570840] RSP: 0018:ffffc90034f27dc0 EFLAGS: 00010246\n[31757.576143] RAX: 0000000000000000 RBX: ffffc90034f27e18 RCX: 0000000000000000\n[31757.583389] RDX: 0000000000000001 RSI: ffffc90034f27e18 RDI: ffff88984cf3c100\n[31757.590631] RBP: ffff88984714a800 R08: ffff88984714a800 R09: 0000000000000000\n[31757.597877] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000fffffffa\n[31757.605123] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000000\n[31757.612364] FS: 00007fb4c5931180(0000) GS:ffff88afdfa00000(0000) knlGS:0000000000000000\n[31757.620571] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[31757.626406] CR2: 0000000000000018 CR3: 000000184b41c003 CR4: 00000000007706e0\n[31757.633648] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[31757.640894] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[31757.648139] PKRU: 55555554\n[31757.650894] Call Trace:\n[31757.653385] \n[31757.655524] sock_sendmsg+0x8f/0xa0\n[31757.659077] ? sockfd_lookup_light+0x12/0x70\n[31757.663416] __sys_sendto+0xfc/0x170\n[31757.667051] ? do_sched_setscheduler+0xdb/0x1b0\n[31757.671658] __x64_sys_sendto+0x20/0x30\n[31757.675557] do_syscall_64+0x38/0x90\n[31757.679197] entry_SYSCALL_64_after_hwframe+0x72/0xdc\n[31757.687969] Code: 8e f6 ff 44 8b 4c 24 2c 4c 8b 44 24 20 41 89 c4 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 3a 44 89 e7 48 89 44 24 08 e8 b5 8e f6 ff 48\n[31757.707007] RSP: 002b:00007ffd49c73c70 EFLAGS: 00000293 ORIG_RAX: 000000000000002c\n[31757.714694] RAX: ffffffffffffffda RBX: 000055a996565380 RCX: 00007fb4c5727c16\n[31757.721939] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\n[31757.729184] RBP: 0000000000000040 R08: 0000000000000000 R09: 0000000000000000\n[31757.736429] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000\n[31757.743673] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[31757.754940] \n\nTo fix this, let's make xsk_xmit a function that will be responsible for\ngeneric Tx, where RCU is handled accordingly and pull out sanity checks\nand xs->zc handling. Populate sanity checks to __xsk_sendmsg() and\nxsk_poll().

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/mdp5: Add check for kzalloc\n\nAs kzalloc may fail and return NULL pointer,\nit should be better to check the return value\nin order to avoid the NULL pointer dereference.\n\nPatchwork: https://patchwork.freedesktop.org/patch/514154/

In the Linux kernel, the following vulnerability has been resolved:\n\nphy: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe()\n\nThe size of array 'priv->ports[]' is INNO_PHY_PORT_NUM.\n\nIn the for loop, 'i' is used as the index for array 'priv->ports[]'\nwith a check (i > INNO_PHY_PORT_NUM) which indicates that\nINNO_PHY_PORT_NUM is allowed value for 'i' in the same loop.\n\nThis > comparison needs to be changed to >=, otherwise it potentially leads\nto an out of bounds write on the next iteration through the loop

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Do not corrupt the pfn list when doing batch carry\n\nIf batch->end is 0 then setting npfns[0] before computing the new value of\npfns will fail to adjust the pfn and result in various page accounting\ncorruptions. It should be ordered after.\n\nThis seems to result in various kinds of page meta-data corruption related\nfailures:\n\n WARNING: CPU: 1 PID: 527 at mm/gup.c:75 try_grab_folio+0x503/0x740\n Modules linked in:\n CPU: 1 PID: 527 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755+ #1\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:try_grab_folio+0x503/0x740\n Code: e3 01 48 89 de e8 6d c1 dd ff 48 85 db 0f 84 7c fe ff ff e8 4f bf dd ff 49 8d 47 ff 48 89 45 d0 e9 73 fe ff ff e8 3d bf dd ff <0f> 0b 31 db e9 d0 fc ff ff e8 2f bf dd ff 48 8b 5d c8 31 ff 48 89\n RSP: 0018:ffffc90000f37908 EFLAGS: 00010046\n RAX: 0000000000000000 RBX: 00000000fffffc02 RCX: ffffffff81504c26\n RDX: 0000000000000000 RSI: ffff88800d030000 RDI: 0000000000000002\n RBP: ffffc90000f37948 R08: 000000000003ca24 R09: 0000000000000008\n R10: 000000000003ca00 R11: 0000000000000023 R12: ffffea000035d540\n R13: 0000000000000001 R14: 0000000000000000 R15: ffffea000035d540\n FS: 00007fecbf659740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00000000200011c3 CR3: 000000000ef66006 CR4: 0000000000770ee0\n PKRU: 55555554\n Call Trace:\n \n internal_get_user_pages_fast+0xd32/0x2200\n pin_user_pages_fast+0x65/0x90\n pfn_reader_user_pin+0x376/0x390\n pfn_reader_next+0x14a/0x7b0\n pfn_reader_first+0x140/0x1b0\n iopt_area_fill_domain+0x74/0x210\n iopt_table_add_domain+0x30e/0x6e0\n iommufd_device_selftest_attach+0x7f/0x140\n iommufd_test+0x10ff/0x16f0\n iommufd_fops_ioctl+0x206/0x330\n __x64_sys_ioctl+0x10e/0x160\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/tests: helpers: Avoid a driver uaf\n\nwhen using __drm_kunit_helper_alloc_drm_device() the driver may be\ndereferenced by device-managed resources up until the device is\nfreed, which is typically later than the kunit-managed resource code\nfrees it. Fix this by simply make the driver device-managed as well.\n\nIn short, the sequence leading to the UAF is as follows:\n\nINIT:\nCode allocates a struct device as a kunit-managed resource.\nCode allocates a drm driver as a kunit-managed resource.\nCode allocates a drm device as a device-managed resource.\n\nEXIT:\nKunit resource cleanup frees the drm driver\nKunit resource cleanup puts the struct device, which starts a\n device-managed resource cleanup\ndevice-managed cleanup calls drm_dev_put()\ndrm_dev_put() dereferences the (now freed) drm driver -> Boom.\n\nRelated KASAN message:\n[55272.551542] ==================================================================\n[55272.551551] BUG: KASAN: slab-use-after-free in drm_dev_put.part.0+0xd4/0xe0 [drm]\n[55272.551603] Read of size 8 at addr ffff888127502828 by task kunit_try_catch/10353\n\n[55272.551612] CPU: 4 PID: 10353 Comm: kunit_try_catch Tainted: G U N 6.5.0-rc7+ #155\n[55272.551620] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021\n[55272.551626] Call Trace:\n[55272.551629] \n[55272.551633] dump_stack_lvl+0x57/0x90\n[55272.551639] print_report+0xcf/0x630\n[55272.551645] ? _raw_spin_lock_irqsave+0x5f/0x70\n[55272.551652] ? drm_dev_put.part.0+0xd4/0xe0 [drm]\n[55272.551694] kasan_report+0xd7/0x110\n[55272.551699] ? drm_dev_put.part.0+0xd4/0xe0 [drm]\n[55272.551742] drm_dev_put.part.0+0xd4/0xe0 [drm]\n[55272.551783] devres_release_all+0x15d/0x1f0\n[55272.551790] ? __pfx_devres_release_all+0x10/0x10\n[55272.551797] device_unbind_cleanup+0x16/0x1a0\n[55272.551802] device_release_driver_internal+0x3e5/0x540\n[55272.551808] ? kobject_put+0x5d/0x4b0\n[55272.551814] bus_remove_device+0x1f1/0x3f0\n[55272.551819] device_del+0x342/0x910\n[55272.551826] ? __pfx_device_del+0x10/0x10\n[55272.551830] ? lock_release+0x339/0x5e0\n[55272.551836] ? kunit_remove_resource+0x128/0x290 [kunit]\n[55272.551845] ? __pfx_lock_release+0x10/0x10\n[55272.551851] platform_device_del.part.0+0x1f/0x1e0\n[55272.551856] ? _raw_spin_unlock_irqrestore+0x30/0x60\n[55272.551863] kunit_remove_resource+0x195/0x290 [kunit]\n[55272.551871] ? _raw_spin_unlock_irqrestore+0x30/0x60\n[55272.551877] kunit_cleanup+0x78/0x120 [kunit]\n[55272.551885] ? __kthread_parkme+0xc1/0x1f0\n[55272.551891] ? __pfx_kunit_try_run_case_cleanup+0x10/0x10 [kunit]\n[55272.551900] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit]\n[55272.551909] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit]\n[55272.551919] kthread+0x2e7/0x3c0\n[55272.551924] ? __pfx_kthread+0x10/0x10\n[55272.551929] ret_from_fork+0x2d/0x70\n[55272.551935] ? __pfx_kthread+0x10/0x10\n[55272.551940] ret_from_fork_asm+0x1b/0x30\n[55272.551948] \n\n[55272.551953] Allocated by task 10351:\n[55272.551956] kasan_save_stack+0x1c/0x40\n[55272.551962] kasan_set_track+0x21/0x30\n[55272.551966] __kasan_kmalloc+0x8b/0x90\n[55272.551970] __kmalloc+0x5e/0x160\n[55272.551976] kunit_kmalloc_array+0x1c/0x50 [kunit]\n[55272.551984] drm_exec_test_init+0xfa/0x2c0 [drm_exec_test]\n[55272.551991] kunit_try_run_case+0xdd/0x250 [kunit]\n[55272.551999] kunit_generic_run_threadfn_adapter+0x4a/0x90 [kunit]\n[55272.552008] kthread+0x2e7/0x3c0\n[55272.552012] ret_from_fork+0x2d/0x70\n[55272.552017] ret_from_fork_asm+0x1b/0x30\n\n[55272.552024] Freed by task 10353:\n[55272.552027] kasan_save_stack+0x1c/0x40\n[55272.552032] kasan_set_track+0x21/0x30\n[55272.552036] kasan_save_free_info+0x27/0x40\n[55272.552041] __kasan_slab_free+0x106/0x180\n[55272.552046] slab_free_freelist_hook+0xb3/0x160\n[55272.552051] __kmem_cache_free+0xb2/0x290\n[55272.552056] kunit_remove_resource+0x195/0x290 [kunit]\n[55272.552064] kunit_cleanup+0x7\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nwatchdog: Fix kmemleak in watchdog_cdev_register\n\nkmemleak reports memory leaks in watchdog_dev_register, as follows:\nunreferenced object 0xffff888116233000 (size 2048):\n comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s)\n hex dump (first 32 bytes):\n 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff .........0#.....\n 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#.............\n backtrace:\n [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220\n [<000000006a389304>] kmalloc_trace+0x21/0x110\n [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog]\n [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog]\n [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog]\n [<000000001f730178>] 0xffffffffc10880ae\n [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0\n [<00000000b98be325>] do_init_module+0x1ca/0x5f0\n [<0000000046d08e7c>] load_module+0x6133/0x70f0\n ...\n\nunreferenced object 0xffff888105b9fa80 (size 16):\n comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s)\n hex dump (first 16 bytes):\n 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1.......\n backtrace:\n [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220\n [<00000000486ab89b>] __kmalloc_node_track_caller+0x44/0x1b0\n [<000000005a39aab0>] kvasprintf+0xb5/0x140\n [<0000000024806f85>] kvasprintf_const+0x55/0x180\n [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150\n [<00000000a92e820b>] dev_set_name+0xab/0xe0\n [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog]\n [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog]\n [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog]\n [<000000001f730178>] 0xffffffffc10880ae\n [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0\n [<00000000b98be325>] do_init_module+0x1ca/0x5f0\n [<0000000046d08e7c>] load_module+0x6133/0x70f0\n ...\n\nThe reason is that put_device is not be called if cdev_device_add fails\nand wdd->id != 0.\n\nwatchdog_cdev_register\n wd_data = kzalloc [1]\n err = dev_set_name [2]\n ..\n err = cdev_device_add\n if (err) {\n if (wdd->id == 0) { // wdd->id != 0\n ..\n }\n return err; // [1],[2] would be leaked\n\nTo fix it, call put_device in all wdd->id cases.