In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init()\n\nIf of_iomap() failed, 'aic' should be freed before return. Otherwise\nthere is a memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: fbcon: release buffer when fbcon_do_set_font() failed\n\nsyzbot is reporting memory leak at fbcon_do_set_font() [1], for\ncommit a5a923038d70 ("fbdev: fbcon: Properly revert changes when\nvc_resize() failed") missed that the buffer might be newly allocated\nby fbcon_set_font().

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dp: add atomic_check to bridge ops\n\nDRM commit_tails() will disable downstream crtc/encoder/bridge if\nboth disable crtc is required and crtc->active is set before pushing\na new frame downstream.\n\nThere is a rare case that user space display manager issue an extra\nscreen update immediately followed by close DRM device while down\nstream display interface is disabled. This extra screen update will\ntimeout due to the downstream interface is disabled but will cause\ncrtc->active be set. Hence the followed commit_tails() called by\ndrm_release() will pass the disable downstream crtc/encoder/bridge\nconditions checking even downstream interface is disabled.\nThis cause the crash to happen at dp_bridge_disable() due to it trying\nto access the main link register to push the idle pattern out while main\nlink clocks is disabled.\n\nThis patch adds atomic_check to prevent the extra frame will not\nbe pushed down if display interface is down so that crtc->active\nwill not be set neither. This will fail the conditions checking\nof disabling down stream crtc/encoder/bridge which prevent\ndrm_release() from calling dp_bridge_disable() so that crash\nat dp_bridge_disable() prevented.\n\nThere is no protection in the DRM framework to check if the display\npipeline has been already disabled before trying again. The only\ncheck is the crtc_state->active but this is controlled by usermode\nusing UAPI. Hence if the usermode sets this and then crashes, the\ndriver needs to protect against double disable.\n\nSError Interrupt on CPU7, code 0x00000000be000411 -- SError\nCPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19\nHardware name: Google Lazor (rev3 - 8) (DT)\npstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __cmpxchg_case_acq_32+0x14/0x2c\nlr : do_raw_spin_lock+0xa4/0xdc\nsp : ffffffc01092b6a0\nx29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038\nx26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000\nx23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008\nx20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000\nx17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0\nx14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4\nx8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001\nx5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0\nx2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0\nKernel panic - not syncing: Asynchronous SError Interrupt\nCPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19\nHardware name: Google Lazor (rev3 - 8) (DT)\nCall trace:\n dump_backtrace.part.0+0xbc/0xe4\n show_stack+0x24/0x70\n dump_stack_lvl+0x68/0x84\n dump_stack+0x18/0x34\n panic+0x14c/0x32c\n nmi_panic+0x58/0x7c\n arm64_serror_panic+0x78/0x84\n do_serror+0x40/0x64\n el1h_64_error_handler+0x30/0x48\n el1h_64_error+0x68/0x6c\n __cmpxchg_case_acq_32+0x14/0x2c\n _raw_spin_lock_irqsave+0x38/0x4c\n lock_timer_base+0x40/0x78\n __mod_timer+0xf4/0x25c\n schedule_timeout+0xd4/0xfc\n __wait_for_common+0xac/0x140\n wait_for_completion_timeout+0x2c/0x54\n dp_ctrl_push_idle+0x40/0x88\n dp_bridge_disable+0x24/0x30\n drm_atomic_bridge_chain_disable+0x90/0xbc\n drm_atomic_helper_commit_modeset_disables+0x198/0x444\n msm_atomic_commit_tail+0x1d0/0x374\n commit_tail+0x80/0x108\n drm_atomic_helper_commit+0x118/0x11c\n drm_atomic_commit+0xb4/0xe0\n drm_client_modeset_commit_atomic+0x184/0x224\n drm_client_modeset_commit_locked+0x58/0x160\n drm_client_modeset_commit+0x3c/0x64\n __drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac\n drm_fb_helper_set_par+0x74/0x80\n drm_fb_helper_hotplug_event+0xdc/0xe0\n __drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac\n drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c\n drm_fb_helper_lastclose+0x20/0x2c\n drm_lastclose+0x44/0x6c\n drm_release+0x88/0xd4\n __fput+0x104/0x220\n ____fput+0x1c/0x28\n task_work_run+0x8c/0x100\n d\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: fix memory leak in set_mempolicy_home_node system call\n\nWhen encountering any vma in the range with policy other than MPOL_BIND or\nMPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on\nthe policy just allocated with mpol_dup().\n\nThis allows arbitrary users to leak kernel memory.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs: writeback: fix use-after-free in __mark_inode_dirty()\n\nAn use-after-free issue occurred when __mark_inode_dirty() get the\nbdi_writeback that was in the progress of switching.\n\nCPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1\n......\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __mark_inode_dirty+0x124/0x418\nlr : __mark_inode_dirty+0x118/0x418\nsp : ffffffc08c9dbbc0\n........\nCall trace:\n __mark_inode_dirty+0x124/0x418\n generic_update_time+0x4c/0x60\n file_modified+0xcc/0xd0\n ext4_buffered_write_iter+0x58/0x124\n ext4_file_write_iter+0x54/0x704\n vfs_write+0x1c0/0x308\n ksys_write+0x74/0x10c\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x114\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x40/0xe4\n el0t_64_sync_handler+0x120/0x12c\n el0t_64_sync+0x194/0x198\n\nRoot cause is:\n\nsystemd-random-seed kworker\n----------------------------------------------------------------------\n___mark_inode_dirty inode_switch_wbs_work_fn\n\n spin_lock(&inode->i_lock);\n inode_attach_wb\n locked_inode_to_wb_and_lock_list\n get inode->i_wb\n spin_unlock(&inode->i_lock);\n spin_lock(&wb->list_lock)\n spin_lock(&inode->i_lock)\n inode_io_list_move_locked\n spin_unlock(&wb->list_lock)\n spin_unlock(&inode->i_lock)\n spin_lock(&old_wb->list_lock)\n inode_do_switch_wbs\n spin_lock(&inode->i_lock)\n inode->i_wb = new_wb\n spin_unlock(&inode->i_lock)\n spin_unlock(&old_wb->list_lock)\n wb_put_many(old_wb, nr_switched)\n cgwb_release\n old wb released\n wb_wakeup_delayed() accesses wb,\n then trigger the use-after-free\n issue\n\nFix this race condition by holding inode spinlock until\nwb_wakeup_delayed() finished.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings()\n\nDefine ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure\npage tables are properly synchronized when calling p*d_populate_kernel().\n\nFor 5-level paging, synchronization is performed via\npgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so\nsynchronization is instead performed at the P4D level via\np4d_populate_kernel().\n\nThis fixes intermittent boot failures on systems using 4-level paging and\na large amount of persistent memory:\n\n BUG: unable to handle page fault for address: ffffe70000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0\n Oops: 0002 [#1] SMP NOPTI\n RIP: 0010:__init_single_page+0x9/0x6d\n Call Trace:\n \n __init_zone_device_page+0x17/0x5d\n memmap_init_zone_device+0x154/0x1bb\n pagemap_range+0x2e0/0x40f\n memremap_pages+0x10b/0x2f0\n devm_memremap_pages+0x1e/0x60\n dev_dax_probe+0xce/0x2ec [device_dax]\n dax_bus_probe+0x6d/0xc9\n [... snip ...]\n \n\nIt also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap\nbefore sync_global_pgds() [1]:\n\n BUG: unable to handle page fault for address: ffffeb3ff1200000\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI\n Tainted: [W]=WARN\n RIP: 0010:vmemmap_set_pmd+0xff/0x230\n \n vmemmap_populate_hugepages+0x176/0x180\n vmemmap_populate+0x34/0x80\n __populate_section_memmap+0x41/0x90\n sparse_add_section+0x121/0x3e0\n __add_pages+0xba/0x150\n add_pages+0x1d/0x70\n memremap_pages+0x3dc/0x810\n devm_memremap_pages+0x1c/0x60\n xe_devm_add+0x8b/0x100 [xe]\n xe_tile_init_noalloc+0x6a/0x70 [xe]\n xe_device_probe+0x48c/0x740 [xe]\n [... snip ...]

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: prevent NULL pointer dereference in UTF16 conversion\n\nThere can be a NULL pointer dereference bug here. NULL is passed to\n__cifs_sfu_make_node without checks, which passes it unchecked to\ncifs_strndup_to_utf16, which in turn passes it to\ncifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.\n\nThis patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and\nreturns NULL early to prevent dereferencing NULL pointer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: don't reset unchangable mount option in f2fs_remount()\n\nsyzbot reports a bug as below:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN\nRIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942\nCall Trace:\n lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691\n __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline]\n _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300\n __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100\n f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116\n f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664\n f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838\n vfs_fallocate+0x54b/0x6b0 fs/open.c:324\n ksys_fallocate fs/open.c:347 [inline]\n __do_sys_fallocate fs/open.c:355 [inline]\n __se_sys_fallocate fs/open.c:353 [inline]\n __x64_sys_fallocate+0xbd/0x100 fs/open.c:353\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe root cause is race condition as below:\n- since it tries to remount rw filesystem, so that do_remount won't\ncall sb_prepare_remount_readonly to block fallocate, there may be race\ncondition in between remount and fallocate.\n- in f2fs_remount(), default_options() will reset mount option to default\none, and then update it based on result of parse_options(), so there is\na hole which race condition can happen.\n\nThread A Thread B\n- f2fs_fill_super\n - parse_options\n - clear_opt(READ_EXTENT_CACHE)\n\n- f2fs_remount\n - default_options\n - set_opt(READ_EXTENT_CACHE)\n - f2fs_fallocate\n - f2fs_insert_range\n - f2fs_drop_extent_tree\n - __drop_extent_tree\n - __may_extent_tree\n - test_opt(READ_EXTENT_CACHE) return true\n - write_lock(&et->lock) access NULL pointer\n - parse_options\n - clear_opt(READ_EXTENT_CACHE)

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free\n\nStruct pcie_link_state->downstream is a pointer to the pci_dev of function\n0. Previously we retained that pointer when removing function 0, and\nsubsequent ASPM policy changes dereferenced it, resulting in a\nuse-after-free warning from KASAN, e.g.:\n\n # echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove\n # echo powersave > /sys/module/pcie_aspm/parameters/policy\n\n BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500\n Call Trace:\n kasan_report+0xae/0xe0\n pcie_config_aspm_link+0x42d/0x500\n pcie_aspm_set_policy+0x8e/0x1a0\n param_attr_store+0x162/0x2c0\n module_attr_store+0x3e/0x80\n\nPCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM\nControl value in all functions of multi-function devices.\n\nDisable ASPM and free the pcie_link_state when any child function is\nremoved so we can discard the dangling pcie_link_state->downstream pointer\nand maintain the same ASPM Control configuration for all functions.\n\n[bhelgaas: commit log and comment]

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: qrtr: Fix a refcount bug in qrtr_recvmsg()\n\nSyzbot reported a bug as following:\n\nrefcount_t: addition on 0; use-after-free.\n...\nRIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25\n...\nCall Trace:\n \n __refcount_add include/linux/refcount.h:199 [inline]\n __refcount_inc include/linux/refcount.h:250 [inline]\n refcount_inc include/linux/refcount.h:267 [inline]\n kref_get include/linux/kref.h:45 [inline]\n qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline]\n qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline]\n qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline]\n qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070\n sock_recvmsg_nosec net/socket.c:1017 [inline]\n sock_recvmsg+0xe2/0x160 net/socket.c:1038\n qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688\n process_one_work+0x991/0x15c0 kernel/workqueue.c:2390\n worker_thread+0x669/0x1090 kernel/workqueue.c:2537\n\nIt occurs in the concurrent scenario of qrtr_recvmsg() and\nqrtr_endpoint_unregister() as following:\n\n\tcpu0\t\t\t\t\tcpu1\nqrtr_recvmsg\t\t\t\tqrtr_endpoint_unregister\nqrtr_send_resume_tx\t\t\tqrtr_node_release\nqrtr_node_lookup\t\t\tmutex_lock(&qrtr_node_lock)\nspin_lock_irqsave(&qrtr_nodes_lock, )\trefcount_dec_and_test(&node->ref) [node->ref == 0]\nradix_tree_lookup [node != NULL]\t__qrtr_node_release\nqrtr_node_acquire\t\t\tspin_lock_irqsave(&qrtr_nodes_lock, )\nkref_get(&node->ref) [WARNING]\t\t...\n\t\t\t\t\tmutex_unlock(&qrtr_node_lock)\n\nUse qrtr_node_lock to protect qrtr_node_lookup() implementation, this\nis actually improving the protection of node reference.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: fix bulk_move corruption when adding a entry\n\nWhen the resource is the first in the bulk_move range, adding it again\n(thus moving it to the tail) will corrupt the list since the first\npointer is not moved. This eventually lead to null pointer deref in\nttm_lru_bulk_move_del()

In the Linux kernel, the following vulnerability has been resolved:\n\nmfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak\n\nIn arizona_clk32k_enable(), we should use pm_runtime_resume_and_get()\nas pm_runtime_get_sync() will increase the refcnt even when it\nreturns an error.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: Block switchdev mode when ADQ is active and vice versa\n\nADQ and switchdev are not supported simultaneously. Enabling both at the\nsame time can result in nullptr dereference.\n\nTo prevent this, check if ADQ is active when changing devlink mode to\nswitchdev mode, and check if switchdev is active when enabling ADQ.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: cpumap: Fix memory leak in cpu_map_update_elem\n\nSyzkaller reported a memory leak as follows:\n\nBUG: memory leak\nunreferenced object 0xff110001198ef748 (size 192):\n comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)\n hex dump (first 32 bytes):\n 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J...........\n 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(.......\n backtrace:\n [] __cpu_map_entry_alloc+0xf7/0xb00\n [] cpu_map_update_elem+0x2fe/0x3d0\n [] bpf_map_update_value.isra.0+0x2bd/0x520\n [] map_update_elem+0x4cb/0x720\n [] __se_sys_bpf+0x8c3/0xb90\n [] do_syscall_64+0x30/0x40\n [] entry_SYSCALL_64_after_hwframe+0x61/0xc6\n\nBUG: memory leak\nunreferenced object 0xff110001198ef528 (size 192):\n comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [] __cpu_map_entry_alloc+0x260/0xb00\n [] cpu_map_update_elem+0x2fe/0x3d0\n [] bpf_map_update_value.isra.0+0x2bd/0x520\n [] map_update_elem+0x4cb/0x720\n [] __se_sys_bpf+0x8c3/0xb90\n [] do_syscall_64+0x30/0x40\n [] entry_SYSCALL_64_after_hwframe+0x61/0xc6\n\nBUG: memory leak\nunreferenced object 0xff1100010fd93d68 (size 8):\n comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)\n hex dump (first 8 bytes):\n 00 00 00 00 00 00 00 00 ........\n backtrace:\n [] kvmalloc_node+0x11e/0x170\n [] __cpu_map_entry_alloc+0x2f0/0xb00\n [] cpu_map_update_elem+0x2fe/0x3d0\n [] bpf_map_update_value.isra.0+0x2bd/0x520\n [] map_update_elem+0x4cb/0x720\n [] __se_sys_bpf+0x8c3/0xb90\n [] do_syscall_64+0x30/0x40\n [] entry_SYSCALL_64_after_hwframe+0x61/0xc6\n\nIn the cpu_map_update_elem flow, when kthread_stop is called before\ncalling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bit\nof kthread has been set by kthread_stop, the threadfn of rcpu->kthread\nwill never be executed, and rcpu->refcnt will never be 0, which will\nlead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot be\nreleased.\n\nCalling kthread_stop before executing kthread's threadfn will return\n-EINTR. We can complete the release of memory resources in this state.

In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix sysfs interface lifetime\n\nThe current nilfs2 sysfs support has issues with the timing of creation\nand deletion of sysfs entries, potentially leading to null pointer\ndereferences, use-after-free, and lockdep warnings.\n\nSome of the sysfs attributes for nilfs2 per-filesystem instance refer to\nmetadata file "cpfile", "sufile", or "dat", but\nnilfs_sysfs_create_device_group that creates those attributes is executed\nbefore the inodes for these metadata files are loaded, and\nnilfs_sysfs_delete_device_group which deletes these sysfs entries is\ncalled after releasing their metadata file inodes.\n\nTherefore, access to some of these sysfs attributes may occur outside of\nthe lifetime of these metadata files, resulting in inode NULL pointer\ndereferences or use-after-free.\n\nIn addition, the call to nilfs_sysfs_create_device_group() is made during\nthe locking period of the semaphore "ns_sem" of nilfs object, so the\nshrinker call caused by the memory allocation for the sysfs entries, may\nderive lock dependencies "ns_sem" -> (shrinker) -> "locks acquired in\nnilfs_evict_inode()".\n\nSince nilfs2 may acquire "ns_sem" deep in the call stack holding other\nlocks via its error handler __nilfs_error(), this causes lockdep to report\ncircular locking. This is a false positive and no circular locking\nactually occurs as no inodes exist yet when\nnilfs_sysfs_create_device_group() is called. Fortunately, the lockdep\nwarnings can be resolved by simply moving the call to\nnilfs_sysfs_create_device_group() out of "ns_sem".\n\nThis fixes these sysfs issues by revising where the device's sysfs\ninterface is created/deleted and keeping its lifetime within the lifetime\nof the metadata files above.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Handle cameras with invalid descriptors\n\nIf the source entity does not contain any pads, do not create a link.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: snic: Fix possible memory leak if device_add() fails\n\nIf device_add() returns error, the name allocated by dev_set_name() needs\nbe freed. As the comment of device_add() says, put_device() should be used\nto give up the reference in the error path. So fix this by calling\nput_device(), then the name can be freed in kobject_cleanp().

In the Linux kernel, the following vulnerability has been resolved:\n\ncassini: Fix a memory leak in the error handling path of cas_init_one()\n\ncas_saturn_firmware_init() allocates some memory using vmalloc(). This\nmemory is freed in the .remove() function but not it the error handling\npath of the probe.\n\nAdd the missing vfree() to avoid a memory leak, should an error occur.

In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores\n\nThe IRAM is part of the HiFi DSP.\nAccording to hardware specification only 32-bits write are allowed\notherwise we get a Kernel panic.\n\nTherefore add a custom memory copy and memset functions to deal with\nthe above restriction.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: add vlan_get_protocol_and_depth() helper\n\nBefore blamed commit, pskb_may_pull() was used instead\nof skb_header_pointer() in __vlan_get_protocol() and friends.\n\nFew callers depended on skb->head being populated with MAC header,\nsyzbot caught one of them (skb_mac_gso_segment())\n\nAdd vlan_get_protocol_and_depth() to make the intent clearer\nand use it where sensible.\n\nThis is a more generic fix than commit e9d3f80935b6\n("net/af_packet: make sure to pull mac header") which was\ndealing with a similar issue.\n\nkernel BUG at include/linux/skbuff.h:2655 !\ninvalid opcode: 0000 [#1] SMP KASAN\nCPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023\nRIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]\nRIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136\nCode: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41\nRSP: 0018:ffffc90001bd7520 EFLAGS: 00010286\nRAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9\nR10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012\nR13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7\nFS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\n[] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419\n[] skb_gso_segment include/linux/netdevice.h:4819 [inline]\n[] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725\n[] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313\n[] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029\n[] packet_snd net/packet/af_packet.c:3111 [inline]\n[] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142\n[] sock_sendmsg_nosec net/socket.c:716 [inline]\n[] sock_sendmsg net/socket.c:736 [inline]\n[] __sys_sendto+0x472/0x5f0 net/socket.c:2139\n[] __do_sys_sendto net/socket.c:2151 [inline]\n[] __se_sys_sendto net/socket.c:2147 [inline]\n[] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147\n[] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n[] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80\n[] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\nfirewire: net: fix use after free in fwnet_finish_incoming_packet()\n\nThe netif_rx() function frees the skb so we can't dereference it to\nsave the skb->len.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Don't attach if enclosure has no components\n\nAn enclosure with no components can't usefully be operated by the driver\n(since effectively it has nothing to manage), so report the problem and\ndon't attach. Not attaching also fixes an oops which could occur if the\ndriver tries to manage a zero component enclosure.\n\n[mkp: Switched to KERN_WARNING since this scenario is common]

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: dma: fix memory leak running mt76_dma_tx_cleanup\n\nFix device unregister memory leak and alway cleanup all configured\nrx queues in mt76_dma_tx_cleanup routine.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don't check PageError in __extent_writepage\n\n__extent_writepage currenly sets PageError whenever any error happens,\nand the also checks for PageError to decide if to call error handling.\nThis leads to very unclear responsibility for cleaning up on errors.\nIn the VM and generic writeback helpers the basic idea is that once\nI/O is fired off all error handling responsibility is delegated to the\nend I/O handler. But if that end I/O handler sets the PageError bit,\nand the submitter checks it, the bit could in some cases leak into the\nsubmission context for fast enough I/O.\n\nFix this by simply not checking PageError and just using the local\nret variable to check for submission errors. This also fundamentally\nsolves the long problem documented in a comment in __extent_writepage\nby never leaking the error bit into the submission context.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix warning and UAF when destroy the MR list\n\nIf the MR allocate failed, the MR recovery work not initialized\nand list not cleared. Then will be warning and UAF when release\nthe MR:\n\n WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110\n CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82\n RIP: 0010:__flush_work.isra.0+0xf7/0x110\n Call Trace:\n \n __cancel_work_timer+0x2ba/0x2e0\n smbd_destroy+0x4e1/0x990\n _smbd_get_connection+0x1cbd/0x2110\n smbd_get_connection+0x21/0x40\n cifs_get_tcp_session+0x8ef/0xda0\n mount_get_conns+0x60/0x750\n cifs_mount+0x103/0xd00\n cifs_smb3_do_mount+0x1dd/0xcb0\n smb3_get_tree+0x1d5/0x300\n vfs_get_tree+0x41/0xf0\n path_mount+0x9b3/0xdd0\n __x64_sys_mount+0x190/0x1d0\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990\n Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824\n CPU: 4 PID: 824 Comm: mount.cifs Tainted: G W 6.1.0-rc5+ #82\n Call Trace:\n dump_stack_lvl+0x34/0x44\n print_report+0x171/0x472\n kasan_report+0xad/0x130\n smbd_destroy+0x4fc/0x990\n _smbd_get_connection+0x1cbd/0x2110\n smbd_get_connection+0x21/0x40\n cifs_get_tcp_session+0x8ef/0xda0\n mount_get_conns+0x60/0x750\n cifs_mount+0x103/0xd00\n cifs_smb3_do_mount+0x1dd/0xcb0\n smb3_get_tree+0x1d5/0x300\n vfs_get_tree+0x41/0xf0\n path_mount+0x9b3/0xdd0\n __x64_sys_mount+0x190/0x1d0\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n Allocated by task 824:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n __kasan_kmalloc+0x7a/0x90\n _smbd_get_connection+0x1b6f/0x2110\n smbd_get_connection+0x21/0x40\n cifs_get_tcp_session+0x8ef/0xda0\n mount_get_conns+0x60/0x750\n cifs_mount+0x103/0xd00\n cifs_smb3_do_mount+0x1dd/0xcb0\n smb3_get_tree+0x1d5/0x300\n vfs_get_tree+0x41/0xf0\n path_mount+0x9b3/0xdd0\n __x64_sys_mount+0x190/0x1d0\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n Freed by task 824:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n kasan_save_free_info+0x2a/0x40\n ____kasan_slab_free+0x143/0x1b0\n __kmem_cache_free+0xc8/0x330\n _smbd_get_connection+0x1c6a/0x2110\n smbd_get_connection+0x21/0x40\n cifs_get_tcp_session+0x8ef/0xda0\n mount_get_conns+0x60/0x750\n cifs_mount+0x103/0xd00\n cifs_smb3_do_mount+0x1dd/0xcb0\n smb3_get_tree+0x1d5/0x300\n vfs_get_tree+0x41/0xf0\n path_mount+0x9b3/0xdd0\n __x64_sys_mount+0x190/0x1d0\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nLet's initialize the MR recovery work before MR allocate to prevent\nthe warning, remove the MRs from the list to prevent the UAF.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: platform: mediatek: vpu: fix NULL ptr dereference\n\nIf pdev is NULL, then it is still dereferenced.\n\nThis fixes this smatch warning:\n\ndrivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev'

In the Linux kernel, the following vulnerability has been resolved:\n\nobjtool: Fix memory leak in create_static_call_sections()\n\nstrdup() allocates memory for key_name. We need to release the memory in\nthe following error paths. Add free() to avoid memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: fw: fix memory leak in debugfs\n\nFix a memory leak that occurs when reading the fw_info\nfile all the way, since we return NULL indicating no\nmore data, but don't free the status tracking object.

In the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()\n\nWhen blkg_alloc() is called to allocate a blkcg_gq structure\nwith the associated blkg_iostat_set's, there are 2 fields within\nblkg_iostat_set that requires proper initialization - blkg & sync.\nThe former field was introduced by commit 3b8cc6298724 ("blk-cgroup:\nOptimize blkcg_rstat_flush()") while the later one was introduced by\ncommit f73316482977 ("blk-cgroup: reimplement basic IO stats using\ncgroup rstat").\n\nUnfortunately those fields in the blkg_iostat_set's are not properly\nre-initialized when they are cleared in v1's blkcg_reset_stats(). This\ncan lead to a kernel panic due to NULL pointer access of the blkg\npointer. The missing initialization of sync is less problematic and\ncan be a problem in a debug kernel due to missing lockdep initialization.\n\nFix these problems by re-initializing them after memory clearing.

In the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect rcu_print_task_exp_stall() ->exp_tasks access\n\nFor kernels built with CONFIG_PREEMPT_RCU=y, the following scenario can\nresult in a NULL-pointer dereference:\n\n CPU1 CPU2\nrcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall\n if (special.b.blocked) READ_ONCE(rnp->exp_tasks) != NULL\n raw_spin_lock_rcu_node\n np = rcu_next_node_entry(t, rnp)\n if (&t->rcu_node_entry == rnp->exp_tasks)\n WRITE_ONCE(rnp->exp_tasks, np)\n ....\n raw_spin_unlock_irqrestore_rcu_node\n raw_spin_lock_irqsave_rcu_node\n t = list_entry(rnp->exp_tasks->prev,\n struct task_struct, rcu_node_entry)\n (if rnp->exp_tasks is NULL, this\n will dereference a NULL pointer)\n\nThe problem is that CPU2 accesses the rcu_node structure's->exp_tasks\nfield without holding the rcu_node structure's ->lock and CPU2 did\nnot observe CPU1's change to rcu_node structure's ->exp_tasks in time.\nTherefore, if CPU1 sets rcu_node structure's->exp_tasks pointer to NULL,\nthen CPU2 might dereference that NULL pointer.\n\nThis commit therefore holds the rcu_node structure's ->lock while\naccessing that structure's->exp_tasks field.\n\n[ paulmck: Apply Frederic Weisbecker feedback. ]

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: lpc32xx_udc: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: sl811: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: isp1362: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: dwc3: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.\n\nNote, the root dentry for the debugfs directory for the device needs to\nbe saved so we don't have to keep looking it up, which required a bit\nmore refactoring to properly create and remove it when needed.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: snic: Fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic at\nonce.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: isp116x: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: bcm63xx_udc: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nPM: EM: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: ULPI: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: base: component: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\ntrace/blktrace: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: pxa27x_udc: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: pxa25x_udc: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: gr_udc: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: fotg210: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\ntime/debug: Fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic at\nonce.

In the Linux kernel, the following vulnerability has been resolved:\n\nkernel/printk/index.c: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: kmem: fix a NULL pointer dereference in obj_stock_flush_required()\n\nKCSAN found an issue in obj_stock_flush_required():\nstock->cached_objcg can be reset between the check and dereference:\n\n==================================================================\nBUG: KCSAN: data-race in drain_all_stock / drain_obj_stock\n\nwrite to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0:\n drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306\n refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340\n obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408\n memcg_slab_free_hook mm/slab.h:587 [inline]\n __cache_free mm/slab.c:3373 [inline]\n __do_kmem_cache_free mm/slab.c:3577 [inline]\n kmem_cache_free+0x105/0x280 mm/slab.c:3602\n __d_free fs/dcache.c:298 [inline]\n dentry_free fs/dcache.c:375 [inline]\n __dentry_kill+0x422/0x4a0 fs/dcache.c:621\n dentry_kill+0x8d/0x1e0\n dput+0x118/0x1f0 fs/dcache.c:913\n __fput+0x3bf/0x570 fs/file_table.c:329\n ____fput+0x15/0x20 fs/file_table.c:349\n task_work_run+0x123/0x160 kernel/task_work.c:179\n resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]\n exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171\n exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203\n __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]\n syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296\n do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nread to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1:\n obj_stock_flush_required mm/memcontrol.c:3319 [inline]\n drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361\n try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703\n try_charge mm/memcontrol.c:2837 [inline]\n mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290\n sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025\n sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525\n udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692\n udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817\n sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668\n __sys_setsockopt+0x1c3/0x230 net/socket.c:2271\n __do_sys_setsockopt net/socket.c:2282 [inline]\n __se_sys_setsockopt net/socket.c:2279 [inline]\n __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nvalue changed: 0xffff8881382d52c0 -> 0xffff888138893740\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023\n\nFix it by using READ_ONCE()/WRITE_ONCE() for all accesses to\nstock->cached_objcg.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: Fix Oops by 9.1 surround channel names\n\nget_line_out_pfx() may trigger an Oops by overflowing the static array\nwith more than 8 channels. This was reported for MacBookPro 12,1 with\nCirrus codec.\n\nAs a workaround, extend for the 9.1 channels and also fix the\npotential Oops by unifying the code paths accessing the same array\nwith the proper size check.

In the Linux kernel, the following vulnerability has been resolved:\n\nmlx5: fix possible ptp queue fifo use-after-free\n\nFifo indexes are not checked during pop operations and it leads to\npotential use-after-free when poping from empty queue. Such case was\npossible during re-sync action. WARN_ON_ONCE covers future cases.\n\nThere were out-of-order cqe spotted which lead to drain of the queue and\nuse-after-free because of lack of fifo pointers check. Special check and\ncounter are added to avoid resync operation if SKB could not exist in the\nfifo because of OOO cqe (skb_id must be between consumer and producer\nindex).

In the Linux kernel, the following vulnerability has been resolved:\n\nmodpost: fix off by one in is_executable_section()\n\nThe > comparison should be >= to prevent an out of bounds array\naccess.

In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer\n\nACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5\n\nAccording to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.\n\nWhen ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.\n\n=============================================================\nUBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]'\nCPU: 37 PID: 1678 Comm: cat Not tainted\n6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k\nHW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:\n dump_backtrace+0xe0/0x130\n show_stack+0x20/0x60\n dump_stack_lvl+0x68/0x84\n dump_stack+0x18/0x34\n ubsan_epilogue+0x10/0x50\n __ubsan_handle_out_of_bounds+0x80/0x90\n acpi_ds_exec_end_op+0x1bc/0x6d8\n acpi_ps_parse_loop+0x57c/0x618\n acpi_ps_parse_aml+0x1e0/0x4b4\n acpi_ps_execute_method+0x24c/0x2b8\n acpi_ns_evaluate+0x3a8/0x4bc\n acpi_evaluate_object+0x15c/0x37c\n acpi_evaluate_integer+0x54/0x15c\n show_power+0x8c/0x12c [acpi_power_meter]

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device\n\nCurrently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0),\nthere is a special handling in order to use the correct counters, but,\nport_num is being passed down the stack without any change. Also, some\nfunctions assume that port_num >=1. As a result, the following oops can\noccur.\n\n BUG: unable to handle page fault for address: ffff89510294f1a8\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0\n Oops: 0002 [#1] SMP\n CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:_raw_spin_lock+0xc/0x20\n Call Trace:\n \n mlx5_ib_get_native_port_mdev+0x73/0xe0 [mlx5_ib]\n do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib]\n mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib]\n ib_setup_device_attrs+0xf0/0x290 [ib_core]\n ib_register_device+0x3bb/0x510 [ib_core]\n ? atomic_notifier_chain_register+0x67/0x80\n __mlx5_ib_add+0x2b/0x80 [mlx5_ib]\n mlx5r_probe+0xb8/0x150 [mlx5_ib]\n ? auxiliary_match_id+0x6a/0x90\n auxiliary_bus_probe+0x3c/0x70\n ? driver_sysfs_add+0x6b/0x90\n really_probe+0xcd/0x380\n __driver_probe_device+0x80/0x170\n driver_probe_device+0x1e/0x90\n __device_attach_driver+0x7d/0x100\n ? driver_allows_async_probing+0x60/0x60\n ? driver_allows_async_probing+0x60/0x60\n bus_for_each_drv+0x7b/0xc0\n __device_attach+0xbc/0x200\n bus_probe_device+0x87/0xa0\n device_add+0x404/0x940\n ? dev_set_name+0x53/0x70\n __auxiliary_device_add+0x43/0x60\n add_adev+0x99/0xe0 [mlx5_core]\n mlx5_attach_device+0xc8/0x120 [mlx5_core]\n mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core]\n devlink_reload+0x133/0x250\n devlink_nl_cmd_reload+0x480/0x570\n ? devlink_nl_pre_doit+0x44/0x2b0\n genl_family_rcv_msg_doit.isra.0+0xc2/0x110\n genl_rcv_msg+0x180/0x2b0\n ? devlink_nl_cmd_region_read_dumpit+0x540/0x540\n ? devlink_reload+0x250/0x250\n ? devlink_put+0x50/0x50\n ? genl_family_rcv_msg_doit.isra.0+0x110/0x110\n netlink_rcv_skb+0x54/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x1f6/0x2c0\n netlink_sendmsg+0x237/0x490\n sock_sendmsg+0x33/0x40\n __sys_sendto+0x103/0x160\n ? handle_mm_fault+0x10e/0x290\n ? do_user_addr_fault+0x1c0/0x5f0\n __x64_sys_sendto+0x25/0x30\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nFix it by setting port_num to 1 in order to get device status and remove\nunused variable.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: intel-ish-hid: Fix kernel panic during warm reset\n\nDuring warm reset device->fw_client is set to NULL. If a bus driver is\nregistered after this NULL setting and before new firmware clients are\nenumerated by ISHTP, kernel panic will result in the function\nishtp_cl_bus_match(). This is because of reference to\ndevice->fw_client->props.protocol_name.\n\nISH firmware after getting successfully loaded, sends a warm reset\nnotification to remove all clients from the bus and sets\ndevice->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel\nmodule drivers were loaded right after any of the first ISHTP device was\nregistered, regardless of whether it was a matched or an unmatched\ndevice. This resulted in all drivers getting registered much before the\nwarm reset notification from ISH.\n\nStarting kernel v5.16, this issue got exposed after the change was\nintroduced to load only bus drivers for the respective matching devices.\nIn this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are\nregistered after the warm reset device fw_client NULL setting.\ncros_ec_ishtp driver_register() triggers the callback to\nishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel\npanic in guid_equal() when dereferencing fw_client NULL pointer to get\nprotocol_name.

In the Linux kernel, the following vulnerability has been resolved:\n\nshmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs\n\nAs the ramfs-based tmpfs uses ramfs_init_fs_context() for the\ninit_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb()\nto free it and avoid a memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: base: dd: fix memory leak with using debugfs_lookup()\n\nWhen calling debugfs_lookup() the result must have dput() called on it,\notherwise the memory will leak over time. To make things simpler, just\ncall debugfs_lookup_and_remove() instead which handles all of the logic\nat once.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Clean dangling pointer on bind error path\n\nmtk_drm_bind() can fail, in which case drm_dev_put() is called,\ndestroying the drm_device object. However a pointer to it was still\nbeing held in the private object, and that pointer would be passed along\nto DRM in mtk_drm_sys_prepare() if a suspend were triggered at that\npoint, resulting in a panic. Clean the pointer when destroying the\nobject in the error path to prevent this from happening.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix device management cmd timeout flow\n\nIn the UFS error handling flow, the host will send a device management cmd\n(NOP OUT) to the device for link recovery. If this cmd times out and\nclearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing and\nreturn. hba->dev_cmd.complete struct is not set to NULL.\n\nWhen this happens, if cmd has been completed by device, then we will call\ncomplete() in __ufshcd_transfer_req_compl(). Because the complete struct is\nallocated on the stack, the following crash will occur:\n\n ipanic_die+0x24/0x38 [mrdump]\n die+0x344/0x748\n arm64_notify_die+0x44/0x104\n do_debug_exception+0x104/0x1e0\n el1_dbg+0x38/0x54\n el1_sync_handler+0x40/0x88\n el1_sync+0x8c/0x140\n queued_spin_lock_slowpath+0x2e4/0x3c0\n __ufshcd_transfer_req_compl+0x3b0/0x1164\n ufshcd_trc_handler+0x15c/0x308\n ufshcd_host_reset_and_restore+0x54/0x260\n ufshcd_reset_and_restore+0x28c/0x57c\n ufshcd_err_handler+0xeb8/0x1b6c\n process_one_work+0x288/0x964\n worker_thread+0x4bc/0xc7c\n kthread+0x15c/0x264\n ret_from_fork+0x10/0x30

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix potential use-after-free when clear keys\n\nSimilar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in\nhci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu()\ncall.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mdp3: Fix resource leaks in of_find_device_by_node\n\nUse put_device to release the object get through of_find_device_by_node,\navoiding resource leaks.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: avoid possible NULL skb pointer dereference\n\nIn 'mwifiex_handle_uap_rx_forward()', always check the value\nreturned by 'skb_copy()' to avoid potential NULL pointer\ndereference in 'mwifiex_uap_queue_bridged_pkt()', and drop\noriginal skb in case of copying failure.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4\n\nThe T241 platform suffers from the T241-FABRIC-4 erratum which causes\nunexpected behavior in the GIC when multiple transactions are received\nsimultaneously from different sources. This hardware issue impacts\nNVIDIA server platforms that use more than two T241 chips\ninterconnected. Each chip has support for 320 {E}SPIs.\n\nThis issue occurs when multiple packets from different GICs are\nincorrectly interleaved at the target chip. The erratum text below\nspecifies exactly what can cause multiple transfer packets susceptible\nto interleaving and GIC state corruption. GIC state corruption can\nlead to a range of problems, including kernel panics, and unexpected\nbehavior.\n\n>From the erratum text:\n "In some cases, inter-socket AXI4 Stream packets with multiple\n transfers, may be interleaved by the fabric when presented to ARM\n Generic Interrupt Controller. GIC expects all transfers of a packet\n to be delivered without any interleaving.\n\n The following GICv3 commands may result in multiple transfer packets\n over inter-socket AXI4 Stream interface:\n - Register reads from GICD_I* and GICD_N*\n - Register writes to 64-bit GICD registers other than GICD_IROUTERn*\n - ITS command MOVALL\n\n Multiple commands in GICv4+ utilize multiple transfer packets,\n including VMOVP, VMOVI, VMAPP, and 64-bit register accesses."\n\n This issue impacts system configurations with more than 2 sockets,\n that require multi-transfer packets to be sent over inter-socket\n AXI4 Stream interface between GIC instances on different sockets.\n GICv4 cannot be supported. GICv3 SW model can only be supported\n with the workaround. Single and Dual socket configurations are not\n impacted by this issue and support GICv3 and GICv4."\n\n\nWriting to the chip alias region of the GICD_In{E} registers except\nGICD_ICENABLERn has an equivalent effect as writing to the global\ndistributor. The SPI interrupt deactivate path is not impacted by\nthe erratum.\n\nTo fix this problem, implement a workaround that ensures read accesses\nto the GICD_In{E} registers are directed to the chip that owns the\nSPI, and disable GICv4.x features. To simplify code changes, the\ngic_configure_irq() function uses the same alias region for both read\nand write operations to GICD_ICFGR.

In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix null-ptr-deref of mreplace in raid10_sync_request\n\nThere are two check of 'mreplace' in raid10_sync_request(). In the first\ncheck, 'need_replace' will be set and 'mreplace' will be used later if\nno-Faulty 'mreplace' exists, In the second check, 'mreplace' will be\nset to NULL if it is Faulty, but 'need_replace' will not be changed\naccordingly. null-ptr-deref occurs if Faulty is set between two check.\n\nFix it by merging two checks into one. And replace 'need_replace' with\n'mreplace' because their values are always the same.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe()\n\nSmatch reports:\ndrivers/usb/phy/phy-tahvo.c: tahvo_usb_probe()\nwarn: missing unwind goto?\n\nAfter geting irq, if ret < 0, it will return without error handling to\nfree memory.\nJust add error handling to fix this problem.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/dpt: Treat the DPT BO as a framebuffer\n\nCurrently i915_gem_object_is_framebuffer() doesn't treat the\nBO containing the framebuffer's DPT as a framebuffer itself.\nThis means eg. that the shrinker can evict the DPT BO while\nleaving the actual FB BO bound, when the DPT is allocated\nfrom regular shmem.\n\nThat causes an immediate oops during hibernate as we\ntry to rewrite the PTEs inside the already evicted\nDPT obj.\n\nTODO: presumably this might also be the reason for the\nDPT related display faults under heavy memory pressure,\nbut I'm still not sure how that would happen as the object\nshould be pinned by intel_dpt_pin() while in active use by\nthe display engine...\n\n(cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Use number of bits to manage bitmap sizes\n\nTo allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using\nbyte as unit. However, bitmap helper functions assume that bitmaps are\nallocated using unsigned long as unit. This gap causes memory access beyond\nthe bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUG\nwas observed at firmware download to eHBA-9600. Call trace indicated that\nthe out-of-bounds access happened in find_first_zero_bit() called from\nmpi3mr_send_event_ack() for miroc->evtack_cmds_bitmap.\n\nTo fix the BUG, do not use bytes to manage bitmap sizes. Instead, use\nnumber of bits, and call bitmap helper functions which take number of bits\nas arguments. For memory allocation, call bitmap_zalloc() instead of\nkzalloc() and krealloc(). For memory free, call bitmap_free() instead of\nkfree(). For zero clear, call bitmap_clear() instead of memset().\n\nRemove three fields for bitmap byte sizes in struct scmd_priv which are no\nlonger required. Replace the field dev_handle_bitmap_sz with\ndev_handle_bitmap_bits to keep number of bits of removepend_bitmap across\nresize.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Free error logs of tracing instances\n\nWhen a tracing instance is removed, the error messages that hold errors\nthat occurred in the instance needs to be freed. The following reports a\nmemory leak:\n\n # cd /sys/kernel/tracing\n # mkdir instances/foo\n # echo 'hist:keys=x' > instances/foo/events/sched/sched_switch/trigger\n # cat instances/foo/error_log\n [ 117.404795] hist:sched:sched_switch: error: Couldn't find field\n Command: hist:keys=x\n ^\n # rmdir instances/foo\n\nThen check for memory leaks:\n\n # echo scan > /sys/kernel/debug/kmemleak\n # cat /sys/kernel/debug/kmemleak\nunreferenced object 0xffff88810d8ec700 (size 192):\n comm "bash", pid 869, jiffies 4294950577 (age 215.752s)\n hex dump (first 32 bytes):\n 60 dd 68 61 81 88 ff ff 60 dd 68 61 81 88 ff ff `.ha....`.ha....\n a0 30 8c 83 ff ff ff ff 26 00 0a 00 00 00 00 00 .0......&.......\n backtrace:\n [<00000000dae26536>] kmalloc_trace+0x2a/0xa0\n [<00000000b2938940>] tracing_log_err+0x277/0x2e0\n [<000000004a0e1b07>] parse_atom+0x966/0xb40\n [<0000000023b24337>] parse_expr+0x5f3/0xdb0\n [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560\n [<00000000293a9645>] trigger_process_regex+0x135/0x1a0\n [<000000005c22b4f2>] event_trigger_write+0x87/0xf0\n [<000000002cadc509>] vfs_write+0x162/0x670\n [<0000000059c3b9be>] ksys_write+0xca/0x170\n [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0\n [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc\nunreferenced object 0xffff888170c35a00 (size 32):\n comm "bash", pid 869, jiffies 4294950577 (age 215.752s)\n hex dump (first 32 bytes):\n 0a 20 20 43 6f 6d 6d 61 6e 64 3a 20 68 69 73 74 . Command: hist\n 3a 6b 65 79 73 3d 78 0a 00 00 00 00 00 00 00 00 :keys=x.........\n backtrace:\n [<000000006a747de5>] __kmalloc+0x4d/0x160\n [<000000000039df5f>] tracing_log_err+0x29b/0x2e0\n [<000000004a0e1b07>] parse_atom+0x966/0xb40\n [<0000000023b24337>] parse_expr+0x5f3/0xdb0\n [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560\n [<00000000293a9645>] trigger_process_regex+0x135/0x1a0\n [<000000005c22b4f2>] event_trigger_write+0x87/0xf0\n [<000000002cadc509>] vfs_write+0x162/0x670\n [<0000000059c3b9be>] ksys_write+0xca/0x170\n [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0\n [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nThe problem is that the error log needs to be freed when the instance is\nremoved.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: seqiv - Handle EBUSY correctly\n\nAs it is seqiv only handles the special return value of EINPROGERSS,\nwhich means that in all other cases it will free data related to the\nrequest.\n\nHowever, as the caller of seqiv may specify MAY_BACKLOG, we also need\nto expect EBUSY and treat it in the same way. Otherwise backlogged\nrequests will trigger a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix a potential overflow in sctp_ifwdtsn_skip\n\nCurrently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only\nchecks the pos against the end of the chunk. However, the data left for\nthe last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereference\nit as struct sctp_ifwdtsn_skip may cause coverflow.\n\nThis patch fixes it by checking the pos against "the end of the chunk -\nsizeof(struct sctp_ifwdtsn_skip)" in sctp_ifwdtsn_skip, similar to\nsctp_fwdtsn_skip.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create\n\nThe memory pointed to by the fs->any pointer is not freed in the error\npath of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.\nFix by freeing the memory in the error path, thereby making the error path\nidentical to mlx5e_fs_tt_redirect_any_destroy().

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix memory leak in mes self test\n\nThe fences associated with mes queue have to be freed\nup during amdgpu_ring_fini.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dcb: choose correct policy to parse DCB_ATTR_BCN\n\nThe dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],\nwhich is introduced in commit 859ee3c43812 ("DCB: Add support for DCB\nBCN"). Please see the comment in below code\n\nstatic int dcbnl_bcn_setcfg(...)\n{\n ...\n ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. )\n // !!! dcbnl_pfc_up_nest for attributes\n // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs\n ...\n for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) {\n // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs\n ...\n value_byte = nla_get_u8(data[i]);\n ...\n }\n ...\n for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) {\n // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs\n ...\n value_int = nla_get_u32(data[i]);\n ...\n }\n ...\n}\n\nThat is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nest\nattributes to parse nlattr defined in dcbnl_pfc_up_attrs. But the\nfollowing access code fetch each nlattr as dcbnl_bcn_attrs attributes.\nBy looking up the associated nla_policy for dcbnl_bcn_attrs. We can find\nthe beginning part of these two policies are "same".\n\nstatic const struct nla_policy dcbnl_pfc_up_nest[...] = {\n [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},\n};\n\nstatic const struct nla_policy dcbnl_bcn_nest[...] = {\n [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG},\n // from here is somewhat different\n [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32},\n ...\n [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG},\n};\n\nTherefore, the current code is buggy and this\nnla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use\nthe adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.\n\nHence use the correct policy dcbnl_bcn_nest to parse the nested\ntb[DCB_ATTR_BCN] TLV.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: check null pointer before accessing when swapping\n\nAdd a check to avoid null pointer dereference as below:\n\n[ 90.002283] general protection fault, probably for non-canonical\naddress 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI\n[ 90.002292] KASAN: null-ptr-deref in range\n[0x0000000000000000-0x0000000000000007]\n[ 90.002346] ? exc_general_protection+0x159/0x240\n[ 90.002352] ? asm_exc_general_protection+0x26/0x30\n[ 90.002357] ? ttm_bo_evict_swapout_allowable+0x322/0x5e0 [ttm]\n[ 90.002365] ? ttm_bo_evict_swapout_allowable+0x42e/0x5e0 [ttm]\n[ 90.002373] ttm_bo_swapout+0x134/0x7f0 [ttm]\n[ 90.002383] ? __pfx_ttm_bo_swapout+0x10/0x10 [ttm]\n[ 90.002391] ? lock_acquire+0x44d/0x4f0\n[ 90.002398] ? ttm_device_swapout+0xa5/0x260 [ttm]\n[ 90.002412] ? lock_acquired+0x355/0xa00\n[ 90.002416] ? do_raw_spin_trylock+0xb6/0x190\n[ 90.002421] ? __pfx_lock_acquired+0x10/0x10\n[ 90.002426] ? ttm_global_swapout+0x25/0x210 [ttm]\n[ 90.002442] ttm_device_swapout+0x198/0x260 [ttm]\n[ 90.002456] ? __pfx_ttm_device_swapout+0x10/0x10 [ttm]\n[ 90.002472] ttm_global_swapout+0x75/0x210 [ttm]\n[ 90.002486] ttm_tt_populate+0x187/0x3f0 [ttm]\n[ 90.002501] ttm_bo_handle_move_mem+0x437/0x590 [ttm]\n[ 90.002517] ttm_bo_validate+0x275/0x430 [ttm]\n[ 90.002530] ? __pfx_ttm_bo_validate+0x10/0x10 [ttm]\n[ 90.002544] ? kasan_save_stack+0x33/0x60\n[ 90.002550] ? kasan_set_track+0x25/0x30\n[ 90.002554] ? __kasan_kmalloc+0x8f/0xa0\n[ 90.002558] ? amdgpu_gtt_mgr_new+0x81/0x420 [amdgpu]\n[ 90.003023] ? ttm_resource_alloc+0xf6/0x220 [ttm]\n[ 90.003038] amdgpu_bo_pin_restricted+0x2dd/0x8b0 [amdgpu]\n[ 90.003210] ? __x64_sys_ioctl+0x131/0x1a0\n[ 90.003210] ? do_syscall_64+0x60/0x90

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sysfs: Fix attempting to call device_add multiple times\n\ndevice_add shall not be called multiple times as stated in its\ndocumentation:\n\n 'Do not call this routine or device_register() more than once for\n any device structure'\n\nSyzkaller reports a bug as follows [1]:\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:33!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN\n[...]\nCall Trace:\n \n __list_add include/linux/list.h:69 [inline]\n list_add_tail include/linux/list.h:102 [inline]\n kobj_kset_join lib/kobject.c:164 [inline]\n kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214\n kobject_add_varg lib/kobject.c:358 [inline]\n kobject_add+0x150/0x1c0 lib/kobject.c:410\n device_add+0x368/0x1e90 drivers/base/core.c:3452\n hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53\n hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799\n hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110\n hci_event_func net/bluetooth/hci_event.c:7440 [inline]\n hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495\n hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007\n process_one_work+0x991/0x1610 kernel/workqueue.c:2289\n worker_thread+0x665/0x1080 kernel/workqueue.c:2436\n kthread+0x2e4/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register()\n\nmhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets\nsome error, mhi_ctrl should be freed with mhi_free_controller(). But\nwhen ath11k_mhi_read_addr_from_dt() fails, the function returns without\ncalling mhi_free_controller(), which will lead to a memory leak.\n\nWe can fix it by calling mhi_free_controller() when\nath11k_mhi_read_addr_from_dt() fails.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/panfrost: Fix GEM handle creation ref-counting\n\npanfrost_gem_create_with_handle() previously returned a BO but with the\nonly reference being from the handle, which user space could in theory\nguess and release, causing a use-after-free. Additionally if the call to\npanfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then\na(nother) reference on the BO was dropped.\n\nThe _create_with_handle() is a problematic pattern, so ditch it and\ninstead create the handle in panfrost_ioctl_create_bo(). If the call to\npanfrost_gem_mapping_get() fails then this means that user space has\nindeed gone behind our back and freed the handle. In which case just\nreturn an error code.

In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: led: Fix potential null-ptr-deref in start_task()\n\nstart_task() calls create_singlethread_workqueue() and not checked the\nret value, which may return NULL. And a null-ptr-deref may happen:\n\nstart_task()\n create_singlethread_workqueue() # failed, led_wq is NULL\n queue_delayed_work()\n queue_delayed_work_on()\n __queue_delayed_work() # warning here, but continue\n __queue_work() # access wq->flags, null-ptr-deref\n\nCheck the ret value and return -ENOMEM if it is NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: fcoe: Fix transport not deattached when fcoe_if_init() fails\n\nfcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when\nfcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed\n&fcoe_sw_transport on fcoe_transports list. This causes panic when\nreinserting module.\n\n BUG: unable to handle page fault for address: fffffbfff82e2213\n RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe]\n Call Trace:\n \n do_one_initcall+0xd0/0x4e0\n load_module+0x5eee/0x7210\n ...

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix use-after-free\n\nWe've already freed the assoc_data at this point, so need\nto use another copy of the AP (MLD) address instead.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: bridge: adv7511: unregister cec i2c device after cec adapter\n\ncec_unregister_adapter() assumes that the underlying adapter ops are\ncallable. For example, if the CEC adapter currently has a valid physical\naddress, then the unregistration procedure will invalidate the physical\naddress by setting it to f.f.f.f. Whence the following kernel oops\nobserved after removing the adv7511 module:\n\n Unable to handle kernel execution of user memory at virtual address 0000000000000000\n Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP\n Call trace:\n 0x0\n adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511]\n cec_adap_unconfigure+0x44/0x90 [cec]\n __cec_s_phys_addr.part.0+0x68/0x230 [cec]\n __cec_s_phys_addr+0x40/0x50 [cec]\n cec_unregister_adapter+0xb4/0x118 [cec]\n adv7511_remove+0x60/0x90 [adv7511]\n i2c_device_remove+0x34/0xe0\n device_release_driver_internal+0x114/0x1f0\n driver_detach+0x54/0xe0\n bus_remove_driver+0x60/0xd8\n driver_unregister+0x34/0x60\n i2c_del_driver+0x2c/0x68\n adv7511_exit+0x1c/0x67c [adv7511]\n __arm64_sys_delete_module+0x154/0x288\n invoke_syscall+0x48/0x100\n el0_svc_common.constprop.0+0x48/0xe8\n do_el0_svc+0x28/0x88\n el0_svc+0x1c/0x50\n el0t_64_sync_handler+0xa8/0xb0\n el0t_64_sync+0x15c/0x160\n Code: bad PC value\n ---[ end trace 0000000000000000 ]---\n\nProtect against this scenario by unregistering i2c_cec after\nunregistering the CEC adapter. Duly disable the CEC clock afterwards\ntoo.

In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix error code path in acpi_ds_call_control_method()\n\nA use-after-free in acpi_ps_parse_aml() after a failing invocaion of\nacpi_ds_call_control_method() is reported by KASAN [1] and code\ninspection reveals that next_walk_state pushed to the thread by\nacpi_ds_create_walk_state() is freed on errors, but it is not popped\nfrom the thread beforehand. Thus acpi_ds_get_current_walk_state()\ncalled by acpi_ps_parse_aml() subsequently returns it as the new\nwalk state which is incorrect.\n\nTo address this, make acpi_ds_call_control_method() call\nacpi_ds_pop_walk_state() to pop next_walk_state from the thread before\nreturning an error.

In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Protect against send buffer overflow in NFSv2 READ\n\nSince before the git era, NFSD has conserved the number of pages\nheld by each nfsd thread by combining the RPC receive and send\nbuffers into a single array of pages. This works because there are\nno cases where an operation needs a large RPC Call message and a\nlarge RPC Reply at the same time.\n\nOnce an RPC Call has been received, svc_process() updates\nsvc_rqst::rq_res to describe the part of rq_pages that can be\nused for constructing the Reply. This means that the send buffer\n(rq_res) shrinks when the received RPC record containing the RPC\nCall is large.\n\nA client can force this shrinkage on TCP by sending a correctly-\nformed RPC Call header contained in an RPC record that is\nexcessively large. The full maximum payload size cannot be\nconstructed in that case.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: If sock is dead don't access sock's sk_wq in sk_stream_wait_memory\n\nFixes the below NULL pointer dereference:\n\n [...]\n [ 14.471200] Call Trace:\n [ 14.471562] \n [ 14.471882] lock_acquire+0x245/0x2e0\n [ 14.472416] ? remove_wait_queue+0x12/0x50\n [ 14.473014] ? _raw_spin_lock_irqsave+0x17/0x50\n [ 14.473681] _raw_spin_lock_irqsave+0x3d/0x50\n [ 14.474318] ? remove_wait_queue+0x12/0x50\n [ 14.474907] remove_wait_queue+0x12/0x50\n [ 14.475480] sk_stream_wait_memory+0x20d/0x340\n [ 14.476127] ? do_wait_intr_irq+0x80/0x80\n [ 14.476704] do_tcp_sendpages+0x287/0x600\n [ 14.477283] tcp_bpf_push+0xab/0x260\n [ 14.477817] tcp_bpf_sendmsg_redir+0x297/0x500\n [ 14.478461] ? __local_bh_enable_ip+0x77/0xe0\n [ 14.479096] tcp_bpf_send_verdict+0x105/0x470\n [ 14.479729] tcp_bpf_sendmsg+0x318/0x4f0\n [ 14.480311] sock_sendmsg+0x2d/0x40\n [ 14.480822] ____sys_sendmsg+0x1b4/0x1c0\n [ 14.481390] ? copy_msghdr_from_user+0x62/0x80\n [ 14.482048] ___sys_sendmsg+0x78/0xb0\n [ 14.482580] ? vmf_insert_pfn_prot+0x91/0x150\n [ 14.483215] ? __do_fault+0x2a/0x1a0\n [ 14.483738] ? do_fault+0x15e/0x5d0\n [ 14.484246] ? __handle_mm_fault+0x56b/0x1040\n [ 14.484874] ? lock_is_held_type+0xdf/0x130\n [ 14.485474] ? find_held_lock+0x2d/0x90\n [ 14.486046] ? __sys_sendmsg+0x41/0x70\n [ 14.486587] __sys_sendmsg+0x41/0x70\n [ 14.487105] ? intel_pmu_drain_pebs_core+0x350/0x350\n [ 14.487822] do_syscall_64+0x34/0x80\n [ 14.488345] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n [...]\n\nThe test scenario has the following flow:\n\nthread1 thread2\n----------- ---------------\n tcp_bpf_sendmsg\n tcp_bpf_send_verdict\n tcp_bpf_sendmsg_redir sock_close\n tcp_bpf_push_locked __sock_release\n tcp_bpf_push //inet_release\n do_tcp_sendpages sock->ops->release\n sk_stream_wait_memory // tcp_close\n sk_wait_event sk->sk_prot->close\n release_sock(__sk);\n ***\n lock_sock(sk);\n __tcp_close\n sock_orphan(sk)\n sk->sk_wq = NULL\n release_sock\n ****\n lock_sock(__sk);\n remove_wait_queue(sk_sleep(sk), &wait);\n sk_sleep(sk)\n //NULL pointer dereference\n &rcu_dereference_raw(sk->sk_wq)->wait\n\nWhile waiting for memory in thread1, the socket is released with its wait\nqueue because thread2 has closed it. This caused by tcp_bpf_send_verdict\ndidn't increase the f_count of psock->sk_redir->sk_socket->file in thread1.\n\nWe should check if SOCK_DEAD flag is set on wakeup in sk_stream_wait_memory\nbefore accessing the wait queue.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit()\n\n> ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb);\n\nmay be schedule, and then complete before the line\n\n> ndev->stats.tx_bytes += skb->len;\n\n[ 46.912801] ==================================================================\n[ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]\n[ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328\n[ 46.935991]\n[ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1\n[ 46.947255] Hardware name: [REDACTED]\n[ 46.954568] Call trace:\n[ 46.957037] dump_backtrace+0x0/0x2b8\n[ 46.960719] show_stack+0x24/0x30\n[ 46.964052] dump_stack+0x128/0x194\n[ 46.967557] print_address_description.isra.0+0x64/0x380\n[ 46.972877] __kasan_report+0x1d4/0x240\n[ 46.976723] kasan_report+0xc/0x18\n[ 46.980138] __asan_report_load4_noabort+0x18/0x20\n[ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]\n[ 46.990613] dev_hard_start_xmit+0x1bc/0xda0\n[ 46.994894] sch_direct_xmit+0x198/0xd08\n[ 46.998827] __qdisc_run+0x37c/0x1dc0\n[ 47.002500] __dev_queue_xmit+0x1528/0x21f8\n[ 47.006692] dev_queue_xmit+0x24/0x30\n[ 47.010366] neigh_resolve_output+0x37c/0x678\n[ 47.014734] ip_finish_output2+0x598/0x2458\n[ 47.018927] __ip_finish_output+0x300/0x730\n[ 47.023118] ip_output+0x2e0/0x430\n[ 47.026530] ip_local_out+0x90/0x140\n[ 47.030117] igmpv3_sendpack+0x14c/0x228\n[ 47.034049] igmpv3_send_cr+0x384/0x6b8\n[ 47.037895] igmp_ifc_timer_expire+0x4c/0x118\n[ 47.042262] call_timer_fn+0x1cc/0xbe8\n[ 47.046021] __run_timers+0x4d8/0xb28\n[ 47.049693] run_timer_softirq+0x24/0x40\n[ 47.053626] __do_softirq+0x2c0/0x117c\n[ 47.057387] irq_exit+0x2dc/0x388\n[ 47.060715] __handle_domain_irq+0xb4/0x158\n[ 47.064908] gic_handle_irq+0x58/0xb0\n[ 47.068581] el0_irq_naked+0x50/0x5c\n[ 47.072162]\n[ 47.073665] Allocated by task 328:\n[ 47.077083] save_stack+0x24/0xb0\n[ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0\n[ 47.084776] kasan_slab_alloc+0x14/0x20\n[ 47.088622] kmem_cache_alloc+0x15c/0x468\n[ 47.092643] __alloc_skb+0xa4/0x498\n[ 47.096142] igmpv3_newpack+0x158/0xd78\n[ 47.099987] add_grhead+0x210/0x288\n[ 47.103485] add_grec+0x6b0/0xb70\n[ 47.106811] igmpv3_send_cr+0x2e0/0x6b8\n[ 47.110657] igmp_ifc_timer_expire+0x4c/0x118\n[ 47.115027] call_timer_fn+0x1cc/0xbe8\n[ 47.118785] __run_timers+0x4d8/0xb28\n[ 47.122457] run_timer_softirq+0x24/0x40\n[ 47.126389] __do_softirq+0x2c0/0x117c\n[ 47.130142]\n[ 47.131643] Freed by task 180:\n[ 47.134712] save_stack+0x24/0xb0\n[ 47.138041] __kasan_slab_free+0x108/0x180\n[ 47.142146] kasan_slab_free+0x10/0x18\n[ 47.145904] slab_free_freelist_hook+0xa4/0x1b0\n[ 47.150444] kmem_cache_free+0x8c/0x528\n[ 47.154292] kfree_skbmem+0x94/0x108\n[ 47.157880] consume_skb+0x10c/0x5a8\n[ 47.161466] __dev_kfree_skb_any+0x88/0xa0\n[ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil]\n[ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac]\n[ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac]\n[ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac]\n[ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac]\n[ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac]\n[ 47.197859] process_one_work+0x7fc/0x1a80\n[ 47.201965] worker_thread+0x31c/0xc40\n[ 47.205726] kthread+0x2d8/0x370\n[ 47.208967] ret_from_fork+0x10/0x18\n[ 47.212546]\n[ 47.214051] The buggy address belongs to the object at ffffff803f588280\n[ 47.214051] which belongs to the cache skbuff_head_cache of size 208\n[ 47.227086] The buggy address is located 104 bytes inside of\n[ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350)\n[ 47.238814] The buggy address belongs to the page:\n[ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/qm - increase the memory of local variables\n\nIncrease the buffer to prevent stack overflow by fuzz test. The maximum\nlength of the qos configuration buffer is 256 bytes. Currently, the value\nof the 'val buffer' is only 32 bytes. The sscanf does not check the dest\nmemory length. So the 'val buffer' may stack overflow.

In the Linux kernel, the following vulnerability has been resolved:\n\niomap: iomap: fix memory corruption when recording errors during writeback\n\nEvery now and then I see this crash on arm64:\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000f8\nBuffer I/O error on dev dm-0, logical block 8733687, async page read\nMem abort info:\n ESR = 0x0000000096000006\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x06: level 2 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000006\n CM = 0, WnR = 0\nuser pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000\n[00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000\nInternal error: Oops: 96000006 [#1] PREEMPT SMP\nBuffer I/O error on dev dm-0, logical block 8733688, async page read\nDumping ftrace buffer:\nBuffer I/O error on dev dm-0, logical block 8733689, async page read\n (ftrace buffer empty)\nXFS (dm-0): log I/O error -5\nModules linked in: dm_thin_pool dm_persistent_data\nXFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296).\n dm_bio_prison\nXFS (dm-0): Please unmount the filesystem and rectify the problem(s)\nXFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0\n dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT\npotentially unexpected fatal signal 6.\n nf_reject_ipv6\npotentially unexpected fatal signal 6.\n ipt_REJECT nf_reject_ipv4\nCPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7\n rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables\nHardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021\npstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)\n ip_tables\npc : 000003fd6d7df200\n x_tables\nlr : 000003fd6d7df1ec\n overlay nfsv4\nCPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405\nHardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021\nWorkqueue: writeback wb_workfn\nsp : 000003ffd9522fd0\n (flush-253:0)\npstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--)\npc : errseq_set+0x1c/0x100\nx29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780\nx26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000\nx23: 00000000ffffffff x22: 0000000000000005\nlr : __filemap_set_wb_err+0x24/0xe0\n x21: 0000000000000006\nsp : fffffe000f80f760\nx29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8\nx26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868\nx23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000\nx20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000\n\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000\nx11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288\nx8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000\nx5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8\nx20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001\nx17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668\nx2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8\nCall trace:\n errseq_set+0x1c/0x100\n __filemap_set_wb_err+0x24/0xe0\n iomap_do_writepage+0x5e4/0xd5c\n write_cache_pages+0x208/0x674\n iomap_writepages+0x34/0x60\n xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b]\nx14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180\nx11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288\nx8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee\nx5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020\nx2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000\nCPU: \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tunnel: wait until all sk_user_data reader finish before releasing the sock\n\nThere is a race condition in vxlan that when deleting a vxlan device\nduring receiving packets, there is a possibility that the sock is\nreleased after getting vxlan_sock vs from sk_user_data. Then in\nlater vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got\nNULL pointer dereference. e.g.\n\n #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757\n #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d\n #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48\n #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b\n #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb\n #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542\n #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62\n [exception RIP: vxlan_ecn_decapsulate+0x3b]\n RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246\n RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000\n RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700\n RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae\n R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700\n R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae\n ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan]\n #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507\n #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45\n #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807\n #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951\n #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde\n #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b\n #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139\n #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a\n #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3\n #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca\n #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3\n\nReproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh\n\nFix this by waiting for all sk_user_data reader to finish before\nreleasing the sock.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix undefined behavior in bit shift for ext4_check_flag_values\n\nShifting signed 32-bit value by 31 bits is undefined, so changing\nsignificant bit to unsigned. The UBSAN warning calltrace like below:\n\nUBSAN: shift-out-of-bounds in fs/ext4/ext4.h:591:2\nleft shift of 1 by 31 places cannot be represented in type 'int'\nCall Trace:\n \n dump_stack_lvl+0x7d/0xa5\n dump_stack+0x15/0x1b\n ubsan_epilogue+0xe/0x4e\n __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c\n ext4_init_fs+0x5a/0x277\n do_one_initcall+0x76/0x430\n kernel_init_freeable+0x3b3/0x422\n kernel_init+0x24/0x1e0\n ret_from_fork+0x1f/0x30\n

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/md/md-bitmap: check the return value of md_bitmap_get_counter()\n\nCheck the return value of md_bitmap_get_counter() in case it returns\nNULL pointer, which will result in a null pointer dereference.\n\nv2: update the check to include other dereference

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure\n\nOn error situation `clp->cl_cb_conn.cb_xprt` should not be given\na reference to the xprt otherwise both client cleanup and the\nerror handling path of the caller call to put it. Better to\ndelay handing over the reference to a later branch.\n\n[ 72.530665] refcount_t: underflow; use-after-free.\n[ 72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120\n[ 72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc]\n[ 72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G OE 5.15.82-dan #1\n[ 72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014\n[ 72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd]\n[ 72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120\n[ 72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48\n[ 72.546666] RSP: 0018:ffffb3f841157cf0 EFLAGS: 00010286\n[ 72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX: 0000000000000000\n[ 72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0\n[ 72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff\n[ 72.550209] R10: 0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180\n[ 72.551142] R13: ffff89ac6231d478 R14: ffff89ac40c06180 R15: ffff89ac6231d4b0\n[ 72.552089] FS: 0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000\n[ 72.553175] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 72.553934] CR2: 0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0\n[ 72.554874] Call Trace:\n[ 72.555278] \n[ 72.555614] svc_xprt_put+0xaf/0xe0 [sunrpc]\n[ 72.556276] nfsd4_process_cb_update.isra.11+0xb7/0x410 [nfsd]\n[ 72.557087] ? update_load_avg+0x82/0x610\n[ 72.557652] ? cpuacct_charge+0x60/0x70\n[ 72.558212] ? dequeue_entity+0xdb/0x3e0\n[ 72.558765] ? queued_spin_unlock+0x9/0x20\n[ 72.559358] nfsd4_run_cb_work+0xfc/0x270 [nfsd]\n[ 72.560031] process_one_work+0x1df/0x390\n[ 72.560600] worker_thread+0x37/0x3b0\n[ 72.561644] ? process_one_work+0x390/0x390\n[ 72.562247] kthread+0x12f/0x150\n[ 72.562710] ? set_kthread_struct+0x50/0x50\n[ 72.563309] ret_from_fork+0x22/0x30\n[ 72.563818] \n[ 72.564189] ---[ end trace 031117b1c72ec616 ]---\n[ 72.566019] list_add corruption. next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018).\n[ 72.567647] ------------[ cut here ]------------

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: greybus: audio_helper: remove unused and wrong debugfs usage\n\nIn the greybus audio_helper code, the debugfs file for the dapm has the\npotential to be removed and memory will be leaked. There is also the\nvery real potential for this code to remove ALL debugfs entries from the\nsystem, and it seems like this is what will really happen if this code\never runs. This all is very wrong as the greybus audio driver did not\ncreate this debugfs file, the sound core did and controls the lifespan\nof it.\n\nSo remove all of the debugfs logic from the audio_helper code as there's\nno way it could be correct. If this really is needed, it can come back\nwith a fixup for the incorrect usage of the debugfs_lookup() call which\nis what caused this to be noticed at all.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: atomisp: prevent integer overflow in sh_css_set_black_frame()\n\nThe "height" and "width" values come from the user so the "height * width"\nmultiplication can overflow.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: fix memory leak in tcindex_set_parms\n\nSyzkaller reports a memory leak as follows:\n====================================\nBUG: memory leak\nunreferenced object 0xffff88810c287f00 (size 256):\n comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046\n [] kmalloc include/linux/slab.h:576 [inline]\n [] kmalloc_array include/linux/slab.h:627 [inline]\n [] kcalloc include/linux/slab.h:659 [inline]\n [] tcf_exts_init include/net/pkt_cls.h:250 [inline]\n [] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342\n [] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553\n [] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147\n [] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082\n [] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540\n [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345\n [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921\n [] sock_sendmsg_nosec net/socket.c:714 [inline]\n [] sock_sendmsg+0x56/0x80 net/socket.c:734\n [] ____sys_sendmsg+0x178/0x410 net/socket.c:2482\n [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536\n [] __sys_sendmmsg+0x105/0x330 net/socket.c:2622\n [] __do_sys_sendmmsg net/socket.c:2651 [inline]\n [] __se_sys_sendmmsg net/socket.c:2648 [inline]\n [] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648\n [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n [] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n====================================\n\nKernel uses tcindex_change() to change an existing\nfilter properties.\n\nYet the problem is that, during the process of changing,\nif `old_r` is retrieved from `p->perfect`, then\nkernel uses tcindex_alloc_perfect_hash() to newly\nallocate filter results, uses tcindex_filter_result_init()\nto clear the old filter result, without destroying\nits tcf_exts structure, which triggers the above memory leak.\n\nTo be more specific, there are only two source for the `old_r`,\naccording to the tcindex_lookup(). `old_r` is retrieved from\n`p->perfect`, or `old_r` is retrieved from `p->h`.\n\n * If `old_r` is retrieved from `p->perfect`, kernel uses\ntcindex_alloc_perfect_hash() to newly allocate the\nfilter results. Then `r` is assigned with `cp->perfect + handle`,\nwhich is newly allocated. So condition `old_r && old_r != r` is\ntrue in this situation, and kernel uses tcindex_filter_result_init()\nto clear the old filter result, without destroying\nits tcf_exts structure\n\n * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL\naccording to the tcindex_lookup(). Considering that `cp->h`\nis directly copied from `p->h` and `p->perfect` is NULL,\n`r` is assigned with `tcindex_lookup(cp, handle)`, whose value\nshould be the same as `old_r`, so condition `old_r && old_r != r`\nis false in this situation, kernel ignores using\ntcindex_filter_result_init() to clear the old filter result.\n\nSo only when `old_r` is retrieved from `p->perfect` does kernel use\ntcindex_filter_result_init() to clear the old filter result, which\ntriggers the above memory leak.\n\nConsidering that there already exists a tc_filter_wq workqueue\nto destroy the old tcindex_d\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nintegrity: Fix memory leakage in keyring allocation error path\n\nKey restriction is allocated in integrity_init_keyring(). However, if\nkeyring allocation failed, it is not freed, causing memory leaks.

In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: ismt: Fix an out-of-bounds bug in ismt_access()\n\nWhen the driver does not check the data from the user, the variable\n'data->block[0]' may be very large to cause an out-of-bounds bug.\n\nThe following log can reveal it:\n\n[ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20\n[ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE\n[ 33.996475] ==================================================================\n[ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b\n[ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485\n[ 33.999450] Call Trace:\n[ 34.001849] memcpy+0x20/0x60\n[ 34.002077] ismt_access.cold+0x374/0x214b\n[ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0\n[ 34.004007] i2c_smbus_xfer+0x10a/0x390\n[ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710\n[ 34.005196] i2cdev_ioctl+0x5ec/0x74c\n\nFix this bug by checking the size of 'data->block[0]' first.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: SDMA update use unlocked iterator\n\nSDMA update page table may be called from unlocked context, this\ngenerate below warning. Use unlocked iterator to handle this case.\n\nWARNING: CPU: 0 PID: 1475 at\ndrivers/dma-buf/dma-resv.c:483 dma_resv_iter_next\nCall Trace:\n dma_resv_iter_first+0x43/0xa0\n amdgpu_vm_sdma_update+0x69/0x2d0 [amdgpu]\n amdgpu_vm_ptes_update+0x29c/0x870 [amdgpu]\n amdgpu_vm_update_range+0x2f6/0x6c0 [amdgpu]\n svm_range_unmap_from_gpus+0x115/0x300 [amdgpu]\n svm_range_cpu_invalidate_pagetables+0x510/0x5e0 [amdgpu]\n __mmu_notifier_invalidate_range_start+0x1d3/0x230\n unmap_vmas+0x140/0x150\n unmap_region+0xa8/0x110

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: mt8183: fix refcount leak in mt8183_mt6358_ts3a227_max98357_dev_probe()\n\nThe node returned by of_parse_phandle() with refcount incremented,\nof_node_put() needs be called when finish using it. So add it in the\nerror path in mt8183_mt6358_ts3a227_max98357_dev_probe().

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED\n\nShifting signed 32-bit value by 31 bits is undefined, so changing\nsignificant bit to unsigned. The UBSAN warning calltrace like below:\n\nUBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26\nleft shift of 1 by 31 places cannot be represented in type 'int'\nCall Trace:\n \n dump_stack_lvl+0x7d/0xa5\n dump_stack+0x15/0x1b\n ubsan_epilogue+0xe/0x4e\n __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c\n ttm_bo_move_memcpy+0x3b4/0x460 [ttm]\n bo_driver_move+0x32/0x40 [drm_vram_helper]\n ttm_bo_handle_move_mem+0x118/0x200 [ttm]\n ttm_bo_validate+0xfa/0x220 [ttm]\n drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper]\n drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper]\n drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper]\n drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper]\n drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper]\n drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper]\n drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper]\n drm_atomic_commit+0x9c/0x160 [drm]\n drm_client_modeset_commit_atomic+0x33a/0x380 [drm]\n drm_client_modeset_commit_locked+0x77/0x220 [drm]\n drm_client_modeset_commit+0x31/0x60 [drm]\n __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper]\n drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper]\n fbcon_init+0x316/0x790\n visual_init+0x113/0x1d0\n do_bind_con_driver+0x2a3/0x5c0\n do_take_over_console+0xa9/0x270\n do_fbcon_takeover+0xa1/0x170\n do_fb_registered+0x2a8/0x340\n fbcon_fb_registered+0x47/0xe0\n register_framebuffer+0x294/0x4a0\n __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper]\n drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper]\n drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper]\n drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper]\n bochs_pci_probe+0x6ca/0x772 [bochs]\n local_pci_probe+0x4d/0xb0\n pci_device_probe+0x119/0x320\n really_probe+0x181/0x550\n __driver_probe_device+0xc6/0x220\n driver_probe_device+0x32/0x100\n __driver_attach+0x195/0x200\n bus_for_each_dev+0xbb/0x120\n driver_attach+0x27/0x30\n bus_add_driver+0x22e/0x2f0\n driver_register+0xa9/0x190\n __pci_register_driver+0x90/0xa0\n bochs_pci_driver_init+0x52/0x1000 [bochs]\n do_one_initcall+0x76/0x430\n do_init_module+0x61/0x28a\n load_module+0x1f82/0x2e50\n __do_sys_finit_module+0xf8/0x190\n __x64_sys_finit_module+0x23/0x30\n do_syscall_64+0x58/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n