In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ppp: Add bound checking for skb data on ppp_sync_txmung\n\nEnsure we have enough data in linear buffer from skb before accessing\ninitial bytes. This prevents potential out-of-bounds accesses\nwhen processing short packets.\n\nWhen ppp_sync_txmung receives an incoming package with an empty\npayload:\n(remote) gef➤ p *(struct pppoe_hdr *) (skb->head + skb->network_header)\n$18 = {\n type = 0x1,\n ver = 0x1,\n code = 0x0,\n sid = 0x2,\n length = 0x0,\n tag = 0xffff8880371cdb96\n}\n\nfrom the skb struct (trimmed)\n tail = 0x16,\n end = 0x140,\n head = 0xffff88803346f400 "4",\n data = 0xffff88803346f416 ":\\377",\n truesize = 0x380,\n len = 0x0,\n data_len = 0x0,\n mac_len = 0xe,\n hdr_len = 0x0,\n\nit is not safe to access data[2].\n\n[pabeni@redhat.com: fixed subj typo]

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group\n\nCurrently, mtk_iommu calls during probe iommu_device_register before\nthe hw_list from driver data is initialized. Since iommu probing issue\nfix, it leads to NULL pointer dereference in mtk_iommu_device_group when\nhw_list is accessed with list_first_entry (not null safe).\n\nSo, change the call order to ensure iommu_device_register is called\nafter the driver data are initialized.

In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix hang while freeing sigtrap event\n\nPerf can hang while freeing a sigtrap event if a related deferred\nsignal hadn't managed to be sent before the file got closed:\n\nperf_event_overflow()\n task_work_add(perf_pending_task)\n\nfput()\n task_work_add(____fput())\n\ntask_work_run()\n ____fput()\n perf_release()\n perf_event_release_kernel()\n _free_event()\n perf_pending_task_sync()\n task_work_cancel() -> FAILED\n rcuwait_wait_event()\n\nOnce task_work_run() is running, the list of pending callbacks is\nremoved from the task_struct and from this point on task_work_cancel()\ncan't remove any pending and not yet started work items, hence the\ntask_work_cancel() failure and the hang on rcuwait_wait_event().\n\nTask work could be changed to remove one work at a time, so a work\nrunning on the current task can always cancel a pending one, however\nthe wait / wake design is still subject to inverted dependencies when\nremote targets are involved, as pictured by Oleg:\n\nT1 T2\n\nfd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid);\nclose(fd) close(fd)\n \n perf_event_overflow() perf_event_overflow()\n task_work_add(perf_pending_task) task_work_add(perf_pending_task)\n \n fput() fput()\n task_work_add(____fput()) task_work_add(____fput())\n\n task_work_run() task_work_run()\n ____fput() ____fput()\n perf_release() perf_release()\n perf_event_release_kernel() perf_event_release_kernel()\n _free_event() _free_event()\n perf_pending_task_sync() perf_pending_task_sync()\n rcuwait_wait_event() rcuwait_wait_event()\n\nTherefore the only option left is to acquire the event reference count\nupon queueing the perf task work and release it from the task work, just\nlike it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release")\nbut without the leaks it fixed.\n\nSome adjustments are necessary to make it work:\n\n* A child event might dereference its parent upon freeing. Care must be\n taken to release the parent last.\n\n* Some places assuming the event doesn't have any reference held and\n therefore can be freed right away must instead put the reference and\n let the reference counting to its job.

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/dwc_pcie: fix duplicate pci_dev devices\n\nDuring platform_device_register, wrongly using struct device\npci_dev as platform_data caused a kmemdup copy of pci_dev. Worse\nstill, accessing the duplicated device leads to list corruption as its\nmutex content (e.g., list, magic) remains the same as the original.

In the Linux kernel, the following vulnerability has been resolved:\n\nPM: hibernate: Avoid deadlock in hibernate_compressor_param_set()\n\nsyzbot reported a deadlock in lock_system_sleep() (see below).\n\nThe write operation to "/sys/module/hibernate/parameters/compressor"\nconflicts with the registration of ieee80211 device, resulting in a deadlock\nwhen attempting to acquire system_transition_mutex under param_lock.\n\nTo avoid this deadlock, change hibernate_compressor_param_set() to use\nmutex_trylock() for attempting to acquire system_transition_mutex and\nreturn -EBUSY when it fails.\n\nTask flags need not be saved or adjusted before calling\nmutex_trylock(&system_transition_mutex) because the caller is not going\nto end up waiting for this mutex and if it runs concurrently with system\nsuspend in progress, it will be frozen properly when it returns to user\nspace.\n\nsyzbot report:\n\nsyz-executor895/5833 is trying to acquire lock:\nffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, at: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56\n\nbut task is already holding lock:\nffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: kernel_param_lock kernel/params.c:607 [inline]\nffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: param_attr_store+0xe6/0x300 kernel/params.c:586\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #3 (param_lock){+.+.}-{4:4}:\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730\n ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [inline]\n rate_control_alloc net/mac80211/rate.c:266 [inline]\n ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015\n ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531\n mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558\n init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910\n do_one_initcall+0x128/0x700 init/main.c:1257\n do_initcall_level init/main.c:1319 [inline]\n do_initcalls init/main.c:1335 [inline]\n do_basic_setup init/main.c:1354 [inline]\n kernel_init_freeable+0x5c7/0x900 init/main.c:1568\n kernel_init+0x1c/0x2b0 init/main.c:1457\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n-> #2 (rtnl_mutex){+.+.}-{4:4}:\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730\n wg_pm_notification drivers/net/wireguard/device.c:80 [inline]\n wg_pm_notification+0x49/0x180 drivers/net/wireguard/device.c:64\n notifier_call_chain+0xb7/0x410 kernel/notifier.c:85\n notifier_call_chain_robust kernel/notifier.c:120 [inline]\n blocking_notifier_call_chain_robust kernel/notifier.c:345 [inline]\n blocking_notifier_call_chain_robust+0xc9/0x170 kernel/notifier.c:333\n pm_notifier_call_chain_robust+0x27/0x60 kernel/power/main.c:102\n snapshot_open+0x189/0x2b0 kernel/power/user.c:77\n misc_open+0x35a/0x420 drivers/char/misc.c:179\n chrdev_open+0x237/0x6a0 fs/char_dev.c:414\n do_dentry_open+0x735/0x1c40 fs/open.c:956\n vfs_open+0x82/0x3f0 fs/open.c:1086\n do_open fs/namei.c:3830 [inline]\n path_openat+0x1e88/0x2d80 fs/namei.c:3989\n do_filp_open+0x20c/0x470 fs/namei.c:4016\n do_sys_openat2+0x17a/0x1e0 fs/open.c:1428\n do_sys_open fs/open.c:1443 [inline]\n __do_sys_openat fs/open.c:1459 [inline]\n __se_sys_openat fs/open.c:1454 [inline]\n __x64_sys_openat+0x175/0x210 fs/open.c:1454\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n-> #1 ((pm_chain_head).rwsem){++++}-{4:4}:\n down_read+0x9a/0x330 kernel/locking/rwsem.c:1524\n blocking_notifier_call_chain_robust kerne\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix memory leak in ath12k_pci_remove()\n\nKmemleak reported this error:\n\n unreferenced object 0xffff1c165cec3060 (size 32):\n comm "insmod", pid 560, jiffies 4296964570 (age 235.596s)\n backtrace:\n [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0\n [<000000001203b155>] kmalloc_trace+0x40/0x88\n [<0000000028adc9c8>] _request_firmware+0xb8/0x608\n [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80\n [<000000005011a682>] local_pci_probe+0x48/0xd0\n [<00000000077cd295>] pci_device_probe+0xb4/0x200\n [<0000000087184c94>] really_probe+0x150/0x2c0\n\nThe firmware memory was allocated in ath12k_pci_probe(), but not\nfreed in ath12k_pci_remove() in case ATH12K_FLAG_QMI_FAIL bit is\nset. So call ath12k_fw_unmap() to free the memory.\n\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: Avoid memory leak while enabling statistics\n\nDriver uses monitor destination rings for extended statistics mode and\nstandalone monitor mode. In extended statistics mode, TLVs are parsed from\nthe buffer received from the monitor destination ring and assigned to the\nppdu_info structure to update per-packet statistics. In standalone monitor\nmode, along with per-packet statistics, the packet data (payload) is\ncaptured, and the driver updates per MSDU to mac80211.\n\nWhen the AP interface is enabled, only extended statistics mode is\nactivated. As part of enabling monitor rings for collecting statistics,\nthe driver subscribes to HAL_RX_MPDU_START TLV in the filter\nconfiguration. This TLV is received from the monitor destination ring, and\nkzalloc for the mon_mpdu object occurs, which is not freed, leading to a\nmemory leak. The kzalloc for the mon_mpdu object is only required while\nenabling the standalone monitor interface. This causes a memory leak while\nenabling extended statistics mode in the driver.\n\nFix this memory leak by removing the kzalloc for the mon_mpdu object in\nthe HAL_RX_MPDU_START TLV handling. Additionally, remove the standalone\nmonitor mode handlings in the HAL_MON_BUF_ADDR and HAL_RX_MSDU_END TLVs.\nThese TLV tags will be handled properly when enabling standalone monitor\nmode in the future.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

In the Linux kernel, the following vulnerability has been resolved:\n\njfs: Fix uninit-value access of imap allocated in the diMount() function\n\nsyzbot reports that hex_dump_to_buffer is using uninit-value:\n\n=====================================================\nBUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171\nhex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171\nprint_hex_dump+0x13d/0x3e0 lib/hexdump.c:276\ndiFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876\njfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156\nevict+0x723/0xd10 fs/inode.c:796\niput_final fs/inode.c:1946 [inline]\niput+0x97b/0xdb0 fs/inode.c:1972\ntxUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367\ntxLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]\njfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733\nkthread+0x6b9/0xef0 kernel/kthread.c:464\nret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148\nret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\nslab_post_alloc_hook mm/slub.c:4121 [inline]\nslab_alloc_node mm/slub.c:4164 [inline]\n__kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320\nkmalloc_noprof include/linux/slab.h:901 [inline]\ndiMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105\njfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176\njfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523\nget_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636\nget_tree_bdev+0x37/0x50 fs/super.c:1659\njfs_get_tree+0x34/0x40 fs/jfs/super.c:635\nvfs_get_tree+0xb1/0x5a0 fs/super.c:1814\ndo_new_mount+0x71f/0x15e0 fs/namespace.c:3560\npath_mount+0x742/0x1f10 fs/namespace.c:3887\ndo_mount fs/namespace.c:3900 [inline]\n__do_sys_mount fs/namespace.c:4111 [inline]\n__se_sys_mount+0x71f/0x800 fs/namespace.c:4088\n__x64_sys_mount+0xe4/0x150 fs/namespace.c:4088\nx64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x77/0x7f\n=====================================================\n\nThe reason is that imap is not properly initialized after memory\nallocation. It will cause the snprintf() function to write uninitialized\ndata into linebuf within hex_dump_to_buffer().\n\nFix this by using kzalloc instead of kmalloc to clear its content at the\nbeginning in diMount().

In the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(&(imap->im_aglock[index]));\n lock(&(imap->im_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\njfs: add sanity check for agwidth in dbMount\n\nThe width in dmapctl of the AG is zero, it trigger a divide error when\ncalculating the control page level in dbAllocAG.\n\nTo avoid this issue, add a check for agwidth in dbAllocAG.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/vf: Don't try to trigger a full GT reset if VF\n\nVFs don't have access to the GDRST(0x941c) register that driver\nuses to reset a GT. Attempt to trigger a reset using debugfs:\n\n $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset\n\nor due to a hang condition detected by the driver leads to:\n\n [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe]\n [ ] xe 0000:00:02.1: [drm] GT0: reset queued\n [ ] xe 0000:00:02.1: [drm] GT0: reset started\n [ ] ------------[ cut here ]------------\n [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0\n [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ] Call Trace:\n [ ] \n [ ] ? show_regs+0x6c/0x80\n [ ] ? __warn+0x93/0x1c0\n [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ] ? report_bug+0x182/0x1b0\n [ ] ? handle_bug+0x6e/0xb0\n [ ] ? exc_invalid_op+0x18/0x80\n [ ] ? asm_exc_invalid_op+0x1b/0x20\n [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]\n [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe]\n [ ] ? __mutex_unlock_slowpath+0x41/0x2e0\n [ ] xe_mmio_write32+0x64/0x150 [xe]\n [ ] do_gt_reset+0x2f/0xa0 [xe]\n [ ] gt_reset_worker+0x14e/0x1e0 [xe]\n [ ] process_one_work+0x21c/0x740\n [ ] worker_thread+0x1db/0x3c0\n\nFix that by sending H2G VF_RESET(0x5507) action instead.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type\n\nThe access to the PCI config space via pci_ops::read and pci_ops::write is\na low-level hardware access. The functions can be accessed with disabled\ninterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this\npurpose.\n\nA spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be\nacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in\nthe same context as the pci_lock.\n\nMake vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with\ninterrupts disabled.\n\nThis was reported as:\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n Call Trace:\n rt_spin_lock+0x4e/0x130\n vmd_pci_read+0x8d/0x100 [vmd]\n pci_user_read_config_byte+0x6f/0xe0\n pci_read_config+0xfe/0x290\n sysfs_kf_bin_read+0x68/0x90\n\n[bigeasy: reword commit message]\nTested-off-by: Luis Claudio R. Goncalves \n[kwilczynski: commit log]\n[bhelgaas: add back report info from\nhttps://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add a check to handle OOB in sfr region\n\nsfr->buf_size is in shared memory and can be modified by malicious user.\nOOB write is possible when the size is made higher than actual sfr data\nbuffer. Cap the size to allocated size for such cases.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr->q_size\n\nif (wr_idx >= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx < qsize) {\n memcpy(wr_ptr, packet, dwords << 2) --> OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi_parser: add check to avoid out of bound access\n\nThere is a possibility that init_codecs is invoked multiple times during\nmanipulated payload from video firmware. In such case, if codecs_count\ncan get incremented to value more than MAX_CODEC_NUM, there can be OOB\naccess. Reset the count so that it always starts from beginning.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi_parser: refactor hfi packet parsing logic\n\nwords_count denotes the number of words in total payload, while data\npoints to payload of various property within it. When words_count\nreaches last word, data can access memory beyond the total payload. This\ncan lead to OOB access. With this patch, the utility api for handling\nindividual properties now returns the size of data consumed. Accordingly\nremaining bytes are calculated before parsing the payload, thereby\neliminates the OOB access possibilities.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: Fix accessing freed irq affinity_hint\n\nThe cpumask should not be a local variable, since its pointer is saved\nto irq_desc and may be accessed from procfs.\nTo fix it, use the persistent mask cpumask_of(cpu#).

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/net: fix io_req_post_cqe abuse by send bundle\n\n[ 114.987980][ T5313] WARNING: CPU: 6 PID: 5313 at io_uring/io_uring.c:872 io_req_post_cqe+0x12e/0x4f0\n[ 114.991597][ T5313] RIP: 0010:io_req_post_cqe+0x12e/0x4f0\n[ 115.001880][ T5313] Call Trace:\n[ 115.002222][ T5313] \n[ 115.007813][ T5313] io_send+0x4fe/0x10f0\n[ 115.009317][ T5313] io_issue_sqe+0x1a6/0x1740\n[ 115.012094][ T5313] io_wq_submit_work+0x38b/0xed0\n[ 115.013223][ T5313] io_worker_handle_work+0x62a/0x1600\n[ 115.013876][ T5313] io_wq_worker+0x34f/0xdf0\n\nAs the comment states, io_req_post_cqe() should only be used by\nmultishot requests, i.e. REQ_F_APOLL_MULTISHOT, which bundled sends are\nnot. Add a flag signifying whether a request wants to post multiple\nCQEs. Eventually REQ_F_APOLL_MULTISHOT should imply the new flag, but\nthat's left out for simplicity.

In the Linux kernel, the following vulnerability has been resolved:\n\narm/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch()\n\nFix a silly bug where an array was used outside of its scope.

In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: host: Fix race between unprepare and queue_buf\n\nA client driver may use mhi_unprepare_from_transfer() to quiesce\nincoming data during the client driver's tear down. The client driver\nmight also be processing data at the same time, resulting in a call to\nmhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs\nafter mhi_unprepare_from_transfer() has torn down the channel, a panic\nwill occur due to an invalid dereference leading to a page fault.\n\nThis occurs because mhi_gen_tre() does not verify the channel state\nafter locking it. Fix this by having mhi_gen_tre() confirm the channel\nstate is valid, or return error to avoid accessing deinitialized data.\n\n[mani: added stable tag]

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nCall Trace:\n \n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \n\nThe following loop is located right above 'if' statement.\n\nfor (i = count-1; i >= 0; i--) {\n /* is more than half of this entry in 2nd half of the block? */\n if (size + map[i].size/2 > blocksize/2)\n break;\n size += map[i].size;\n move++;\n}\n\n'i' in this case could go down to -1, in which case sum of active entries\nwouldn't exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: do not start chip while suspended\n\nChecking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can\nlead to a spurious tpm_chip_start() call:\n\n[35985.503771] i2c i2c-1: Transfer while suspended\n[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810\n[35985.503802] Modules linked in:\n[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f\n[35985.503814] Tainted: [W]=WARN\n[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810\n[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5\n[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246\n[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000\n[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001\n[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\n[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820\n[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120\n[35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000\n[35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0\n[35985.503855] Call Trace:\n[35985.503859] \n[35985.503863] ? __warn+0xd4/0x260\n[35985.503868] ? __i2c_transfer+0xbe/0x810\n[35985.503874] ? report_bug+0xf3/0x210\n[35985.503882] ? handle_bug+0x63/0xb0\n[35985.503887] ? exc_invalid_op+0x16/0x50\n[35985.503892] ? asm_exc_invalid_op+0x16/0x20\n[35985.503904] ? __i2c_transfer+0xbe/0x810\n[35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0\n[35985.503920] tpm_cr50_i2c_read+0x8e/0x120\n[35985.503928] tpm_cr50_request_locality+0x75/0x170\n[35985.503935] tpm_chip_start+0x116/0x160\n[35985.503942] tpm_try_get_ops+0x57/0x90\n[35985.503948] tpm_find_get_ops+0x26/0xd0\n[35985.503955] tpm_get_random+0x2d/0x80\n\nDon't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless\nTPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in\nsuch a failure case.

In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()\n\nsoc_dev_attr->revision could be NULL, thus,\na pointer check is added to prevent potential NULL pointer dereference.\nThis is similar to the fix in commit 3027e7b15b02\n("ice: Fix some null pointer dereference issues in ice_ptp.c").\n\nThis issue is found by our static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:\n\ni3c: Add NULL pointer check in i3c_master_queue_ibi()\n\nThe I3C master driver may receive an IBI from a target device that has not\nbeen probed yet. In such cases, the master calls `i3c_master_queue_ibi()`\nto queue an IBI work task, leading to "Unable to handle kernel read from\nunreadable memory" and resulting in a kernel panic.\n\nTypical IBI handling flow:\n1. The I3C master scans target devices and probes their respective drivers.\n2. The target device driver calls `i3c_device_request_ibi()` to enable IBI\n and assigns `dev->ibi = ibi`.\n3. The I3C master receives an IBI from the target device and calls\n `i3c_master_queue_ibi()` to queue the target device driver’s IBI\n handler task.\n\nHowever, since target device events are asynchronous to the I3C probe\nsequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,\nleading to a kernel panic.\n\nAdd a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing\nan uninitialized `dev->ibi`, ensuring stability.

In the Linux kernel, the following vulnerability has been resolved:\n\nmfd: ene-kb3930: Fix a potential NULL pointer dereference\n\nThe off_gpios could be NULL. Add missing check in the kb3930_probe().\nThis is similar to the issue fixed in commit b1ba8bcb2d1f\n("backlight: hx8357: Fix potential NULL pointer dereference").\n\nThis was detected by our static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix NULL pointer in can_accept_new_subflow\n\nWhen testing valkey benchmark tool with MPTCP, the kernel panics in\n'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL.\n\nCall trace:\n\n mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)\n subflow_syn_recv_sock (./net/mptcp/subflow.c:854)\n tcp_check_req (./net/ipv4/tcp_minisocks.c:863)\n tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268)\n ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207)\n ip_local_deliver_finish (./net/ipv4/ip_input.c:234)\n ip_local_deliver (./net/ipv4/ip_input.c:254)\n ip_rcv_finish (./net/ipv4/ip_input.c:449)\n ...\n\nAccording to the debug log, the same req received two SYN-ACK in a very\nshort time, very likely because the client retransmits the syn ack due\nto multiple reasons.\n\nEven if the packets are transmitted with a relevant time interval, they\ncan be processed by the server on different CPUs concurrently). The\n'subflow_req->msk' ownership is transferred to the subflow the first,\nand there will be a risk of a null pointer dereference here.\n\nThis patch fixes this issue by moving the 'subflow_req->msk' under the\n`own_req == true` conditional.\n\nNote that the !msk check in subflow_hmac_valid() can be dropped, because\nthe same check already exists under the own_req mpj branch where the\ncode has been moved to.

In the Linux kernel, the following vulnerability has been resolved:\n\nbacklight: led_bl: Hold led_access lock when calling led_sysfs_disable()\n\nLockdep detects the following issue on led-backlight removal:\n [ 142.315935] ------------[ cut here ]------------\n [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80\n ...\n [ 142.500725] Call trace:\n [ 142.503176] led_sysfs_enable+0x54/0x80 (P)\n [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl]\n [ 142.511742] platform_remove+0x30/0x58\n [ 142.515501] device_remove+0x54/0x90\n ...\n\nIndeed, led_sysfs_enable() has to be called with the led_access\nlock held.\n\nHold the lock when calling led_sysfs_disable().

In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: detect and prevent references to a freed transport in sendmsg\n\nsctp_sendmsg() re-uses associations and transports when possible by\ndoing a lookup based on the socket endpoint and the message destination\naddress, and then sctp_sendmsg_to_asoc() sets the selected transport in\nall the message chunks to be sent.\n\nThere's a possible race condition if another thread triggers the removal\nof that selected transport, for instance, by explicitly unbinding an\naddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have\nbeen set up and before the message is sent. This can happen if the send\nbuffer is full, during the period when the sender thread temporarily\nreleases the socket lock in sctp_wait_for_sndbuf().\n\nThis causes the access to the transport data in\nsctp_outq_select_transport(), when the association outqueue is flushed,\nto result in a use-after-free read.\n\nThis change avoids this scenario by having sctp_transport_free() signal\nthe freeing of the transport, tagging it as "dead". In order to do this,\nthe patch restores the "dead" bit in struct sctp_transport, which was\nremoved in\ncommit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").\n\nThen, in the scenario where the sender thread has released the socket\nlock in sctp_wait_for_sndbuf(), the bit is checked again after\nre-acquiring the socket lock to detect the deletion. This is done while\nholding a reference to the transport to prevent it from being freed in\nthe process.\n\nIf the transport was deleted while the socket lock was relinquished,\nsctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the\nsend.\n\nThe bug was found by a private syzbot instance (see the error report [1]\nand the C reproducer that triggers it [2]).

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses\n\nAcquire a lock on kvm->srcu when userspace is getting MP state to handle a\nrather extreme edge case where "accepting" APIC events, i.e. processing\npending INIT or SIPI, can trigger accesses to guest memory. If the vCPU\nis in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP\nstate will trigger a nested VM-Exit by way of ->check_nested_events(), and\nemuating the nested VM-Exit can access guest memory.\n\nThe splat was originally hit by syzkaller on a Google-internal kernel, and\nreproduced on an upstream kernel by hacking the triple_fault_event_test\nselftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a\nmemory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.\n\n =============================\n WARNING: suspicious RCU usage\n 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!\n\n other info that might help us debug this:\n\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by triple_fault_ev/1256:\n #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]\n\n stack backtrace:\n CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n \n dump_stack_lvl+0x7f/0x90\n lockdep_rcu_suspicious+0x144/0x190\n kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]\n kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n read_and_check_msr_entry+0x2e/0x180 [kvm_intel]\n __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]\n kvm_check_nested_events+0x1b/0x30 [kvm]\n kvm_apic_accept_events+0x33/0x100 [kvm]\n kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]\n kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]\n __x64_sys_ioctl+0x8b/0xb0\n do_syscall_64+0x6c/0x170\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error\n\nAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),\nthe pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs\nhave been released.\n\nHowever, some requested IRQs remain unreleased, so there are still\n/proc/irq/* entries remaining, and this results in WARN() with the\nfollowing message:\n\n remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0'\n WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c\n\nTo solve this issue, set the number of remaining IRQs to test->num_irqs,\nand release IRQs in advance by calling pci_endpoint_test_release_irq().\n\n[kwilczynski: commit log]

In the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: fix pipe accounting mismatch\n\nCurrently, watch_queue_set_size() modifies the pipe buffers charged to\nuser->pipe_bufs without updating the pipe->nr_accounted on the pipe\nitself, due to the if (!pipe_has_watch_queue()) test in\npipe_resize_ring(). This means that when the pipe is ultimately freed,\nwe decrement user->pipe_bufs by something other than what than we had\ncharged to it, potentially leading to an underflow. This in turn can\ncause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.\n\nTo remedy this, explicitly account for the pipe usage in\nwatch_queue_set_size() to match the number set via account_pipe_buffers()\n\n(It's unclear why watch_queue_set_size() does not update nr_accounted;\nit may be due to intentional overprovisioning in watch_queue_set_size()?)

In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update\n\nCheck if policy is NULL before dereferencing it in amd_pstate_update.

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: int340x: Add NULL check for adev\n\nNot all devices have an ACPI companion fwnode, so adev might be NULL.\nThis is similar to the commit cd2fd6eab480\n("platform/x86: int3472: Check for adev == NULL").\n\nAdd a check for adev not being set and return -ENODEV in that case to\navoid a possible NULL pointer deref in int3402_thermal_probe().\n\nNote, under the same directory, int3400_thermal_probe() has such a\ncheck.\n\n[ rjw: Subject edit, added Fixes: ]

In the Linux kernel, the following vulnerability has been resolved:\n\nRISC-V: KVM: Teardown riscv specific bits after kvm_exit\n\nDuring a module removal, kvm_exit invokes arch specific disable\ncall which disables AIA. However, we invoke aia_exit before kvm_exit\nresulting in the following warning. KVM kernel module can't be inserted\nafterwards due to inconsistent state of IRQ.\n\n[25469.031389] percpu IRQ 31 still enabled on CPU0!\n[25469.031732] WARNING: CPU: 3 PID: 943 at kernel/irq/manage.c:2476 __free_percpu_irq+0xa2/0x150\n[25469.031804] Modules linked in: kvm(-)\n[25469.031848] CPU: 3 UID: 0 PID: 943 Comm: rmmod Not tainted 6.14.0-rc5-06947-g91c763118f47-dirty #2\n[25469.031905] Hardware name: riscv-virtio,qemu (DT)\n[25469.031928] epc : __free_percpu_irq+0xa2/0x150\n[25469.031976] ra : __free_percpu_irq+0xa2/0x150\n[25469.032197] epc : ffffffff8007db1e ra : ffffffff8007db1e sp : ff2000000088bd50\n[25469.032241] gp : ffffffff8131cef8 tp : ff60000080b96400 t0 : ff2000000088baf8\n[25469.032285] t1 : fffffffffffffffc t2 : 5249207570637265 s0 : ff2000000088bd90\n[25469.032329] s1 : ff60000098b21080 a0 : 037d527a15eb4f00 a1 : 037d527a15eb4f00\n[25469.032372] a2 : 0000000000000023 a3 : 0000000000000001 a4 : ffffffff8122dbf8\n[25469.032410] a5 : 0000000000000fff a6 : 0000000000000000 a7 : ffffffff8122dc10\n[25469.032448] s2 : ff60000080c22eb0 s3 : 0000000200000022 s4 : 000000000000001f\n[25469.032488] s5 : ff60000080c22e00 s6 : ffffffff80c351c0 s7 : 0000000000000000\n[25469.032582] s8 : 0000000000000003 s9 : 000055556b7fb490 s10: 00007ffff0e12fa0\n[25469.032621] s11: 00007ffff0e13e9a t3 : ffffffff81354ac7 t4 : ffffffff81354ac7\n[25469.032664] t5 : ffffffff81354ac8 t6 : ffffffff81354ac7\n[25469.032698] status: 0000000200000100 badaddr: ffffffff8007db1e cause: 0000000000000003\n[25469.032738] [] __free_percpu_irq+0xa2/0x150\n[25469.032797] [] free_percpu_irq+0x30/0x5e\n[25469.032856] [] kvm_riscv_aia_exit+0x40/0x42 [kvm]\n[25469.033947] [] cleanup_module+0x10/0x32 [kvm]\n[25469.035300] [] __riscv_sys_delete_module+0x18e/0x1fc\n[25469.035374] [] syscall_handler+0x3a/0x46\n[25469.035456] [] do_trap_ecall_u+0x72/0x134\n[25469.035536] [] handle_exception+0x148/0x156\n\nInvoke aia_exit and other arch specific cleanup functions after kvm_exit\nso that disable gets a chance to be called first before exit.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: timer: Don't take register_mutex with copy_from/to_user()\n\nThe infamous mmap_lock taken in copy_from/to_user() can be often\nproblematic when it's called inside another mutex, as they might lead\nto deadlocks.\n\nIn the case of ALSA timer code, the bad pattern is with\nguard(mutex)(®ister_mutex) that covers copy_from/to_user() -- which\nwas mistakenly introduced at converting to guard(), and it had been\ncarefully worked around in the past.\n\nThis patch fixes those pieces simply by moving copy_from/to_user() out\nof the register mutex lock again.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: update channel list in reg notifier instead reg worker\n\nCurrently when ath11k gets a new channel list, it will be processed\naccording to the following steps:\n1. update new channel list to cfg80211 and queue reg_work.\n2. cfg80211 handles new channel list during reg_work.\n3. update cfg80211's handled channel list to firmware by\nath11k_reg_update_chan_list().\n\nBut ath11k will immediately execute step 3 after reg_work is just\nqueued. Since step 2 is asynchronous, cfg80211 may not have completed\nhandling the new channel list, which may leading to an out-of-bounds\nwrite error:\nBUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list\nCall Trace:\n ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]\n kfree+0x109/0x3a0\n ath11k_regd_update+0x1cf/0x350 [ath11k]\n ath11k_regd_update_work+0x14/0x20 [ath11k]\n process_one_work+0xe35/0x14c0\n\nShould ensure step 2 is completely done before executing step 3. Thus\nWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,\ncfg80211 will notify ath11k after step 2 is done.\n\nSo enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will\nnotify ath11k after step 2 is done. At this time, there will be no\nKASAN bug during the execution of the step 3.\n\n[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/\n\nTested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: quota: fix to avoid warning in dquot_writeback_dquots()\n\nF2FS-fs (dm-59): checkpoint=enable has some unwritten data.\n\n------------[ cut here ]------------\nWARNING: CPU: 6 PID: 8013 at fs/quota/dquot.c:691 dquot_writeback_dquots+0x2fc/0x308\npc : dquot_writeback_dquots+0x2fc/0x308\nlr : f2fs_quota_sync+0xcc/0x1c4\nCall trace:\ndquot_writeback_dquots+0x2fc/0x308\nf2fs_quota_sync+0xcc/0x1c4\nf2fs_write_checkpoint+0x3d4/0x9b0\nf2fs_issue_checkpoint+0x1bc/0x2c0\nf2fs_sync_fs+0x54/0x150\nf2fs_do_sync_file+0x2f8/0x814\n__f2fs_ioctl+0x1960/0x3244\nf2fs_ioctl+0x54/0xe0\n__arm64_sys_ioctl+0xa8/0xe4\ninvoke_syscall+0x58/0x114\n\ncheckpoint and f2fs_remount may race as below, resulting triggering warning\nin dquot_writeback_dquots().\n\natomic write remount\n - do_remount\n - down_write(&sb->s_umount);\n - f2fs_remount\n- ioctl\n - f2fs_do_sync_file\n - f2fs_sync_fs\n - f2fs_write_checkpoint\n - block_operations\n - locked = down_read_trylock(&sbi->sb->s_umount)\n : fail to lock due to the write lock was held by remount\n - up_write(&sb->s_umount);\n - f2fs_quota_sync\n - dquot_writeback_dquots\n - WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount))\n : trigger warning because s_umount lock was unlocked by remount\n\nIf checkpoint comes from mount/umount/remount/freeze/quotactl, caller of\ncheckpoint has already held s_umount lock, calling dquot_writeback_dquots()\nin the context should be safe.\n\nSo let's record task to sbi->umount_lock_holder, so that checkpoint can\nknow whether the lock has held in the context or not by checking current\nw/ it.\n\nIn addition, in order to not misrepresent caller of checkpoint, we should\nnot allow to trigger async checkpoint for those callers: mount/umount/remount/\nfreeze/quotactl.

In the Linux kernel, the following vulnerability has been resolved:\n\ndlm: prevent NPD when writing a positive value to event_done\n\ndo_uevent returns the value written to event_done. In case it is a\npositive value, new_lockspace would undo all the work, and lockspace\nwould not be set. __dlm_new_lockspace, however, would treat that\npositive value as a success due to commit 8511a2728ab8 ("dlm: fix use\ncount with multiple joins").\n\nDown the line, device_create_lockspace would pass that NULL lockspace to\ndlm_find_lockspace_local, leading to a NULL pointer dereference.\n\nTreating such positive values as successes prevents the problem. Given\nthis has been broken for so long, this is unlikely to break userspace\nexpectations.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path\n\nIf a shared IRQ is used by the driver due to platform limitation, then the\nIRQ affinity hint is set right after the allocation of IRQ vectors in\nath11k_pci_alloc_msi(). This does no harm unless one of the functions\nrequesting the IRQ fails and attempt to free the IRQ. This results in the\nbelow warning:\n\nWARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c\nCall trace:\n free_irq+0x278/0x29c\n ath11k_pcic_free_irq+0x70/0x10c [ath11k]\n ath11k_pci_probe+0x800/0x820 [ath11k_pci]\n local_pci_probe+0x40/0xbc\n\nThe warning is due to not clearing the affinity hint before freeing the\nIRQs.\n\nSo to fix this issue, clear the IRQ affinity hint before calling\nath11k_pcic_free_irq() in the error path. The affinity will be cleared once\nagain further down the error path due to code organization, but that does\nno harm.\n\nTested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path\n\nIf a shared IRQ is used by the driver due to platform limitation, then the\nIRQ affinity hint is set right after the allocation of IRQ vectors in\nath12k_pci_msi_alloc(). This does no harm unless one of the functions\nrequesting the IRQ fails and attempt to free the IRQ.\n\nThis may end up with a warning from the IRQ core that is expecting the\naffinity hint to be cleared before freeing the IRQ:\n\nkernel/irq/manage.c:\n\n /* make sure affinity_hint is cleaned up */\n if (WARN_ON_ONCE(desc->affinity_hint))\n desc->affinity_hint = NULL;\n\nSo to fix this issue, clear the IRQ affinity hint before calling\nath12k_pci_free_irq() in the error path. The affinity will be cleared once\nagain further down the error path due to code organization, but that does\nno harm.

In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix mddev uaf while iterating all_mddevs list\n\nWhile iterating all_mddevs list from md_notify_reboot() and md_exit(),\nlist_for_each_entry_safe is used, and this can race with deletint the\nnext mddev, causing UAF:\n\nt1:\nspin_lock\n//list_for_each_entry_safe(mddev, n, ...)\n mddev_get(mddev1)\n // assume mddev2 is the next entry\n spin_unlock\n t2:\n //remove mddev2\n ...\n mddev_free\n spin_lock\n list_del\n spin_unlock\n kfree(mddev2)\n mddev_put(mddev1)\n spin_lock\n //continue dereference mddev2->all_mddevs\n\nThe old helper for_each_mddev() actually grab the reference of mddev2\nwhile holding the lock, to prevent from being freed. This problem can be\nfixed the same way, however, the code will be complex.\n\nHence switch to use list_for_each_entry, in this case mddev_put() can free\nthe mddev1 and it's not safe as well. Refer to md_seq_show(), also factor\nout a helper mddev_put_locked() to fix this problem.

In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1,raid10: don't ignore IO flags\n\nIf blk-wbt is enabled by default, it's found that raid write performance\nis quite bad because all IO are throttled by wbt of underlying disks,\ndue to flag REQ_IDLE is ignored. And turns out this behaviour exist since\nblk-wbt is introduced.\n\nOther than REQ_IDLE, other flags should not be ignored as well, for\nexample REQ_META can be set for filesystems, clearing it can cause priority\nreverse problems; And REQ_NOWAIT should not be cleared as well, because\nio will wait instead of failing directly in underlying disks.\n\nFix those problems by keep IO flags from master bio.\n\nFises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid accessing uninitialized curseg\n\nsyzbot reports a f2fs bug as below:\n\nF2FS-fs (loop3): Stopped filesystem due to reason: 7\nkworker/u8:7: attempt to access beyond end of device\nBUG: unable to handle page fault for address: ffffed1604ea3dfa\nRIP: 0010:get_ckpt_valid_blocks fs/f2fs/segment.h:361 [inline]\nRIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline]\nRIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline]\nRIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline]\nRIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649\n \n f2fs_is_checkpoint_ready fs/f2fs/segment.h:671 [inline]\n f2fs_write_inode+0x425/0x540 fs/f2fs/inode.c:791\n write_inode fs/fs-writeback.c:1525 [inline]\n __writeback_single_inode+0x708/0x10d0 fs/fs-writeback.c:1745\n writeback_sb_inodes+0x820/0x1360 fs/fs-writeback.c:1976\n wb_writeback+0x413/0xb80 fs/fs-writeback.c:2156\n wb_do_writeback fs/fs-writeback.c:2303 [inline]\n wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343\n process_one_work kernel/workqueue.c:3236 [inline]\n process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317\n worker_thread+0x870/0xd30 kernel/workqueue.c:3398\n kthread+0x7a9/0x920 kernel/kthread.c:464\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nCommit 8b10d3653735 ("f2fs: introduce FAULT_NO_SEGMENT") allows to trigger\nno free segment fault in allocator, then it will update curseg->segno to\nNULL_SEGNO, though, CP_ERROR_FLAG has been set, f2fs_write_inode() missed\nto check the flag, and access invalid curseg->segno directly in below call\npath, then resulting in panic:\n\n- f2fs_write_inode\n - f2fs_is_checkpoint_ready\n - has_enough_free_secs\n - has_not_enough_free_secs\n - __get_secs_required\n - has_curseg_enough_space\n - get_ckpt_valid_blocks\n : access invalid curseg->segno\n\nTo avoid this issue, let's:\n- check CP_ERROR_FLAG flag in prior to f2fs_is_checkpoint_ready() in\nf2fs_write_inode().\n- in has_curseg_enough_space(), save curseg->segno into a temp variable,\nand verify its validation before use.

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix adding folio to bio\n\n>4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage\nis supported, then 'offset' of folio can't be held in 'unsigned int',\ncause warning in bio_add_folio_nofail() and IO failure.\n\nFix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't\nbe overflow, and folio can be added to bio successfully.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()\n\nThere's issue as follows:\nBUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790\nRead of size 4 at addr ffff88807b003000 by task syz-executor.0/15172\n\nCPU: 3 PID: 15172 Comm: syz-executor.0\nCall Trace:\n __dump_stack lib/dump_stack.c:82 [inline]\n dump_stack+0xbe/0xfd lib/dump_stack.c:123\n print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400\n __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560\n kasan_report+0x3a/0x50 mm/kasan/report.c:585\n ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137\n ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896\n ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323\n evict+0x39f/0x880 fs/inode.c:622\n iput_final fs/inode.c:1746 [inline]\n iput fs/inode.c:1772 [inline]\n iput+0x525/0x6c0 fs/inode.c:1758\n ext4_orphan_cleanup fs/ext4/super.c:3298 [inline]\n ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300\n mount_bdev+0x355/0x410 fs/super.c:1446\n legacy_get_tree+0xfe/0x220 fs/fs_context.c:611\n vfs_get_tree+0x8d/0x2f0 fs/super.c:1576\n do_new_mount fs/namespace.c:2983 [inline]\n path_mount+0x119a/0x1ad0 fs/namespace.c:3316\n do_mount+0xfc/0x110 fs/namespace.c:3329\n __do_sys_mount fs/namespace.c:3540 [inline]\n __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514\n do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nMemory state around the buggy address:\n ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ^\n ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n\nAbove issue happens as ext4_xattr_delete_inode() isn't check xattr\nis valid if xattr is in inode.\nTo solve above issue call xattr_check_inode() check if xattr if valid\nin inode. In fact, we can directly verify in ext4_iget_extra_inode(),\nso that there is no divergent verification.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: goto right label 'out_mmap_sem' in ext4_setattr()\n\nOtherwise, if ext4_inode_attach_jinode() fails, a hung task will\nhappen because filemap_invalidate_unlock() isn't called to unlock\nmapping->invalidate_lock. Like this:\n\nEXT4-fs error (device sda) in ext4_setattr:5557: Out of memory\nINFO: task fsstress:374 blocked for more than 122 seconds.\n Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726\n"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\ntask:fsstress state:D stack:0 pid:374 tgid:374 ppid:373\n task_flags:0x440140 flags:0x00000000\nCall Trace:\n \n __schedule+0x2c9/0x7f0\n schedule+0x27/0xa0\n schedule_preempt_disabled+0x15/0x30\n rwsem_down_read_slowpath+0x278/0x4c0\n down_read+0x59/0xb0\n page_cache_ra_unbounded+0x65/0x1b0\n filemap_get_pages+0x124/0x3e0\n filemap_read+0x114/0x3d0\n vfs_read+0x297/0x360\n ksys_read+0x6c/0xe0\n do_syscall_64+0x4b/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: init wiphy_work before allocating rfkill fails\n\nsyzbort reported a uninitialize wiphy_work_lock in cfg80211_dev_free. [1]\n\nAfter rfkill allocation fails, the wiphy release process will be performed,\nwhich will cause cfg80211_dev_free to access the uninitialized wiphy_work\nrelated data.\n\nMove the initialization of wiphy_work to before rfkill initialization to\navoid this issue.\n\n[1]\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn't initialize this object before use?\nturning off the locking correctness validator.\nCPU: 0 UID: 0 PID: 5935 Comm: syz-executor550 Not tainted 6.14.0-rc6-syzkaller-00103-g4003c9e78778 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n assign_lock_key kernel/locking/lockdep.c:983 [inline]\n register_lock_class+0xc39/0x1240 kernel/locking/lockdep.c:1297\n __lock_acquire+0x135/0x3c40 kernel/locking/lockdep.c:5103\n lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5851\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x3a/0x60 kernel/locking/spinlock.c:162\n cfg80211_dev_free+0x30/0x3d0 net/wireless/core.c:1196\n device_release+0xa1/0x240 drivers/base/core.c:2568\n kobject_cleanup lib/kobject.c:689 [inline]\n kobject_release lib/kobject.c:720 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1e4/0x5a0 lib/kobject.c:737\n put_device+0x1f/0x30 drivers/base/core.c:3774\n wiphy_free net/wireless/core.c:1224 [inline]\n wiphy_new_nm+0x1c1f/0x2160 net/wireless/core.c:562\n ieee80211_alloc_hw_nm+0x1b7a/0x2260 net/mac80211/main.c:835\n mac80211_hwsim_new_radio+0x1d6/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5185\n hwsim_new_radio_nl+0xb42/0x12b0 drivers/net/wireless/virtual/mac80211_hwsim.c:6242\n genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2533\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]\n netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1338\n netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1882\n sock_sendmsg_nosec net/socket.c:718 [inline]\n __sock_sendmsg net/socket.c:733 [inline]\n ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2573\n ___sys_sendmsg+0x135/0x1e0 net/socket.c:2627\n __sys_sendmsg+0x16e/0x220 net/socket.c:2659\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n\nClose: https://syzkaller.appspot.com/bug?extid=aaf0488c83d1d5f4f029

In the Linux kernel, the following vulnerability has been resolved:\n\nice: validate queue quanta parameters to prevent OOB access\n\nAdd queue wraparound prevention in quanta configuration.\nEnsure end_qid does not overflow by validating start_qid and num_queues.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix using untrusted value of pkt_len in ice_vc_fdir_parse_raw()\n\nFix using the untrusted value of proto->raw.pkt_len in function\nice_vc_fdir_parse_raw() by verifying if it does not exceed the\nVIRTCHNL_MAX_SIZE_RAW_PACKET value.

In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: check error for register_netdev() on init\n\nCurrent init logic ignores the error code from register_netdev(),\nwhich will cause WARN_ON() on attempt to unregister it, if there was one,\nand there is no info for the user that the creation of the netdev failed.\n\nWARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10\n...\n[ 3707.563641] unregister_netdev+0x1c/0x30\n[ 3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf]\n[ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf]\n[ 3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf]\n[ 3707.563739] idpf_remove+0xbf/0x780 [idpf]\n[ 3707.563769] pci_device_remove+0xab/0x1e0\n[ 3707.563786] device_release_driver_internal+0x371/0x530\n[ 3707.563803] driver_detach+0xbf/0x180\n[ 3707.563816] bus_remove_driver+0x11b/0x2a0\n[ 3707.563829] pci_unregister_driver+0x2a/0x250\n\nIntroduce an error check and log the vport number and error code.\nOn removal make sure to check VPORT_REG_NETDEV flag prior to calling\nunregister and free on the netdev.\n\nAdd local variables for idx, vport_config and netdev for readability.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don't clobber ret in btrfs_validate_super()\n\nCommit 2a9bb78cfd36 ("btrfs: validate system chunk array at\nbtrfs_validate_super()") introduces a call to validate_sys_chunk_array()\nin btrfs_validate_super(), which clobbers the value of ret set earlier.\nThis has the effect of negating the validity checks done earlier, making\nit so btrfs could potentially try to mount invalid filesystems.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_queue: Initialize ctx to avoid memory allocation error\n\nIt is possible that ctx in nfqnl_build_packet_message() could be used\nbefore it is properly initialize, which is only initialized\nby nfqnl_get_sk_secctx().\n\nThis patch corrects this problem by initializing the lsmctx to a safe\nvalue when it is declared.\n\nThis is similar to the commit 35fcac7a7c25\n("audit: Initialize lsmctx to avoid memory allocation error").

In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Mask the bd_cnt field in the TX BD properly\n\nThe bd_cnt field in the TX BD specifies the total number of BDs for\nthe TX packet. The bd_cnt field has 5 bits and the maximum number\nsupported is 32 with the value 0.\n\nCONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB\nfragments can approach or exceed the maximum supported by the chip.\nAdd a macro to properly mask the bd_cnt field so that the value 32\nwill be properly masked and set to 0 in the bd_cnd field.\n\nWithout this patch, the out-of-range bd_cnt value will corrupt the\nTX BD and may cause TX timeout.\n\nThe next patch will check for values exceeding 32.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()\n\nThere are actually 2 problems:\n- deleting the last element doesn't require the memmove of elements\n [i + 1, end) over it. Actually, element i+1 is out of bounds.\n- The memmove itself should move size - i - 1 elements, because the last\n element is out of bounds.\n\nThe out-of-bounds element still remains out of bounds after being\naccessed, so the problem is only that we touch it, not that it becomes\nin active use. But I suppose it can lead to issues if the out-of-bounds\nelement is part of an unmapped page.

In the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: unregister xdp rxq info in the reset path\n\nvmxnet3 does not unregister xdp rxq info in the\nvmxnet3_reset_work() code path as vmxnet3_rq_destroy()\nis not invoked in this code path. So, we get below message with a\nbacktrace.\n\nMissing unregister, handled but fix driver\nWARNING: CPU:48 PID: 500 at net/core/xdp.c:182\n__xdp_rxq_info_reg+0x93/0xf0\n\nThis patch fixes the problem by moving the unregister\ncode of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().

In the Linux kernel, the following vulnerability has been resolved:\n\nibmvnic: Use kernel helpers for hex dumps\n\nPreviously, when the driver was printing hex dumps, the buffer was cast\nto an 8 byte long and printed using string formatters. If the buffer\nsize was not a multiple of 8 then a read buffer overflow was possible.\n\nTherefore, create a new ibmvnic function that loops over a buffer and\ncalls hex_dump_to_buffer instead.\n\nThis patch address KASAN reports like the one below:\n ibmvnic 30000003 env3: Login Buffer:\n ibmvnic 30000003 env3: 01000000af000000\n <...>\n ibmvnic 30000003 env3: 2e6d62692e736261\n ibmvnic 30000003 env3: 65050003006d6f63\n ==================================================================\n BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic]\n Read of size 8 at addr c0000001331a9aa8 by task ip/17681\n <...>\n Allocated by task 17681:\n <...>\n ibmvnic_login+0x2f0/0xffc [ibmvnic]\n ibmvnic_open+0x148/0x308 [ibmvnic]\n __dev_open+0x1ac/0x304\n <...>\n The buggy address is located 168 bytes inside of\n allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf)\n <...>\n =================================================================\n ibmvnic 30000003 env3: 000000000033766e

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: libwx: fix Tx L4 checksum\n\nThe hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol.\nThere was a bug to set Tx checksum flag for the other protocol that results\nin Tx ring hang. Fix to compute software checksum for these packets.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/panthor: Fix race condition when gathering fdinfo group samples\n\nCommit e16635d88fa0 ("drm/panthor: add DRM fdinfo support") failed to\nprotect access to groups with an xarray lock, which could lead to\nuse-after-free errors.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: xlnx: zynqmp_dpsub: Add NULL check in zynqmp_audio_init\n\ndevm_kasprintf() calls can return null pointers on failure.\nBut some return values were not checked in zynqmp_audio_init().\n\nAdd NULL check in zynqmp_audio_init(), avoid referencing null\npointers in the subsequent code.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set()\n\nInstead of attempting the same mutex twice, lock and unlock it.\n\nThis bug has been detected by the Clang thread-safety analyzer.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vkms: Fix use after free and double free on init error\n\nIf the driver initialization fails, the vkms_exit() function might\naccess an uninitialized or freed default_config pointer and it might\ndouble free it.\n\nFix both possible errors by initializing default_config only when the\ndriver initialization succeeded.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/gem: Fix error code msm_parse_deps()\n\nThe SUBMIT_ERROR() macro turns the error code negative. This extra '-'\noperation turns it back to positive EINVAL again. The error code is\npassed to ERR_PTR() and since positive values are not an IS_ERR() it\neventually will lead to an oops. Delete the '-'.\n\nPatchwork: https://patchwork.freedesktop.org/patch/637625/

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/perf: Fix ref-counting on the PMU 'vpa_pmu'\n\nCommit 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa\ncounters") introduced 'vpa_pmu' to expose Book3s-HV nested APIv2 provided\nL1<->L2 context switch latency counters to L1 user-space via\nperf-events. However the newly introduced PMU named 'vpa_pmu' doesn't\nassign ownership of the PMU to the module 'vpa_pmu'. Consequently the\nmodule 'vpa_pmu' can be unloaded while one of the perf-events are still\nactive, which can lead to kernel oops and panic of the form below on a\nPseries-LPAR:\n\nBUG: Kernel NULL pointer dereference on read at 0x00000058\n\n NIP [c000000000506cb8] event_sched_out+0x40/0x258\n LR [c00000000050e8a4] __perf_remove_from_context+0x7c/0x2b0\n Call Trace:\n [c00000025fc3fc30] [c00000025f8457a8] 0xc00000025f8457a8 (unreliable)\n [c00000025fc3fc80] [fffffffffffffee0] 0xfffffffffffffee0\n [c00000025fc3fcd0] [c000000000501e70] event_function+0xa8/0x120\n\n Kernel panic - not syncing: Aiee, killing interrupt handler!\n\nFix this by adding the module ownership to 'vpa_pmu' so that the module\n'vpa_pmu' is ref-counted and prevented from being unloaded when perf-events\nare initialized.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: avoid NPD when ASIC does not support DMUB\n\nctx->dmub_srv will de NULL if the ASIC does not support DMUB, which is\ntested in dm_dmub_sw_init.\n\nHowever, it will be dereferenced in dmub_hw_lock_mgr_cmd if\nshould_use_dmub_lock returns true.\n\nThis has been the case since dmub support has been added for PSR1.\n\nFix this by checking for dmub_srv in should_use_dmub_lock.\n\n[ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058\n[ 37.447808] #PF: supervisor read access in kernel mode\n[ 37.452959] #PF: error_code(0x0000) - not-present page\n[ 37.458112] PGD 0 P4D 0\n[ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88\n[ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0\n[ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5\n[ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202\n[ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358\n[ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000\n[ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5\n[ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000\n[ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000\n[ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000\n[ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0\n[ 37.572697] Call Trace:\n[ 37.575152] \n[ 37.577258] ? __die_body+0x66/0xb0\n[ 37.580756] ? page_fault_oops+0x3e7/0x4a0\n[ 37.584861] ? exc_page_fault+0x3e/0xe0\n[ 37.588706] ? exc_page_fault+0x5c/0xe0\n[ 37.592550] ? asm_exc_page_fault+0x22/0x30\n[ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0\n[ 37.601107] dcn10_cursor_lock+0x1e1/0x240\n[ 37.605211] program_cursor_attributes+0x81/0x190\n[ 37.609923] commit_planes_for_stream+0x998/0x1ef0\n[ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0\n[ 37.619703] dc_update_planes_and_stream+0x78/0x140\n[ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0\n[ 37.629832] ? srso_return_thunk+0x5/0x5f\n[ 37.633847] ? mark_held_locks+0x6d/0xd0\n[ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50\n[ 37.642135] ? srso_return_thunk+0x5/0x5f\n[ 37.646148] ? lockdep_hardirqs_on+0x95/0x150\n[ 37.650510] ? srso_return_thunk+0x5/0x5f\n[ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50\n[ 37.658883] ? srso_return_thunk+0x5/0x5f\n[ 37.662897] ? wait_for_common+0x186/0x1c0\n[ 37.666998] ? srso_return_thunk+0x5/0x5f\n[ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170\n[ 37.675983] commit_tail+0xf5/0x1c0\n[ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0\n[ 37.684186] drm_atomic_commit+0xd6/0x100\n[ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10\n[ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130\n[ 37.698054] drm_mode_cursor_common+0x501/0x670\n[ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[ 37.707572] drm_mode_cursor_ioctl+0x48/0x70\n[ 37.711851] drm_ioctl_kernel+0xf2/0x150\n[ 37.715781] drm_ioctl+0x363/0x590\n[ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10\n[ 37.724165] amdgpu_drm_ioctl+0x41/0x80\n[ 37.728013] __se_sys_ioctl+0x7f/0xd0\n[ 37.731685] do_syscall_64+0x87/0x100\n[ 37.735355] ? vma_end_read+0x12/0xe0\n[ 37.739024] ? srso_return_thunk+0x5/0x5f\n[ 37.743041] ? find_held_lock+0x47/0xf0\n[ 37.746884] ? vma_end_read+0x12/0xe0\n[ 37.750552] ? srso_return_thunk+0x5/0\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix NULL dereference in SR-IOV VF creation error path\n\nClean up when virtfn setup fails to prevent NULL pointer dereference\nduring device removal. The kernel oops below occurred due to incorrect\nerror handling flow when pci_setup_device() fails.\n\nAdd pci_iov_scan_device(), which handles virtfn allocation and setup and\ncleans up if pci_setup_device() fails, so pci_iov_add_virtfn() doesn't need\nto call pci_stop_and_remove_bus_device(). This prevents accessing\npartially initialized virtfn devices during removal.\n\n BUG: kernel NULL pointer dereference, address: 00000000000000d0\n RIP: 0010:device_del+0x3d/0x3d0\n Call Trace:\n pci_remove_bus_device+0x7c/0x100\n pci_iov_add_virtfn+0xfa/0x200\n sriov_enable+0x208/0x420\n mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core]\n sriov_numvfs_store+0xae/0x1a0\n\n[bhelgaas: commit log, return ERR_PTR(-ENOMEM) directly]

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix page_size variable overflow\n\nChange all variables storing mlx5_umem_mkc_find_best_pgsz() result to\nunsigned long to support values larger than 31 and avoid overflow.\n\nFor example: If we try to register 4GB of memory that is contiguous in\nphysical memory, the driver will optimize the page_size and try to use\nan mkey with 4GB entity size. The 'unsigned int' page_size variable will\noverflow to '0' and we'll hit the WARN_ON() in alloc_cacheable_mr().\n\nWARNING: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloc_cacheable_mr+0x22/0x580 [mlx5_ib]\nModules linked in: mlx5_ib mlx5_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre rdma_rxe rdma_ucm ib_uverbs ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm fuse ib_core [last unloaded: mlx5_core]\nCPU: 2 UID: 70878 PID: 1203 Comm: rdma_resource_l Tainted: G W 6.14.0-rc4-dirty #43\nTainted: [W]=WARN\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:alloc_cacheable_mr+0x22/0x580 [mlx5_ib]\nCode: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 <0f> 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41\nRSP: 0018:ffffc900006ffac8 EFLAGS: 00010246\nRAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001\nRDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600\nRBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000\nR10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240\nR13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00\nFS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \n ? __warn+0x81/0x130\n ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib]\n ? report_bug+0xfc/0x1e0\n ? handle_bug+0x55/0x90\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib]\n create_real_mr+0x54/0x150 [mlx5_ib]\n ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs]\n ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xca/0x140 [ib_uverbs]\n ib_uverbs_run_method+0x6d0/0x780 [ib_uverbs]\n ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\n ib_uverbs_cmd_verbs+0x19b/0x360 [ib_uverbs]\n ? walk_system_ram_range+0x79/0xd0\n ? ___pte_offset_map+0x1b/0x110\n ? __pte_offset_map_lock+0x80/0x100\n ib_uverbs_ioctl+0xac/0x110 [ib_uverbs]\n __x64_sys_ioctl+0x94/0xb0\n do_syscall_64+0x50/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fb7ecf0737b\nCode: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48\nRSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b\nRDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003\nRBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4\nR10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4\nR13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150\n

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()\n\nIf track_pfn_copy() fails, we already added the dst VMA to the maple\ntree. As fork() fails, we'll cleanup the maple tree, and stumble over\nthe dst VMA for which we neither performed any reservation nor copied\nany page tables.\n\nConsequently untrack_pfn() will see VM_PAT and try obtaining the\nPAT information from the page table -- which fails because the page\ntable was not copied.\n\nThe easiest fix would be to simply clear the VM_PAT flag of the dst VMA\nif track_pfn_copy() fails. However, the whole thing is about "simply"\nclearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()\nand performed a reservation, but copying the page tables fails, we'll\nsimply clear the VM_PAT flag, not properly undoing the reservation ...\nwhich is also wrong.\n\nSo let's fix it properly: set the VM_PAT flag only if the reservation\nsucceeded (leaving it clear initially), and undo the reservation if\nanything goes wrong while copying the page tables: clearing the VM_PAT\nflag after undoing the reservation.\n\nNote that any copied page table entries will get zapped when the VMA will\nget removed later, after copy_page_range() succeeded; as VM_PAT is not set\nthen, we won't try cleaning VM_PAT up once more and untrack_pfn() will be\nhappy. Note that leaving these page tables in place without a reservation\nis not a problem, as we are aborting fork(); this process will never run.\n\nA reproducer can trigger this usually at the first try:\n\n https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c\n\n WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110\n Modules linked in: ...\n CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n RIP: 0010:get_pat_info+0xf6/0x110\n ...\n Call Trace:\n \n ...\n untrack_pfn+0x52/0x110\n unmap_single_vma+0xa6/0xe0\n unmap_vmas+0x105/0x1f0\n exit_mmap+0xf6/0x460\n __mmput+0x4b/0x120\n copy_process+0x1bf6/0x2aa0\n kernel_clone+0xab/0x440\n __do_sys_clone+0x66/0x90\n do_syscall_64+0x95/0x180\n\nLikely this case was missed in:\n\n d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")\n\n... and instead of undoing the reservation we simply cleared the VM_PAT flag.\n\nKeep the documentation of these functions in include/linux/pgtable.h,\none place is more than sufficient -- we should clean that up for the other\nfunctions like track_pfn_remap/untrack_pfn separately.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/erdma: Prevent use-after-free in erdma_accept_newconn()\n\nAfter the erdma_cep_put(new_cep) being called, new_cep will be freed,\nand the following dereference will cause a UAF problem. Fix this issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix array bounds error with may_goto\n\nmay_goto uses an additional 8 bytes on the stack, which causes the\ninterpreters[] array to go out of bounds when calculating index by\nstack_size.\n\n1. If a BPF program is rewritten, re-evaluate the stack size. For non-JIT\ncases, reject loading directly.\n\n2. For non-JIT cases, calculating interpreters[idx] may still cause\nout-of-bounds array access, and just warn about it.\n\n3. For jit_requested cases, the execution of bpf_func also needs to be\nwarned. So move the definition of function __bpf_prog_ret0_warn out of\nthe macro definition CONFIG_BPF_JIT_ALWAYS_ON.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Fix use-after-free when rename device name\n\nSyzbot reported a slab-use-after-free with the following call trace:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in nla_put+0xd3/0x150 lib/nlattr.c:1099\nRead of size 5 at addr ffff888140ea1c60 by task syz.0.988/10025\n\nCPU: 0 UID: 0 PID: 10025 Comm: syz.0.988\nNot tainted 6.14.0-rc4-syzkaller-00859-gf77f12010f67 #0\nHardware name: Google Compute Engine, BIOS Google 02/12/2025\nCall Trace:\n \n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0x16e/0x5b0 mm/kasan/report.c:521\n kasan_report+0x143/0x180 mm/kasan/report.c:634\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n nla_put+0xd3/0x150 lib/nlattr.c:1099\n nla_put_string include/net/netlink.h:1621 [inline]\n fill_nldev_handle+0x16e/0x200 drivers/infiniband/core/nldev.c:265\n rdma_nl_notify_event+0x561/0xef0 drivers/infiniband/core/nldev.c:2857\n ib_device_notify_register+0x22/0x230 drivers/infiniband/core/device.c:1344\n ib_register_device+0x1292/0x1460 drivers/infiniband/core/device.c:1460\n rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540\n rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212\n nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795\n rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]\n rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:709 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:724\n ____sys_sendmsg+0x53a/0x860 net/socket.c:2564\n ___sys_sendmsg net/socket.c:2618 [inline]\n __sys_sendmsg+0x269/0x350 net/socket.c:2650\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f42d1b8d169\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 ...\nRSP: 002b:00007f42d2960038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f42d1da6320 RCX: 00007f42d1b8d169\nRDX: 0000000000000000 RSI: 00004000000002c0 RDI: 000000000000000c\nRBP: 00007f42d1c0e2a0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f42d1da6320 R15: 00007ffe399344a8\n \n\nAllocated by task 10025:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4294 [inline]\n __kmalloc_node_track_caller_noprof+0x28b/0x4c0 mm/slub.c:4313\n __kmemdup_nul mm/util.c:61 [inline]\n kstrdup+0x42/0x100 mm/util.c:81\n kobject_set_name_vargs+0x61/0x120 lib/kobject.c:274\n dev_set_name+0xd5/0x120 drivers/base/core.c:3468\n assign_name drivers/infiniband/core/device.c:1202 [inline]\n ib_register_device+0x178/0x1460 drivers/infiniband/core/device.c:1384\n rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540\n rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212\n nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795\n rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]\n rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8de/0xcb0 net\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nw1: fix NULL pointer dereference in probe\n\nThe w1_uart_probe() function calls w1_uart_serdev_open() (which includes\ndevm_serdev_device_open()) before setting the client ops via\nserdev_device_set_client_ops(). This ordering can trigger a NULL pointer\ndereference in the serdev controller's receive_buf handler, as it assumes\nserdev->ops is valid when SERPORT_ACTIVE is set.\n\nThis is similar to the issue fixed in commit 5e700b384ec1\n("platform/chrome: cros_ec_uart: properly fix race condition") where\ndevm_serdev_device_open() was called before fully initializing the\ndevice.\n\nFix the race by ensuring client ops are set before enabling the port via\nw1_uart_serdev_open().

In the Linux kernel, the following vulnerability has been resolved:\n\niio: backend: make sure to NULL terminate stack buffer\n\nMake sure to NULL terminate the buffer in\niio_backend_debugfs_write_reg() before passing it to sscanf(). It is a\nstack variable so we should not assume it will 0 initialized.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix a couple integer overflows on 32bit systems\n\nOn 32bit systems the "off + sizeof(struct NTFS_DE)" addition can\nhave an integer wrapping issue. Fix it by using size_add().

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Prevent integer overflow in hdr_first_de()\n\nThe "de_off" and "used" variables come from the disk so they both need to\ncheck. The problem is that on 32bit systems if they're both greater than\nUINT_MAX - 16 then the check does work as intended because of an integer\noverflow.

In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: validate l_tree_depth to avoid out-of-bounds access\n\nThe l_tree_depth field is 16-bit (__le16), but the actual maximum depth is\nlimited to OCFS2_MAX_PATH_DEPTH.\n\nAdd a check to prevent out-of-bounds access if l_tree_depth has an invalid\nvalue, which may occur when reading from a corrupted mounted disk [1].

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: vchiq_arm: Fix possible NPR of keep-alive thread\n\nIn case vchiq_platform_conn_state_changed() is never called or fails before\ndriver removal, ka_thread won't be a valid pointer to a task_struct. So\ndo the necessary checks before calling kthread_stop to avoid a crash.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "smb: client: fix TCP timers deadlock after rmmod"\n\nThis reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.\n\nCommit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after\nrmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is\nmentioned as CVE-2024-54680, but is actually did not fix anything;\nThe issue can be reproduced on top of it. [0]\n\nAlso, it reverted the change by commit ef7134c7fc48 ("smb: client:\nFix use-after-free of network namespace.") and introduced a real\nissue by reviving the kernel TCP socket.\n\nWhen a reconnect happens for a CIFS connection, the socket state\ntransitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()\nin tcp_close() stops all timers for the socket.\n\nIf an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1\nforever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.\n\nUsually, FIN can be retransmitted by the peer, but if the peer aborts\nthe connection, the issue comes into reality.\n\nI warned about this privately by pointing out the exact report [1],\nbut the bogus fix was finally merged.\n\nSo, we should not stop the timers to finally kill the connection on\nour side in that case, meaning we must not use a kernel socket for\nTCP whose sk->sk_net_refcnt is 0.\n\nThe kernel socket does not have a reference to its netns to make it\npossible to tear down netns without cleaning up every resource in it.\n\nFor example, tunnel devices use a UDP socket internally, but we can\ndestroy netns without removing such devices and let it complete\nduring exit. Otherwise, netns would be leaked when the last application\ndied.\n\nHowever, this is problematic for TCP sockets because TCP has timers to\nclose the connection gracefully even after the socket is close()d. The\nlifetime of the socket and its netns is different from the lifetime of\nthe underlying connection.\n\nIf the socket user does not maintain the netns lifetime, the timer could\nbe fired after the socket is close()d and its netns is freed up, resulting\nin use-after-free.\n\nActually, we have seen so many similar issues and converted such sockets\nto have a reference to netns.\n\nThat's why I converted the CIFS client socket to have a reference to\nnetns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope\nof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right\nfix**.\n\nRegarding the LOCKDEP issue, we can prevent the module unload by\nbumping the module refcount when switching the LOCKDDEP key in\nsock_lock_init_class_and_name(). [2]\n\nFor a while, let's revert the bogus fix.\n\nNote that now we can use sk_net_refcnt_upgrade() for the socket\nconversion, but I'll do so later separately to make backport easy.

In the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix missing shutdown check\n\nxfstests generic/730 test failed because after deleting the device\nthat still had dirty data, the file could still be read without\nreturning an error. The reason is the missing shutdown check in\n->read_iter.\n\nI also noticed that shutdown checks were missing from ->write_iter,\n->splice_read, and ->mmap. This commit adds shutdown checks to all\nof them.

In the Linux kernel, the following vulnerability has been resolved:\n\nrtnetlink: Allocate vfinfo size for VF GUIDs when supported\n\nCommit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")\nadded support for getting VF port and node GUIDs in netlink ifinfo\nmessages, but their size was not taken into consideration in the\nfunction that allocates the netlink message, causing the following\nwarning when a netlink message is filled with many VF port and node\nGUIDs:\n # echo 64 > /sys/bus/pci/devices/0000\\:08\\:00.0/sriov_numvfs\n # ip link show dev ib0\n RTNETLINK answers: Message too long\n Cannot send link get request: Message too long\n\nKernel warning:\n\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0\n Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core\n CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #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:rtnl_getlink+0x586/0x5a0\n Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00\n RSP: 0018:ffff888113557348 EFLAGS: 00010246\n RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000\n RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8\n RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000\n R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00\n R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff\n FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \n ? __warn+0xa5/0x230\n ? rtnl_getlink+0x586/0x5a0\n ? report_bug+0x22d/0x240\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x14/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? skb_trim+0x6a/0x80\n ? rtnl_getlink+0x586/0x5a0\n ? __pfx_rtnl_getlink+0x10/0x10\n ? rtnetlink_rcv_msg+0x1e5/0x860\n ? __pfx___mutex_lock+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx_lock_acquire+0x10/0x10\n ? stack_trace_save+0x90/0xd0\n ? filter_irq_stacks+0x1d/0x70\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n rtnetlink_rcv_msg+0x21c/0x860\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? arch_stack_walk+0x9e/0xf0\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n ? rcu_is_watching+0x34/0x60\n netlink_rcv_skb+0xe0/0x210\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? __pfx_netlink_rcv_skb+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx___netlink_lookup+0x10/0x10\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0xfd/0x290\n ? rcu_is_watching+0x34/0x60\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0x95/0x290\n netlink_unicast+0x31f/0x480\n ? __pfx_netlink_unicast+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n netlink_sendmsg+0x369/0x660\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ? import_ubuf+0xb9/0xf0\n ? __import_iovec+0x254/0x2b0\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ____sys_sendmsg+0x559/0x5a0\n ? __pfx_____sys_sendmsg+0x10/0x10\n ? __pfx_copy_msghdr_from_user+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? do_read_fault+0x213/0x4a0\n ? rcu_is_watching+0x34/0x60\n ___sys_sendmsg+0xe4/0x150\n ? __pfx____sys_sendmsg+0x10/0x10\n ? do_fault+0x2cc/0x6f0\n ? handle_pte_fault+0x2e3/0x3d0\n ? __pfx_handle_pte_fault+0x10/0x10\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix r_count dec/increment mismatch\n\nr_count is only increased when there is an oplock break wait,\nso r_count inc/decrement are not paired. This can cause r_count\nto become negative, which can lead to a problem where the ksmbd\nthread does not terminate.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/9p: fix NULL pointer dereference on mkdir\n\nWhen a 9p tree was mounted with option 'posixacl', parent directory had a\ndefault ACL set for its subdirectories, e.g.:\n\n setfacl -m default:group:simpsons:rwx parentdir\n\nthen creating a subdirectory crashed 9p client, as v9fs_fid_add() call in\nfunction v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL\n(since dafbe689736) even though the subsequent v9fs_set_create_acl() call\nexpects a valid non-NULL 'fid' pointer:\n\n [ 37.273191] BUG: kernel NULL pointer dereference, address: 0000000000000000\n ...\n [ 37.322338] Call Trace:\n [ 37.323043] \n [ 37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)\n [ 37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714)\n [ 37.325532] ? search_module_extables (kernel/module/main.c:3733)\n [ 37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet\n [ 37.328006] ? search_bpf_extables (kernel/bpf/core.c:804)\n [ 37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538)\n [ 37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574)\n [ 37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet\n [ 37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p\n [ 37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p\n [ 37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p\n [ 37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p\n [ 37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p\n [ 37.338590] vfs_mkdir (fs/namei.c:4313)\n [ 37.339535] do_mkdirat (fs/namei.c:4336)\n [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354)\n [ 37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\n [ 37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nFix this by simply swapping the sequence of these two calls in\nv9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before\nv9fs_fid_add().

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler\n\nNaresh Kamboju reported a "Bad frame pointer" kernel warning while\nrunning LTP trace ftrace_stress_test.sh in riscv. We can reproduce the\nsame issue with the following command:\n\n```\n$ cd /sys/kernel/debug/tracing\n$ echo 'f:myprobe do_nanosleep%return args1=$retval' > dynamic_events\n$ echo 1 > events/fprobes/enable\n$ echo 1 > tracing_on\n$ sleep 1\n```\n\nAnd we can get the following kernel warning:\n\n[ 127.692888] ------------[ cut here ]------------\n[ 127.693755] Bad frame pointer: expected ff2000000065be50, received ba34c141e9594000\n[ 127.693755] from func do_nanosleep return to ffffffff800ccb16\n[ 127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be\n[ 127.699894] Modules linked in:\n[ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32\n[ 127.701453] Hardware name: riscv-virtio,qemu (DT)\n[ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be\n[ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be\n[ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10\n[ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000\n[ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80\n[ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1 : ffffffff81894f20\n[ 127.702408] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000\n[ 127.702470] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038\n[ 127.702530] s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff2000000065bdd0\n[ 127.702591] s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : 0000000000000068\n[ 127.702651] s8 : 00007fff8adf5d10 s9 : 000000000000006d s10: 0000000000000001\n[ 127.702710] s11: 00005555737377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e\n[ 127.702769] t5 : ffffffff819d89a0 t6 : ff2000000065bb18\n[ 127.702826] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003\n[ 127.703292] [] ftrace_return_to_handler+0x1b2/0x1be\n[ 127.703760] [] return_to_handler+0x16/0x26\n[ 127.704009] [] return_to_handler+0x0/0x26\n[ 127.704057] [] common_nsleep+0x42/0x54\n[ 127.704117] [] __riscv_sys_clock_nanosleep+0xba/0x10a\n[ 127.704176] [] do_trap_ecall_u+0x188/0x218\n[ 127.704295] [] handle_exception+0x14a/0x156\n[ 127.705436] ---[ end trace 0000000000000000 ]---\n\nThe reason is that the stack layout for constructing argument for the\nftrace_return_to_handler in the return_to_handler does not match the\n__arch_ftrace_regs structure of riscv, leading to unexpected results.

In the Linux kernel, the following vulnerability has been resolved:\n\nublk: make sure ubq->canceling is set when queue is frozen\n\nNow ublk driver depends on `ubq->canceling` for deciding if the request\ncan be dispatched via uring_cmd & io_uring_cmd_complete_in_task().\n\nOnce ubq->canceling is set, the uring_cmd can be done via ublk_cancel_cmd()\nand io_uring_cmd_done().\n\nSo set ubq->canceling when queue is frozen, this way makes sure that the\nflag can be observed from ublk_queue_rq() reliably, and avoids\nuse-after-free on uring_cmd.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: cadence: Fix out-of-bounds array access in cdns_mrvl_xspi_setup_clock()\n\nIf requested_clk > 128, cdns_mrvl_xspi_setup_clock() iterates over the\nentire cdns_mrvl_xspi_clk_div_list array without breaking out early,\ncausing 'i' to go beyond the array bounds.\n\nFix that by stopping the loop when it gets to the last entry, clamping\nthe clock to the minimum 6.25 MHz.\n\nFixes the following warning with an UBSAN kernel:\n\n vmlinux.o: warning: objtool: cdns_mrvl_xspi_setup_clock: unexpected end of section .text.cdns_mrvl_xspi_setup_clock

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: imx-card: Add NULL check in imx_card_probe()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\nimx_card_probe() does not check for this case, which results in a NULL\npointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix adapter NULL pointer dereference on reboot\n\nWith SRIOV enabled, idpf ends up calling into idpf_remove() twice.\nFirst via idpf_shutdown() and then again when idpf_remove() calls into\nsriov_disable(), because the VF devices use the idpf driver, hence the\nsame remove routine. When that happens, it is possible for the adapter\nto be NULL from the first call to idpf_remove(), leading to a NULL\npointer dereference.\n\necho 1 > /sys/class/net//device/sriov_numvfs\nreboot\n\nBUG: kernel NULL pointer dereference, address: 0000000000000020\n...\nRIP: 0010:idpf_remove+0x22/0x1f0 [idpf]\n...\n? idpf_remove+0x22/0x1f0 [idpf]\n? idpf_remove+0x1e4/0x1f0 [idpf]\npci_device_remove+0x3f/0xb0\ndevice_release_driver_internal+0x19f/0x200\npci_stop_bus_device+0x6d/0x90\npci_stop_and_remove_bus_device+0x12/0x20\npci_iov_remove_virtfn+0xbe/0x120\nsriov_disable+0x34/0xe0\nidpf_sriov_configure+0x58/0x140 [idpf]\nidpf_remove+0x1b9/0x1f0 [idpf]\nidpf_shutdown+0x12/0x30 [idpf]\npci_device_shutdown+0x35/0x60\ndevice_shutdown+0x156/0x200\n...\n\nReplace the direct idpf_remove() call in idpf_shutdown() with\nidpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform\nthe bulk of the cleanup, such as stopping the init task, freeing IRQs,\ndestroying the vports and freeing the mailbox. This avoids the calls to\nsriov_disable() in addition to a small netdev cleanup, and destroying\nworkqueues, which don't seem to be required on shutdown.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: don't unregister hook when table is dormant\n\nWhen nf_tables_updchain encounters an error, hook registration needs to\nbe rolled back.\n\nThis should only be done if the hook has been registered, which won't\nhappen when the table is flagged as dormant (inactive).\n\nJust move the assignment into the registration block.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets\n\nWhen calling netlbl_conn_setattr(), addr->sa_family is used\nto determine the function behavior. If sk is an IPv4 socket,\nbut the connect function is called with an IPv6 address,\nthe function calipso_sock_setattr() is triggered.\nInside this function, the following code is executed:\n\nsk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;\n\nSince sk is an IPv4 socket, pinet6 is NULL, leading to a\nnull pointer dereference.\n\nThis patch fixes the issue by checking if inet6_sk(sk)\nreturns a NULL pointer before accessing pinet6.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: airoha: Fix qid report in airoha_tc_get_htb_get_leaf_queue()\n\nFix the following kernel warning deleting HTB offloaded leafs and/or root\nHTB qdisc in airoha_eth driver properly reporting qid in\nairoha_tc_get_htb_get_leaf_queue routine.\n\n$tc qdisc replace dev eth1 root handle 10: htb offload\n$tc class add dev eth1 arent 10: classid 10:4 htb rate 100mbit ceil 100mbit\n$tc qdisc replace dev eth1 parent 10:4 handle 4: ets bands 8 \\\n quanta 1514 3028 4542 6056 7570 9084 10598 12112\n$tc qdisc del dev eth1 root\n\n[ 55.827864] ------------[ cut here ]------------\n[ 55.832493] WARNING: CPU: 3 PID: 2678 at 0xffffffc0798695a4\n[ 55.956510] CPU: 3 PID: 2678 Comm: tc Tainted: G O 6.6.71 #0\n[ 55.963557] Hardware name: Airoha AN7581 Evaluation Board (DT)\n[ 55.969383] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 55.976344] pc : 0xffffffc0798695a4\n[ 55.979851] lr : 0xffffffc079869a20\n[ 55.983358] sp : ffffffc0850536a0\n[ 55.986665] x29: ffffffc0850536a0 x28: 0000000000000024 x27: 0000000000000001\n[ 55.993800] x26: 0000000000000000 x25: ffffff8008b19000 x24: ffffff800222e800\n[ 56.000935] x23: 0000000000000001 x22: 0000000000000000 x21: ffffff8008b19000\n[ 56.008071] x20: ffffff8002225800 x19: ffffff800379d000 x18: 0000000000000000\n[ 56.015206] x17: ffffffbf9ea59000 x16: ffffffc080018000 x15: 0000000000000000\n[ 56.022342] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001\n[ 56.029478] x11: ffffffc081471008 x10: ffffffc081575a98 x9 : 0000000000000000\n[ 56.036614] x8 : ffffffc08167fd40 x7 : ffffffc08069e104 x6 : ffffff8007f86000\n[ 56.043748] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000001\n[ 56.050884] x2 : 0000000000000000 x1 : 0000000000000250 x0 : ffffff800222c000\n[ 56.058020] Call trace:\n[ 56.060459] 0xffffffc0798695a4\n[ 56.063618] 0xffffffc079869a20\n[ 56.066777] __qdisc_destroy+0x40/0xa0\n[ 56.070528] qdisc_put+0x54/0x6c\n[ 56.073748] qdisc_graft+0x41c/0x648\n[ 56.077324] tc_get_qdisc+0x168/0x2f8\n[ 56.080978] rtnetlink_rcv_msg+0x230/0x330\n[ 56.085076] netlink_rcv_skb+0x5c/0x128\n[ 56.088913] rtnetlink_rcv+0x14/0x1c\n[ 56.092490] netlink_unicast+0x1e0/0x2c8\n[ 56.096413] netlink_sendmsg+0x198/0x3c8\n[ 56.100337] ____sys_sendmsg+0x1c4/0x274\n[ 56.104261] ___sys_sendmsg+0x7c/0xc0\n[ 56.107924] __sys_sendmsg+0x44/0x98\n[ 56.111492] __arm64_sys_sendmsg+0x20/0x28\n[ 56.115580] invoke_syscall.constprop.0+0x58/0xfc\n[ 56.120285] do_el0_svc+0x3c/0xbc\n[ 56.123592] el0_svc+0x18/0x4c\n[ 56.126647] el0t_64_sync_handler+0x118/0x124\n[ 56.131005] el0t_64_sync+0x150/0x154\n[ 56.134660] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mvpp2: Prevent parser TCAM memory corruption\n\nProtect the parser TCAM/SRAM memory, and the cached (shadow) SRAM\ninformation, from concurrent modifications.\n\nBoth the TCAM and SRAM tables are indirectly accessed by configuring\nan index register that selects the row to read or write to. This means\nthat operations must be atomic in order to, e.g., avoid spreading\nwrites across multiple rows. Since the shadow SRAM array is used to\nfind free rows in the hardware table, it must also be protected in\norder to avoid TOCTOU errors where multiple cores allocate the same\nrow.\n\nThis issue was detected in a situation where `mvpp2_set_rx_mode()` ran\nconcurrently on two CPUs. In this particular case the\nMVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the\nclassifier unit to drop all incoming unicast - indicated by the\n`rx_classifier_drops` counter.

In the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix multiple wraparounds of sk->sk_rmem_alloc.\n\n__udp_enqueue_schedule_skb() has the following condition:\n\n if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)\n goto drop;\n\nsk->sk_rcvbuf is initialised by net.core.rmem_default and later can\nbe configured by SO_RCVBUF, which is limited by net.core.rmem_max,\nor SO_RCVBUFFORCE.\n\nIf we set INT_MAX to sk->sk_rcvbuf, the condition is always false\nas sk->sk_rmem_alloc is also signed int.\n\nThen, the size of the incoming skb is added to sk->sk_rmem_alloc\nunconditionally.\n\nThis results in integer overflow (possibly multiple times) on\nsk->sk_rmem_alloc and allows a single socket to have skb up to\nnet.core.udp_mem[1].\n\nFor example, if we set a large value to udp_mem[1] and INT_MAX to\nsk->sk_rcvbuf and flood packets to the socket, we can see multiple\noverflows:\n\n # cat /proc/net/sockstat