In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix deadlock triggered by cancel_delayed_work_syn()\n\nThe following LOCKDEP was detected:\n Workqueue: events smc_lgr_free_work [smc]\n WARNING: possible circular locking dependency detected\n 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted\n ------------------------------------------------------\n kworker/3:0/176251 is trying to acquire lock:\n 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0},\n at: __flush_workqueue+0x7a/0x4f0\n but task is already holding lock:\n 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0},\n at: process_one_work+0x232/0x730\n which lock already depends on the new lock.\n the existing dependency chain (in reverse order) is:\n -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:\n __lock_acquire+0x58e/0xbd8\n lock_acquire.part.0+0xe2/0x248\n lock_acquire+0xac/0x1c8\n __flush_work+0x76/0xf0\n __cancel_work_timer+0x170/0x220\n __smc_lgr_terminate.part.0+0x34/0x1c0 [smc]\n smc_connect_rdma+0x15e/0x418 [smc]\n __smc_connect+0x234/0x480 [smc]\n smc_connect+0x1d6/0x230 [smc]\n __sys_connect+0x90/0xc0\n __do_sys_socketcall+0x186/0x370\n __do_syscall+0x1da/0x208\n system_call+0x82/0xb0\n -> #3 (smc_client_lgr_pending){+.+.}-{3:3}:\n __lock_acquire+0x58e/0xbd8\n lock_acquire.part.0+0xe2/0x248\n lock_acquire+0xac/0x1c8\n __mutex_lock+0x96/0x8e8\n mutex_lock_nested+0x32/0x40\n smc_connect_rdma+0xa4/0x418 [smc]\n __smc_connect+0x234/0x480 [smc]\n smc_connect+0x1d6/0x230 [smc]\n __sys_connect+0x90/0xc0\n __do_sys_socketcall+0x186/0x370\n __do_syscall+0x1da/0x208\n system_call+0x82/0xb0\n -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}:\n __lock_acquire+0x58e/0xbd8\n lock_acquire.part.0+0xe2/0x248\n lock_acquire+0xac/0x1c8\n lock_sock_nested+0x46/0xa8\n smc_tx_work+0x34/0x50 [smc]\n process_one_work+0x30c/0x730\n worker_thread+0x62/0x420\n kthread+0x138/0x150\n __ret_from_fork+0x3c/0x58\n ret_from_fork+0xa/0x40\n -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}:\n __lock_acquire+0x58e/0xbd8\n lock_acquire.part.0+0xe2/0x248\n lock_acquire+0xac/0x1c8\n process_one_work+0x2bc/0x730\n worker_thread+0x62/0x420\n kthread+0x138/0x150\n __ret_from_fork+0x3c/0x58\n ret_from_fork+0xa/0x40\n -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}:\n check_prev_add+0xd8/0xe88\n validate_chain+0x70c/0xb20\n __lock_acquire+0x58e/0xbd8\n lock_acquire.part.0+0xe2/0x248\n lock_acquire+0xac/0x1c8\n __flush_workqueue+0xaa/0x4f0\n drain_workqueue+0xaa/0x158\n destroy_workqueue+0x44/0x2d8\n smc_lgr_free+0x9e/0xf8 [smc]\n process_one_work+0x30c/0x730\n worker_thread+0x62/0x420\n kthread+0x138/0x150\n __ret_from_fork+0x3c/0x58\n ret_from_fork+0xa/0x40\n other info that might help us debug this:\n Chain exists of:\n (wq_completion)smc_tx_wq-00000000#2\n --> smc_client_lgr_pending\n --> (work_completion)(&(&lgr->free_work)->work)\n Possible unsafe locking scenario:\n CPU0 CPU1\n ---- ----\n lock((work_completion)(&(&lgr->free_work)->work));\n lock(smc_client_lgr_pending);\n lock((work_completion)\n (&(&lgr->free_work)->work));\n lock((wq_completion)smc_tx_wq-00000000#2);\n *** DEADLOCK ***\n 2 locks held by kworker/3:0/176251:\n #0: 0000000080183548\n ((wq_completion)events){+.+.}-{0:0},\n at: process_one_work+0x232/0x730\n #1: 0000037fffe97dc8\n ((work_completion)\n (&(&lgr->free_work)->work)){+.+.}-{0:0},\n at: process_one_work+0x232/0x730\n stack backtr\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: mt7921: fix kernel panic by accessing unallocated eeprom.data\n\nThe MT7921 driver no longer uses eeprom.data, but the relevant code has not\nbeen removed completely since\ncommit 16d98b548365 ("mt76: mt7921: rely on mcu_get_nic_capability").\nThis could result in potential invalid memory access.\n\nTo fix the kernel panic issue in mt7921, it is necessary to avoid accessing\nunallocated eeprom.data which can lead to invalid memory access.\n\nFurthermore, it is possible to entirely eliminate the\nmt7921_mcu_parse_eeprom function and solely depend on\nmt7921_mcu_parse_response to divide the RxD header.\n\n[2.702735] BUG: kernel NULL pointer dereference, address: 0000000000000550\n[2.702740] #PF: supervisor write access in kernel mode\n[2.702741] #PF: error_code(0x0002) - not-present page\n[2.702743] PGD 0 P4D 0\n[2.702747] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[2.702755] RIP: 0010:mt7921_mcu_parse_response+0x147/0x170 [mt7921_common]\n[2.702758] RSP: 0018:ffffae7c00fef828 EFLAGS: 00010286\n[2.702760] RAX: ffffa367f57be024 RBX: ffffa367cc7bf500 RCX: 0000000000000000\n[2.702762] RDX: 0000000000000550 RSI: 0000000000000000 RDI: ffffa367cc7bf500\n[2.702763] RBP: ffffae7c00fef840 R08: ffffa367cb167000 R09: 0000000000000005\n[2.702764] R10: 0000000000000000 R11: ffffffffc04702e4 R12: ffffa367e8329f40\n[2.702766] R13: 0000000000000000 R14: 0000000000000001 R15: ffffa367e8329f40\n[2.702768] FS: 000079ee6cf20c40(0000) GS:ffffa36b2f940000(0000) knlGS:0000000000000000\n[2.702769] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[2.702775] CR2: 0000000000000550 CR3: 00000001233c6004 CR4: 0000000000770ee0\n[2.702776] PKRU: 55555554\n[2.702777] Call Trace:\n[2.702782] mt76_mcu_skb_send_and_get_msg+0xc3/0x11e [mt76 ]\n[2.702785] mt7921_run_firmware+0x241/0x853 [mt7921_common ]\n[2.702789] mt7921e_mcu_init+0x2b/0x56 [mt7921e ]\n[2.702792] mt7921_register_device+0x2eb/0x5a5 [mt7921_common ]\n[2.702795] ? mt7921_irq_tasklet+0x1d4/0x1d4 [mt7921e ]\n[2.702797] mt7921_pci_probe+0x2d6/0x319 [mt7921e ]\n[2.702799] pci_device_probe+0x9f/0x12a

In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: Fix detection of atomic context\n\nCurrent check for atomic context is not sufficient as\nz_erofs_decompressqueue_endio can be called under rcu lock\nfrom blk_mq_flush_plug_list(). See the stacktrace [1]\n\nIn such case we should hand off the decompression work for async\nprocessing rather than trying to do sync decompression in current\ncontext. Patch fixes the detection by checking for\nrcu_read_lock_any_held() and while at it use more appropriate\n!in_task() check than in_atomic().\n\nBackground: Historically erofs would always schedule a kworker for\ndecompression which would incur the scheduling cost regardless of\nthe context. But z_erofs_decompressqueue_endio() may not always\nbe in atomic context and we could actually benefit from doing the\ndecompression in z_erofs_decompressqueue_endio() if we are in\nthread context, for example when running with dm-verity.\nThis optimization was later added in patch [2] which has shown\nimprovement in performance benchmarks.\n\n==============================================\n[1] Problem stacktrace\n[name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291\n[name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi\n[name:core&]preempt_count: 0, expected: 0\n[name:core&]RCU nest depth: 1, expected: 0\nCPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1\nHardware name: MT6897 (DT)\nCall trace:\n dump_backtrace+0x108/0x15c\n show_stack+0x20/0x30\n dump_stack_lvl+0x6c/0x8c\n dump_stack+0x20/0x48\n __might_resched+0x1fc/0x308\n __might_sleep+0x50/0x88\n mutex_lock+0x2c/0x110\n z_erofs_decompress_queue+0x11c/0xc10\n z_erofs_decompress_kickoff+0x110/0x1a4\n z_erofs_decompressqueue_endio+0x154/0x180\n bio_endio+0x1b0/0x1d8\n __dm_io_complete+0x22c/0x280\n clone_endio+0xe4/0x280\n bio_endio+0x1b0/0x1d8\n blk_update_request+0x138/0x3a4\n blk_mq_plug_issue_direct+0xd4/0x19c\n blk_mq_flush_plug_list+0x2b0/0x354\n __blk_flush_plug+0x110/0x160\n blk_finish_plug+0x30/0x4c\n read_pages+0x2fc/0x370\n page_cache_ra_unbounded+0xa4/0x23c\n page_cache_ra_order+0x290/0x320\n do_sync_mmap_readahead+0x108/0x2c0\n filemap_fault+0x19c/0x52c\n __do_fault+0xc4/0x114\n handle_mm_fault+0x5b4/0x1168\n do_page_fault+0x338/0x4b4\n do_translation_fault+0x40/0x60\n do_mem_abort+0x60/0xc8\n el0_da+0x4c/0xe0\n el0t_64_sync_handler+0xd4/0xfc\n el0t_64_sync+0x1a0/0x1a4\n\n[2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix warning in cifs_smb3_do_mount()\n\nThis fixes the following warning reported by kernel test robot\n\n fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible\n memory leak of 'cifs_sb'

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix invalid drv_sta_pre_rcu_remove calls for non-uploaded sta\n\nAvoid potential data corruption issues caused by uninitialized driver\nprivate data structures.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: drop redundant sched job cleanup when cs is aborted\n\nOnce command submission failed due to userptr invalidation in\namdgpu_cs_submit, legacy code will perform cleanup of scheduler\njob. However, it's not needed at all, as former commit has integrated\njob cleanup stuff into amdgpu_job_free. Otherwise, because of double\nfree, a NULL pointer dereference will occur in such scenario.\n\nBug: https://gitlab.freedesktop.org/drm/amd/-/issues/2457

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix OOB and integer underflow when rx packets\n\nMake sure mwifiex_process_mgmt_packet,\nmwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet,\nmwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet\nnot out-of-bounds access the skb->data buffer.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: imx: Don't skip cleanup in remove's error path\n\nReturning early in a platform driver's remove callback is wrong. In this\ncase the dma resources are not released in the error path. this is never\nretried later and so this is a permanent leak. To fix this, only skip\nhardware disabling if waking the device fails.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: Fix function prototype mismatch for ext4_feat_ktype\n\nWith clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),\nindirect call targets are validated against the expected function\npointer prototype to make sure the call target is valid to help mitigate\nROP attacks. If they are not identical, there is a failure at run time,\nwhich manifests as either a kernel panic or thread getting killed.\n\next4_feat_ktype was setting the "release" handler to "kfree", which\ndoesn't have a matching function prototype. Add a simple wrapper\nwith the correct prototype.\n\nThis was found as a result of Clang's new -Wcast-function-type-strict\nflag, which is more sensitive than the simpler -Wcast-function-type,\nwhich only checks for type width mismatches.\n\nNote that this code is only reached when ext4 is a loadable module and\nit is being unloaded:\n\n CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698)\n ...\n RIP: 0010:kobject_put+0xbb/0x1b0\n ...\n Call Trace:\n \n ext4_exit_sysfs+0x14/0x60 [ext4]\n cleanup_module+0x67/0xedb [ext4]

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\njfs: jfs_dmap: Validate db_l2nbperpage while mounting\n\nIn jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block\nnumber inside dbFree(). db_l2nbperpage, which is the log2 number of\nblocks per page, is passed as an argument to BLKTODMAP which uses it\nfor shifting.\n\nSyzbot reported a shift out-of-bounds crash because db_l2nbperpage is\ntoo big. This happens because the large value is set without any\nvalidation in dbMount() at line 181.\n\nThus, make sure that db_l2nbperpage is correct while mounting.\n\nMax number of blocks per page = Page size / Min block size\n=> log2(Max num_block per page) = log2(Page size / Min block size)\n = log2(Page size) - log2(Min block size)\n\n=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: az6007: Fix null-ptr-deref in az6007_i2c_xfer()\n\nIn az6007_i2c_xfer, msg is controlled by user. When msg[i].buf\nis null and msg[i].len is zero, former checks on msg[i].buf would be\npassed. Malicious data finally reach az6007_i2c_xfer. If accessing\nmsg[i].buf[0] without sanity check, null ptr deref would happen.\nWe add check on msg[i].len to prevent crash.\n\nSimilar commit:\ncommit 0ed554fd769a\n("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\narm64: efi: Make efi_rt_lock a raw_spinlock\n\nRunning a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs\nthe following:\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0\n preempt_count: 2, expected: 0\n RCU nest depth: 0, expected: 0\n 3 locks held by kworker/u320:0/9:\n #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)\n #1: ffff80000861bdd0 ((work_completion)(&efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)\n #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)\n Preemption disabled at:\n efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248)\n CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1\n Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18\n Workqueue: efi_rts_wq efi_call_rts\n Call trace:\n dump_backtrace (arch/arm64/kernel/stacktrace.c:158)\n show_stack (arch/arm64/kernel/stacktrace.c:165)\n dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))\n dump_stack (lib/dump_stack.c:114)\n __might_resched (kernel/sched/core.c:10134)\n rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4))\n efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)\n [...]\n\nThis seems to come from commit ff7a167961d1 ("arm64: efi: Execute\nruntime services from a dedicated stack") which adds a spinlock. This\nspinlock is taken through:\nefi_call_rts()\n\\-efi_call_virt()\n \\-efi_call_virt_pointer()\n \\-arch_efi_call_virt_setup()\n\nMake 'efi_rt_lock' a raw_spinlock to avoid being preempted.\n\n[ardb: The EFI runtime services are called with a different set of\n translation tables, and are permitted to use the SIMD registers.\n The context switch code preserves/restores neither, and so EFI\n calls must be made with preemption disabled, rather than only\n disabling migration.]

In the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Don't balance task to its current running CPU\n\nWe've run into the case that the balancer tries to balance a migration\ndisabled task and trigger the warning in set_task_cpu() like below:\n\n ------------[ cut here ]------------\n WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240\n Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip>\n CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1\n Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021\n pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : set_task_cpu+0x188/0x240\n lr : load_balance+0x5d0/0xc60\n sp : ffff80000803bc70\n x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040\n x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001\n x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78\n x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000\n x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000\n x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530\n x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e\n x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a\n x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001\n Call trace:\n set_task_cpu+0x188/0x240\n load_balance+0x5d0/0xc60\n rebalance_domains+0x26c/0x380\n _nohz_idle_balance.isra.0+0x1e0/0x370\n run_rebalance_domains+0x6c/0x80\n __do_softirq+0x128/0x3d8\n ____do_softirq+0x18/0x24\n call_on_irq_stack+0x2c/0x38\n do_softirq_own_stack+0x24/0x3c\n __irq_exit_rcu+0xcc/0xf4\n irq_exit_rcu+0x18/0x24\n el1_interrupt+0x4c/0xe4\n el1h_64_irq_handler+0x18/0x2c\n el1h_64_irq+0x74/0x78\n arch_cpu_idle+0x18/0x4c\n default_idle_call+0x58/0x194\n do_idle+0x244/0x2b0\n cpu_startup_entry+0x30/0x3c\n secondary_start_kernel+0x14c/0x190\n __secondary_switched+0xb0/0xb4\n ---[ end trace 0000000000000000 ]---\n\nFurther investigation shows that the warning is superfluous, the migration\ndisabled task is just going to be migrated to its current running CPU.\nThis is because that on load balance if the dst_cpu is not allowed by the\ntask, we'll re-select a new_dst_cpu as a candidate. If no task can be\nbalanced to dst_cpu we'll try to balance the task to the new_dst_cpu\ninstead. In this case when the migration disabled task is not on CPU it\nonly allows to run on its current CPU, load balance will select its\ncurrent CPU as new_dst_cpu and later triggers the warning above.\n\nThe new_dst_cpu is chosen from the env->dst_grpmask. Currently it\ncontains CPUs in sched_group_span() and if we have overlapped groups it's\npossible to run into this case. This patch makes env->dst_grpmask of\ngroup_balance_mask() which exclude any CPUs from the busiest group and\nsolve the issue. For balancing in a domain with no overlapped groups\nthe behaviour keeps same as before.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies()\n\nFix a slab-out-of-bounds read that occurs in kmemdup() called from\nbrcmf_get_assoc_ies().\nThe bug could occur when assoc_info->req_len, data from a URB provided\nby a USB device, is bigger than the size of buffer which is defined as\nWL_EXTRA_BUF_MAX.\n\nAdd the size check for req_len/resp_len of assoc_info.\n\nFound by a modified version of syzkaller.\n\n[ 46.592467][ T7] ==================================================================\n[ 46.594687][ T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50\n[ 46.596572][ T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7\n[ 46.598575][ T7]\n[ 46.599157][ T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #145\n[ 46.601333][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\n[ 46.604360][ T7] Workqueue: events brcmf_fweh_event_worker\n[ 46.605943][ T7] Call Trace:\n[ 46.606584][ T7] dump_stack_lvl+0x8e/0xd1\n[ 46.607446][ T7] print_address_description.constprop.0.cold+0x93/0x334\n[ 46.608610][ T7] ? kmemdup+0x3e/0x50\n[ 46.609341][ T7] kasan_report.cold+0x79/0xd5\n[ 46.610151][ T7] ? kmemdup+0x3e/0x50\n[ 46.610796][ T7] kasan_check_range+0x14e/0x1b0\n[ 46.611691][ T7] memcpy+0x20/0x60\n[ 46.612323][ T7] kmemdup+0x3e/0x50\n[ 46.612987][ T7] brcmf_get_assoc_ies+0x967/0xf60\n[ 46.613904][ T7] ? brcmf_notify_vif_event+0x3d0/0x3d0\n[ 46.614831][ T7] ? lock_chain_count+0x20/0x20\n[ 46.615683][ T7] ? mark_lock.part.0+0xfc/0x2770\n[ 46.616552][ T7] ? lock_chain_count+0x20/0x20\n[ 46.617409][ T7] ? mark_lock.part.0+0xfc/0x2770\n[ 46.618244][ T7] ? lock_chain_count+0x20/0x20\n[ 46.619024][ T7] brcmf_bss_connect_done.constprop.0+0x241/0x2e0\n[ 46.620019][ T7] ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0\n[ 46.620818][ T7] ? __lock_acquire+0x181f/0x5790\n[ 46.621462][ T7] brcmf_notify_connect_status+0x448/0x1950\n[ 46.622134][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0\n[ 46.622736][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0\n[ 46.623390][ T7] ? find_held_lock+0x2d/0x110\n[ 46.623962][ T7] ? brcmf_fweh_event_worker+0x19f/0xc60\n[ 46.624603][ T7] ? mark_held_locks+0x9f/0xe0\n[ 46.625145][ T7] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0\n[ 46.625871][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0\n[ 46.626545][ T7] brcmf_fweh_call_event_handler.isra.0+0x90/0x100\n[ 46.627338][ T7] brcmf_fweh_event_worker+0x557/0xc60\n[ 46.627962][ T7] ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100\n[ 46.628736][ T7] ? rcu_read_lock_sched_held+0xa1/0xd0\n[ 46.629396][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0\n[ 46.629970][ T7] ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n[ 46.630649][ T7] process_one_work+0x92b/0x1460\n[ 46.631205][ T7] ? pwq_dec_nr_in_flight+0x330/0x330\n[ 46.631821][ T7] ? rwlock_bug.part.0+0x90/0x90\n[ 46.632347][ T7] worker_thread+0x95/0xe00\n[ 46.632832][ T7] ? __kthread_parkme+0x115/0x1e0\n[ 46.633393][ T7] ? process_one_work+0x1460/0x1460\n[ 46.633957][ T7] kthread+0x3a1/0x480\n[ 46.634369][ T7] ? set_kthread_struct+0x120/0x120\n[ 46.634933][ T7] ret_from_fork+0x1f/0x30\n[ 46.635431][ T7]\n[ 46.635687][ T7] Allocated by task 7:\n[ 46.636151][ T7] kasan_save_stack+0x1b/0x40\n[ 46.636628][ T7] __kasan_kmalloc+0x7c/0x90\n[ 46.637108][ T7] kmem_cache_alloc_trace+0x19e/0x330\n[ 46.637696][ T7] brcmf_cfg80211_attach+0x4a0/0x4040\n[ 46.638275][ T7] brcmf_attach+0x389/0xd40\n[ 46.638739][ T7] brcmf_usb_probe+0x12de/0x1690\n[ 46.639279][ T7] usb_probe_interface+0x2aa/0x760\n[ 46.639820][ T7] really_probe+0x205/0xb70\n[ 46.640342][ T7] __driver_probe_device+0\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: location: Free struct acpi_pld_info *pld before return false\n\nstruct acpi_pld_info *pld should be freed before the return of allocation\nfailure, to prevent memory leak, add the ACPI_FREE() to fix it.

In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid5-cache: fix null-ptr-deref for r5l_flush_stripe_to_raid()\n\nr5l_flush_stripe_to_raid() will check if the list 'flushing_ios' is\nempty, and then submit 'flush_bio', however, r5l_log_flush_endio()\nis clearing the list first and then clear the bio, which will cause\nnull-ptr-deref:\n\nT1: submit flush io\nraid5d\n handle_active_stripes\n r5l_flush_stripe_to_raid\n // list is empty\n // add 'io_end_ios' to the list\n bio_init\n submit_bio\n // io1\n\nT2: io1 is done\nr5l_log_flush_endio\n list_splice_tail_init\n // clear the list\n T3: submit new flush io\n ...\n r5l_flush_stripe_to_raid\n // list is empty\n // add 'io_end_ios' to the list\n bio_init\n bio_uninit\n // clear bio->bi_blkg\n submit_bio\n // null-ptr-deref\n\nFix this problem by clearing bio before clearing the list in\nr5l_log_flush_endio().

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211_hwsim: Fix possible NULL dereference\n\nIn a call to mac80211_hwsim_select_tx_link() the sta pointer might\nbe NULL, thus need to check that it is not NULL before accessing it.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state\n\nWhen emulating nested VM-Exit, load L1's TSC multiplier if L1's desired\nratio doesn't match the current ratio, not if the ratio L1 is using for\nL2 diverges from the default. Functionally, the end result is the same\nas KVM will run L2 with L1's multiplier if L2's multiplier is the default,\ni.e. checking that L1's multiplier is loaded is equivalent to checking if\nL2 has a non-default multiplier.\n\nHowever, the assertion that TSC scaling is exposed to L1 is flawed, as\nuserspace can trigger the WARN at will by writing the MSR and then\nupdating guest CPUID to hide the feature (modifying guest CPUID is\nallowed anytime before KVM_RUN). E.g. hacking KVM's state_test\nselftest to do\n\n vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);\n vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);\n\nafter restoring state in a new VM+vCPU yields an endless supply of:\n\n ------------[ cut here ]------------\n WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105\n nested_svm_vmexit+0x6af/0x720 [kvm_amd]\n Call Trace:\n nested_svm_exit_handled+0x102/0x1f0 [kvm_amd]\n svm_handle_exit+0xb9/0x180 [kvm_amd]\n kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]\n kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]\n ? trace_hardirqs_off+0x4d/0xa0\n __se_sys_ioctl+0x7a/0xc0\n __x64_sys_ioctl+0x21/0x30\n do_syscall_64+0x41/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nUnlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check\ninto the if-statement is wrong as KVM needs to ensure L1's multiplier is\nloaded in the above scenario. Alternatively, the WARN_ON() could simply\nbe deleted, but that would make KVM's behavior even more subtle, e.g. it's\nnot immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when\nchecking only tsc_ratio_msr.

In the Linux kernel, the following vulnerability has been resolved:\n\nublk: fail to recover device if queue setup is interrupted\n\nIn ublk_ctrl_end_recovery(), if wait_for_completion_interruptible() is\ninterrupted by signal, queues aren't setup successfully yet, so we\nhave to fail UBLK_CMD_END_USER_RECOVERY, otherwise kernel oops can be\ntriggered.

In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (pmbus_core) Fix NULL pointer dereference\n\nPass i2c_client to _pmbus_is_enabled to drop the assumption\nthat a regulator device is passed in.\n\nThis will fix the issue of a NULL pointer dereference when called from\n_pmbus_get_flags.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390/diag: fix racy access of physical cpu number in diag 9c handler\n\nWe do check for target CPU == -1, but this might change at the time we\nare going to use it. Hold the physical target CPU in a local variable to\navoid out-of-bound accesses to the cpu arrays.

In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix data-races around user->unix_inflight.\n\nuser->unix_inflight is changed under spin_lock(unix_gc_lock),\nbut too_many_unix_fds() reads it locklessly.\n\nLet's annotate the write/read accesses to user->unix_inflight.\n\nBUG: KCSAN: data-race in unix_attach_fds / unix_inflight\n\nwrite to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1:\n unix_inflight+0x157/0x180 net/unix/scm.c:66\n unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123\n unix_scm_to_skb net/unix/af_unix.c:1827 [inline]\n unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950\n unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]\n unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292\n sock_sendmsg_nosec net/socket.c:725 [inline]\n sock_sendmsg+0x148/0x160 net/socket.c:748\n ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494\n ___sys_sendmsg+0xc6/0x140 net/socket.c:2548\n __sys_sendmsg+0x94/0x140 net/socket.c:2577\n __do_sys_sendmsg net/socket.c:2586 [inline]\n __se_sys_sendmsg net/socket.c:2584 [inline]\n __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nread to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0:\n too_many_unix_fds net/unix/scm.c:101 [inline]\n unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110\n unix_scm_to_skb net/unix/af_unix.c:1827 [inline]\n unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950\n unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline]\n unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292\n sock_sendmsg_nosec net/socket.c:725 [inline]\n sock_sendmsg+0x148/0x160 net/socket.c:748\n ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494\n ___sys_sendmsg+0xc6/0x140 net/socket.c:2548\n __sys_sendmsg+0x94/0x140 net/socket.c:2577\n __do_sys_sendmsg net/socket.c:2586 [inline]\n __se_sys_sendmsg net/socket.c:2584 [inline]\n __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nvalue changed: 0x000000000000000c -> 0x000000000000000d\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7996: rely on mt76_connac2_mac_tx_rate_val\n\nIn order to fix a possible NULL pointer dereference in\nmt7996_mac_write_txwi() of vif pointer, export\nmt76_connac2_mac_tx_rate_val utility routine and reuse it\nin mt7996 driver.

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

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: wraparound mbox producer index\n\nDriver is not handling the wraparound of the mbox producer index correctly.\nCurrently the wraparound happens once u32 max is reached.\n\nBit 31 of the producer index register is special and should be set\nonly once for the first command. Because the producer index overflow\nsetting bit31 after a long time, FW goes to initialization sequence\nand this causes FW hang.\n\nFix is to wraparound the mbox producer index once it reaches u16 max.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: fix percpu counter block leak on error path when creating new netns\n\nHere is the stack where we allocate percpu counter block:\n\n +-< __alloc_percpu\n +-< xt_percpu_counter_alloc\n +-< find_check_entry # {arp,ip,ip6}_tables.c\n +-< translate_table\n\nAnd it can be leaked on this code path:\n\n +-> ip6t_register_table\n +-> translate_table # allocates percpu counter block\n +-> xt_register_table # fails\n\nthere is no freeing of the counter block on xt_register_table fail.\nNote: xt_percpu_counter_free should be called to free it like we do in\ndo_replace through cleanup_entry helper (or in __ip6t_unregister_table).\n\nProbability of hitting this error path is low AFAICS (xt_register_table\ncan only return ENOMEM here, as it is not replacing anything, as we are\ncreating new netns, and it is hard to imagine that all previous\nallocations succeeded and after that one in xt_register_table failed).\nBut it's worth fixing even the rare leak.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nraw: Fix NULL deref in raw_get_next().\n\nDae R. Jeong reported a NULL deref in raw_get_next() [0].\n\nIt seems that the repro was running these sequences in parallel so\nthat one thread was iterating on a socket that was being freed in\nanother netns.\n\n unshare(0x40060200)\n r0 = syz_open_procfs(0x0, &(0x7f0000002080)='net/raw\\x00')\n socket$inet_icmp_raw(0x2, 0x3, 0x1)\n pread64(r0, &(0x7f0000000000)=""/10, 0xa, 0x10000000007f)\n\nAfter commit 0daf07e52709 ("raw: convert raw sockets to RCU"), we\nuse RCU and hlist_nulls_for_each_entry() to iterate over SOCK_RAW\nsockets. However, we should use spinlock for slow paths to avoid\nthe NULL deref.\n\nAlso, SOCK_RAW does not use SLAB_TYPESAFE_BY_RCU, and the slab object\nis not reused during iteration in the grace period. In fact, the\nlockless readers do not check the nulls marker with get_nulls_value().\nSo, SOCK_RAW should use hlist instead of hlist_nulls.\n\nInstead of adding an unnecessary barrier by sk_nulls_for_each_rcu(),\nlet's convert hlist_nulls to hlist and use sk_for_each_rcu() for\nfast paths and sk_for_each() and spinlock for /proc/net/raw.\n\n[0]:\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\nCPU: 2 PID: 20952 Comm: syz-executor.0 Not tainted 6.2.0-g048ec869bafd-dirty #7\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\nRIP: 0010:read_pnet include/net/net_namespace.h:383 [inline]\nRIP: 0010:sock_net include/net/sock.h:649 [inline]\nRIP: 0010:raw_get_next net/ipv4/raw.c:974 [inline]\nRIP: 0010:raw_get_idx net/ipv4/raw.c:986 [inline]\nRIP: 0010:raw_seq_start+0x431/0x800 net/ipv4/raw.c:995\nCode: ef e8 33 3d 94 f7 49 8b 6d 00 4c 89 ef e8 b7 65 5f f7 49 89 ed 49 83 c5 98 0f 84 9a 00 00 00 48 83 c5 c8 48 89 e8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 ef e8 00 3d 94 f7 4c 8b 7d 00 48 89 ef\nRSP: 0018:ffffc9001154f9b0 EFLAGS: 00010206\nRAX: 0000000000000005 RBX: 1ffff1100302c8fd RCX: 0000000000000000\nRDX: 0000000000000028 RSI: ffffc9001154f988 RDI: ffffc9000f77a338\nRBP: 0000000000000029 R08: ffffffff8a50ffb4 R09: fffffbfff24b6bd9\nR10: fffffbfff24b6bd9 R11: 0000000000000000 R12: ffff88801db73b78\nR13: fffffffffffffff9 R14: dffffc0000000000 R15: 0000000000000030\nFS: 00007f843ae8e700(0000) GS:ffff888063700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055bb9614b35f CR3: 000000003c672000 CR4: 00000000003506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n seq_read_iter+0x4c6/0x10f0 fs/seq_file.c:225\n seq_read+0x224/0x320 fs/seq_file.c:162\n pde_read fs/proc/inode.c:316 [inline]\n proc_reg_read+0x23f/0x330 fs/proc/inode.c:328\n vfs_read+0x31e/0xd30 fs/read_write.c:468\n ksys_pread64 fs/read_write.c:665 [inline]\n __do_sys_pread64 fs/read_write.c:675 [inline]\n __se_sys_pread64 fs/read_write.c:672 [inline]\n __x64_sys_pread64+0x1e9/0x280 fs/read_write.c:672\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x478d29\nCode: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f843ae8dbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000011\nRAX: ffffffffffffffda RBX: 0000000000791408 RCX: 0000000000478d29\nRDX: 000000000000000a RSI: 0000000020000000 RDI: 0000000000000003\nRBP: 00000000f477909a R08: 0000000000000000 R09: 0000000000000000\nR10: 000010000000007f R11: 0000000000000246 R12: 0000000000791740\nR13: 0000000000791414 R14: 0000000000791408 R15: 00007ffc2eb48a50\n \nModules linked in:\n---[ end trace 0000000000000000 ]---\nRIP: 0010\n---truncated---

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

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: qcom: Fix potential memory leak\n\nFunction dwc3_qcom_probe() allocates memory for resource structure\nwhich is pointed by parent_res pointer. This memory is not\nfreed. This leads to memory leak. Use stack memory to prevent\nmemory leak.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init\n\nThe line cards array is not freed in the error path of\nmlxsw_m_linecards_init(), which can lead to a memory leak. Fix by\nfreeing the array in the error path, thereby making the error path\nidentical to mlxsw_m_linecards_fini().

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini\n\nThe gmc.ecc_irq is enabled by firmware per IFWI setting,\nand the host driver is not privileged to enable/disable\nthe interrupt. So, it is meaningless to use the amdgpu_irq_put\nfunction in gmc_v10_0_hw_fini, which also leads to the call\ntrace.\n\n[ 82.340264] Call Trace:\n[ 82.340265] \n[ 82.340269] gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu]\n[ 82.340447] gmc_v10_0_suspend+0xe/0x20 [amdgpu]\n[ 82.340623] amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu]\n[ 82.340789] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]\n[ 82.340955] amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu]\n[ 82.341122] amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu]\n[ 82.341359] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]\n[ 82.341529] process_one_work+0x21d/0x3f0\n[ 82.341535] worker_thread+0x1fa/0x3c0\n[ 82.341538] ? process_one_work+0x3f0/0x3f0\n[ 82.341540] kthread+0xff/0x130\n[ 82.341544] ? kthread_complete_and_exit+0x20/0x20\n[ 82.341547] ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix nexthop hash size\n\nThe nexthop code expects a 31 bit hash, such as what is returned by\nfib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash\nreturned by skb_get_hash() can lead to problems related to the fact that\n'int hash' is a negative number when the MSB is set.\n\nIn the case of hash threshold nexthop groups, nexthop_select_path_hthr()\nwill disproportionately select the first nexthop group entry. In the case\nof resilient nexthop groups, nexthop_select_path_res() may do an out of\nbounds access in nh_buckets[], for example:\n hash = -912054133\n num_nh_buckets = 2\n bucket_index = 65535\n\nwhich leads to the following panic:\n\nBUG: unable to handle page fault for address: ffffc900025910c8\nPGD 100000067 P4D 100000067 PUD 10026b067 PMD 0\nOops: 0002 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nWorkqueue: ipv6_addrconf addrconf_dad_work\nRIP: 0010:nexthop_select_path+0x197/0xbf0\nCode: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85\nRSP: 0018:ffff88810c36f260 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8\nRBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219\nR10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0\nR13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900\nFS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0\nPKRU: 55555554\nCall Trace:\n \n ? __die+0x23/0x70\n ? page_fault_oops+0x1ee/0x5c0\n ? __pfx_is_prefetch.constprop.0+0x10/0x10\n ? __pfx_page_fault_oops+0x10/0x10\n ? search_bpf_extables+0xfe/0x1c0\n ? fixup_exception+0x3b/0x470\n ? exc_page_fault+0xf6/0x110\n ? asm_exc_page_fault+0x26/0x30\n ? nexthop_select_path+0x197/0xbf0\n ? nexthop_select_path+0x197/0xbf0\n ? lock_is_held_type+0xe7/0x140\n vxlan_xmit+0x5b2/0x2340\n ? __lock_acquire+0x92b/0x3370\n ? __pfx_vxlan_xmit+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_register_lock_class+0x10/0x10\n ? skb_network_protocol+0xce/0x2d0\n ? dev_hard_start_xmit+0xca/0x350\n ? __pfx_vxlan_xmit+0x10/0x10\n dev_hard_start_xmit+0xca/0x350\n __dev_queue_xmit+0x513/0x1e20\n ? __pfx___dev_queue_xmit+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? mark_held_locks+0x44/0x90\n ? skb_push+0x4c/0x80\n ? eth_header+0x81/0xe0\n ? __pfx_eth_header+0x10/0x10\n ? neigh_resolve_output+0x215/0x310\n ? ip6_finish_output2+0x2ba/0xc90\n ip6_finish_output2+0x2ba/0xc90\n ? lock_release+0x236/0x3e0\n ? ip6_mtu+0xbb/0x240\n ? __pfx_ip6_finish_output2+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? lock_is_held_type+0xe7/0x140\n ip6_finish_output+0x1ee/0x780\n ip6_output+0x138/0x460\n ? __pfx_ip6_output+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_ip6_finish_output+0x10/0x10\n NF_HOOK.constprop.0+0xc0/0x420\n ? __pfx_NF_HOOK.constprop.0+0x10/0x10\n ? ndisc_send_skb+0x2c0/0x960\n ? __pfx_lock_release+0x10/0x10\n ? __local_bh_enable_ip+0x93/0x110\n ? lock_is_held_type+0xe7/0x140\n ndisc_send_skb+0x4be/0x960\n ? __pfx_ndisc_send_skb+0x10/0x10\n ? mark_held_locks+0x65/0x90\n ? find_held_lock+0x83/0xa0\n ndisc_send_ns+0xb0/0x110\n ? __pfx_ndisc_send_ns+0x10/0x10\n addrconf_dad_work+0x631/0x8e0\n ? lock_acquire+0x180/0x3f0\n ? __pfx_addrconf_dad_work+0x10/0x10\n ? mark_held_locks+0x24/0x90\n process_one_work+0x582/0x9c0\n ? __pfx_process_one_work+0x10/0x10\n ? __pfx_do_raw_spin_lock+0x10/0x10\n ? mark_held_locks+0x24/0x90\n worker_thread+0x93/0x630\n ? __kthread_parkme+0xdc/0x100\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x1a5/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains\n\nof_irq_find_parent() returns a node pointer with refcount incremented,\nWe should use of_node_put() on it when not needed anymore.\nAdd missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix memory leaks in error path\n\nThe memory allocated by vxlan_vnigroup_init() is not freed in the error\npath, leading to memory leaks [1]. Fix by calling\nvxlan_vnigroup_uninit() in the error path.\n\nThe leaks can be reproduced by annotating gro_cells_init() with\nALLOW_ERROR_INJECTION() and then running:\n\n # echo "100" > /sys/kernel/debug/fail_function/probability\n # echo "1" > /sys/kernel/debug/fail_function/times\n # echo "gro_cells_init" > /sys/kernel/debug/fail_function/inject\n # printf %#x -12 > /sys/kernel/debug/fail_function/gro_cells_init/retval\n # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter\n RTNETLINK answers: Cannot allocate memory\n\n[1]\nunreferenced object 0xffff88810db84a00 (size 512):\n comm "ip", pid 330, jiffies 4295010045 (age 66.016s)\n hex dump (first 32 bytes):\n f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v.............\n 03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ....H...........\n backtrace:\n [] kmalloc_trace+0x2a/0x60\n [] vxlan_vnigroup_init+0x4c/0x160\n [] vxlan_init+0x1ae/0x280\n [] register_netdevice+0x57a/0x16d0\n [] __vxlan_dev_create+0x7c7/0xa50\n [] vxlan_newlink+0xd6/0x130\n [] __rtnl_newlink+0x112b/0x18a0\n [] rtnl_newlink+0x6c/0xa0\n [] rtnetlink_rcv_msg+0x43f/0xd40\n [] netlink_rcv_skb+0x170/0x440\n [] netlink_unicast+0x53f/0x810\n [] netlink_sendmsg+0x958/0xe70\n [] ____sys_sendmsg+0x78f/0xa90\n [] ___sys_sendmsg+0x13a/0x1e0\n [] __sys_sendmsg+0x11c/0x1f0\n [] do_syscall_64+0x38/0x80\nunreferenced object 0xffff88810e76d5f8 (size 192):\n comm "ip", pid 330, jiffies 4295010045 (age 66.016s)\n hex dump (first 32 bytes):\n 04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00 ..........O.....\n 08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff ..v.......v.....\n backtrace:\n [] __kmalloc_node+0x4e/0x90\n [] kvmalloc_node+0xa6/0x1f0\n [] bucket_table_alloc.isra.0+0x83/0x460\n [] rhashtable_init+0x43b/0x7c0\n [] vxlan_vnigroup_init+0x6c/0x160\n [] vxlan_init+0x1ae/0x280\n [] register_netdevice+0x57a/0x16d0\n [] __vxlan_dev_create+0x7c7/0xa50\n [] vxlan_newlink+0xd6/0x130\n [] __rtnl_newlink+0x112b/0x18a0\n [] rtnl_newlink+0x6c/0xa0\n [] rtnetlink_rcv_msg+0x43f/0xd40\n [] netlink_rcv_skb+0x170/0x440\n [] netlink_unicast+0x53f/0x810\n [] netlink_sendmsg+0x958/0xe70\n [] ____sys_sendmsg+0x78f/0xa90

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6/addrconf: fix a potential refcount underflow for idev\n\nNow in addrconf_mod_rs_timer(), reference idev depends on whether\nrs_timer is not pending. Then modify rs_timer timeout.\n\nThere is a time gap in [1], during which if the pending rs_timer\nbecomes not pending. It will miss to hold idev, but the rs_timer\nis activated. Thus rs_timer callback function addrconf_rs_timer()\nwill be executed and put idev later without holding idev. A refcount\nunderflow issue for idev can be caused by this.\n\n\tif (!timer_pending(&idev->rs_timer))\n\t\tin6_dev_hold(idev);\n\t\t <--------------[1]\n\tmod_timer(&idev->rs_timer, jiffies + when);\n\nTo fix the issue, hold idev if mod_timer() return 0.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix race on port output\n\nassume the following setup on a single machine:\n1. An openvswitch instance with one bridge and default flows\n2. two network namespaces "server" and "client"\n3. two ovs interfaces "server" and "client" on the bridge\n4. for each ovs interface a veth pair with a matching name and 32 rx and\n tx queues\n5. move the ends of the veth pairs to the respective network namespaces\n6. assign ip addresses to each of the veth ends in the namespaces (needs\n to be the same subnet)\n7. start some http server on the server network namespace\n8. test if a client in the client namespace can reach the http server\n\nwhen following the actions below the host has a chance of getting a cpu\nstuck in a infinite loop:\n1. send a large amount of parallel requests to the http server (around\n 3000 curls should work)\n2. in parallel delete the network namespace (do not delete interfaces or\n stop the server, just kill the namespace)\n\nthere is a low chance that this will cause the below kernel cpu stuck\nmessage. If this does not happen just retry.\nBelow there is also the output of bpftrace for the functions mentioned\nin the output.\n\nThe series of events happening here is:\n1. the network namespace is deleted calling\n `unregister_netdevice_many_notify` somewhere in the process\n2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and\n then runs `synchronize_net`\n3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`\n4. this is then handled by `dp_device_event` which calls\n `ovs_netdev_detach_dev` (if a vport is found, which is the case for\n the veth interface attached to ovs)\n5. this removes the rx_handlers of the device but does not prevent\n packages to be sent to the device\n6. `dp_device_event` then queues the vport deletion to work in\n background as a ovs_lock is needed that we do not hold in the\n unregistration path\n7. `unregister_netdevice_many_notify` continues to call\n `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0\n8. port deletion continues (but details are not relevant for this issue)\n9. at some future point the background task deletes the vport\n\nIf after 7. but before 9. a packet is send to the ovs vport (which is\nnot deleted at this point in time) which forwards it to the\n`dev_queue_xmit` flow even though the device is unregistering.\nIn `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is\na while loop (if the packet has a rx_queue recorded) that is infinite if\n`dev->real_num_tx_queues` is zero.\n\nTo prevent this from happening we update `do_output` to handle devices\nwithout carrier the same as if the device is not found (which would\nbe the code path after 9. is done).\n\nAdditionally we now produce a warning in `skb_tx_hash` if we will hit\nthe infinite loop.\n\nbpftrace (first word is function name):\n\n__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1\nnetdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1\ndp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\ndp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2\novs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2\nnetdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2\nsynchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024\nnetdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2\ndp_\n---truncated---

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\narm64/sme: Set new vector length before reallocating\n\nAs part of fixing the allocation of the buffer for SVE state when changing\nSME vector length we introduced an immediate reallocation of the SVE state,\nthis is also done when changing the SVE vector length for consistency.\nUnfortunately this reallocation is done prior to writing the new vector\nlength to the task struct, meaning the allocation is done with the old\nvector length and can lead to memory corruption due to an undersized buffer\nbeing used.\n\nMove the update of the vector length before the allocation to ensure that\nthe new vector length is taken into account.\n\nFor some reason this isn't triggering any problems when running tests on\nthe arm64 fixes branch (even after repeated tries) but is triggering\nissues very often after merge into mainline.

In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Avoid undefined behavior: applying zero offset to null pointer\n\nACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e\n\nBefore this change we see the following UBSAN stack trace in Fuchsia:\n\n #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 +0x233302\n #1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 +0x3d77f\n #1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 +0x3d77f\n #1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 +0x3d77f\n #2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 +0x4196d\n #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 +0x4150d\n #4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 +0x233302\n #5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 +0x262369\n #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 +0x2b7fac\n #7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 +0x2c64d2\n #8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 +0x22a052\n #9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 +0x293dd8\n #10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 +0x2a9e98\n #11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 +0x2931ac\n #12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 +0x2fc40d\n #13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 +0xed603\n\nAdd a simple check that avoids incrementing a pointer by zero, but\notherwise behaves as before. Note that our findings are against ACPICA\n20221020, but the same code exists on master.

In the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf/dma-resv: Stop leaking on krealloc() failure\n\nCurrently dma_resv_get_fences() will leak the previously\nallocated array if the fence iteration got restarted and\nthe krealloc_array() fails.\n\nFree the old array by hand, and make sure we still clear\nthe returned *fences so the caller won't end up accessing\nfreed memory. Some (but not all) of the callers of\ndma_resv_get_fences() seem to still trawl through the\narray even when dma_resv_get_fences() failed. And let's\nzero out *num_fences as well for good measure.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: Avoid NULL pointer access during management transmit cleanup\n\nCurrently 'ar' reference is not added in skb_cb.\nThough this is generally not used during transmit completion\ncallbacks, on interface removal the remaining idr cleanup callback\nuses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them\nduring transmit call for proper usage to avoid NULL pointer dereference.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix zswap writeback race condition\n\nThe zswap writeback mechanism can cause a race condition resulting in\nmemory corruption, where a swapped out page gets swapped in with data that\nwas written to a different page.\n\nThe race unfolds like this:\n1. a page with data A and swap offset X is stored in zswap\n2. page A is removed off the LRU by zpool driver for writeback in\n zswap-shrink work, data for A is mapped by zpool driver\n3. user space program faults and invalidates page entry A, offset X is\n considered free\n4. kswapd stores page B at offset X in zswap (zswap could also be\n full, if so, page B would then be IOed to X, then skip step 5.)\n5. entry A is replaced by B in tree->rbroot, this doesn't affect the\n local reference held by zswap-shrink work\n6. zswap-shrink work writes back A at X, and frees zswap entry A\n7. swapin of slot X brings A in memory instead of B\n\nThe fix:\nOnce the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW),\nzswap-shrink work just checks that the local zswap_entry reference is\nstill the same as the one in the tree. If it's not the same it means that\nit's either been invalidated or replaced, in both cases the writeback is\naborted because the local entry contains stale data.\n\nReproducer:\nI originally found this by running `stress` overnight to validate my work\non the zswap writeback mechanism, it manifested after hours on my test\nmachine. The key to make it happen is having zswap writebacks, so\nwhatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do\nthe trick.\n\nIn order to reproduce this faster on a vm, I setup a system with ~100M of\navailable memory and a 500M swap file, then running `stress --vm 1\n--vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens\nof minutes. One can speed things up even more by swinging\n/sys/module/zswap/parameters/max_pool_percent up and down between, say, 20\nand 1; this makes it reproduce in tens of seconds. It's crucial to set\n`--vm-stride` to something other than 4096 otherwise `stress` won't\nrealize that memory has been corrupted because all pages would have the\nsame data.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: hi846: fix usage of pm_runtime_get_if_in_use()\n\npm_runtime_get_if_in_use() does not only return nonzero values when\nthe device is in use, it can return a negative errno too.\n\nAnd especially during resuming from system suspend, when runtime pm\nis not yet up again, -EAGAIN is being returned, so the subsequent\npm_runtime_put() call results in a refcount underflow.\n\nFix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use().

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250: Reinit port->pm on port specific driver unbind\n\nWhen we unbind a serial port hardware specific 8250 driver, the generic\nserial8250 driver takes over the port. After that we see an oops about 10\nseconds later. This can produce the following at least on some TI SoCs:\n\nUnhandled fault: imprecise external abort (0x1406)\nInternal error: : 1406 [#1] SMP ARM\n\nTurns out that we may still have the serial port hardware specific driver\nport->pm in use, and serial8250_pm() tries to call it after the port\nspecific driver is gone:\n\nserial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]\nuart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]\nuart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c\n__tty_hangup.part.0 from disassociate_ctty+0x154/0x20c\ndisassociate_ctty from do_exit+0x744/0xaac\ndo_exit from do_group_exit+0x40/0x8c\ndo_group_exit from __wake_up_parent+0x0/0x1c\n\nLet's fix the issue by calling serial8250_set_defaults() in\nserial8250_unregister_port(). This will set the port back to using\nthe serial8250 default functions, and sets the port->pm to point to\nserial8250_pm.

No description is available for this CVE.

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

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

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nvfio/type1: prevent underflow of locked_vm via exec()\n\nWhen a vfio container is preserved across exec, the task does not change,\nbut it gets a new mm with locked_vm=0, and loses the count from existing\ndma mappings. If the user later unmaps a dma mapping, locked_vm underflows\nto a large unsigned value, and a subsequent dma map request fails with\nENOMEM in __account_locked_vm.\n\nTo avoid underflow, grab and save the mm at the time a dma is mapped.\nUse that mm when adjusting locked_vm, rather than re-acquiring the saved\ntask's mm, which may have changed. If the saved mm is dead, do nothing.\n\nlocked_vm is incremented for existing mappings in a subsequent patch.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/resctrl: Clear staged_config[] before and after it is used\n\nAs a temporary storage, staged_config[] in rdt_domain should be cleared\nbefore and after it is used. The stale value in staged_config[] could\ncause an MSR access error.\n\nHere is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3\nCache (MBA should be disabled if the number of CLOSIDs for MB is less than\n16.) :\n mount -t resctrl resctrl -o cdp /sys/fs/resctrl\n mkdir /sys/fs/resctrl/p{1..7}\n umount /sys/fs/resctrl/\n mount -t resctrl resctrl /sys/fs/resctrl\n mkdir /sys/fs/resctrl/p{1..8}\n\nAn error occurs when creating resource group named p8:\n unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60)\n Call Trace:\n \n __flush_smp_call_function_queue+0x11d/0x170\n __sysvec_call_function+0x24/0xd0\n sysvec_call_function+0x89/0xc0\n \n \n asm_sysvec_call_function+0x16/0x20\n\nWhen creating a new resource control group, hardware will be configured\nby the following process:\n rdtgroup_mkdir()\n rdtgroup_mkdir_ctrl_mon()\n rdtgroup_init_alloc()\n resctrl_arch_update_domains()\n\nresctrl_arch_update_domains() iterates and updates all resctrl_conf_type\nwhose have_new_ctrl is true. Since staged_config[] holds the same values as\nwhen CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA\nconfigurations. When group p8 is created, get_config_index() called in\nresctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for\nCDP_CODE and CDP_DATA, which will be translated to an invalid register -\n0xca0 in this scenario.\n\nFix it by clearing staged_config[] before and after it is used.\n\n[reinette: re-order commit tags]

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: ucsi_acpi: Increase the command completion timeout\n\nCommit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command\ncompletion timeout value") increased the timeout from 5 seconds\nto 60 seconds due to issues related to alternate mode discovery.\n\nAfter the alternate mode discovery switch to polled mode\nthe timeout was reduced, but instead of being set back to\n5 seconds it was reduced to 1 second.\n\nThis is causing problems when using a Lenovo ThinkPad X1 yoga gen7\nconnected over Type-C to a LG 27UL850-W (charging DP over Type-C).\n\nWhen the monitor is already connected at boot the following error\nis logged: "PPM init failed (-110)", /sys/class/typec is empty and\non unplugging the NULL pointer deref fixed earlier in this series\nhappens.\n\nWhen the monitor is connected after boot the following error\nis logged instead: "GET_CONNECTOR_STATUS failed (-110)".\n\nSetting the timeout back to 5 seconds fixes both cases.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix null pointer dereference in tracing_err_log_open()\n\nFix an issue in function 'tracing_err_log_open'.\nThe function doesn't call 'seq_open' if the file is opened only with\nwrite permissions, which results in 'file->private_data' being left as null.\nIf we then use 'lseek' on that opened file, 'seq_lseek' dereferences\n'file->private_data' in 'mutex_lock(&m->lock)', resulting in a kernel panic.\nWriting to this node requires root privileges, therefore this bug\nhas very little security impact.\n\nTracefs node: /sys/kernel/tracing/error_log\n\nExample Kernel panic:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000038\nCall trace:\n mutex_lock+0x30/0x110\n seq_lseek+0x34/0xb8\n __arm64_sys_lseek+0x6c/0xb8\n invoke_syscall+0x58/0x13c\n el0_svc_common+0xc4/0x10c\n do_el0_svc+0x24/0x98\n el0_svc+0x24/0x88\n el0t_64_sync_handler+0x84/0xe4\n el0t_64_sync+0x1b4/0x1b8\nCode: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02)\n---[ end trace 561d1b49c12cf8a5 ]---\nKernel panic - not syncing: Oops: Fatal exception

In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: bq25890: Fix external_power_changed race\n\nbq25890_charger_external_power_changed() dereferences bq->charger,\nwhich gets sets in bq25890_power_supply_init() like this:\n\n bq->charger = devm_power_supply_register(bq->dev, &bq->desc, &psy_cfg);\n\nAs soon as devm_power_supply_register() has called device_add()\nthe external_power_changed callback can get called. So there is a window\nwhere bq25890_charger_external_power_changed() may get called while\nbq->charger has not been set yet leading to a NULL pointer dereference.\n\nThis race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f\nwhen the cht_wcove_pwrsrc (extcon) power_supply is done with detecting\nthe connected charger-type which happens to exactly hit the small window:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000018\n \n RIP: 0010:__power_supply_is_supplied_by+0xb/0xb0\n \n Call Trace:\n \n __power_supply_get_supplier_property+0x19/0x50\n class_for_each_device+0xb1/0xe0\n power_supply_get_property_from_supplier+0x2e/0x50\n bq25890_charger_external_power_changed+0x38/0x1b0 [bq25890_charger]\n __power_supply_changed_work+0x30/0x40\n class_for_each_device+0xb1/0xe0\n power_supply_changed_work+0x5f/0xe0\n \n\nFixing this is easy. The external_power_changed callback gets passed\nthe power_supply which will eventually get stored in bq->charger,\nso bq25890_charger_external_power_changed() can simply directly use\nthe passed in psy argument which is always valid.

In the Linux kernel, the following vulnerability has been resolved:\n\nudf: Fix uninitialized array access for some pathnames\n\nFor filenames that begin with . and are between 2 and 5 characters long,\nUDF charset conversion code would read uninitialized memory in the\noutput buffer. The only practical impact is that the name may be prepended a\n"unification hash" when it is not actually needed but still it is good\nto fix this.

In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe\n\nof_irq_find_parent() returns a node pointer with refcount incremented,\nWe should use of_node_put() on it when not needed anymore.\nAdd missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: don't hold ni_lock when calling truncate_setsize()\n\nsyzbot is reporting hung task at do_user_addr_fault() [1], for there is\na silent deadlock between PG_locked bit and ni_lock lock.\n\nSince filemap_update_page() calls filemap_read_folio() after calling\nfolio_trylock() which will set PG_locked bit, ntfs_truncate() must not\ncall truncate_setsize() which will wait for PG_locked bit to be cleared\nwhen holding ni_lock lock.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: Fix use after free for wext\n\nKey information in wext.connect is not reset on (re)connect and can hold\ndata from a previous connection.\n\nReset key data to avoid that drivers or mac80211 incorrectly detect a\nWEP connection request and access the freed or already reused memory.\n\nAdditionally optimize cfg80211_sme_connect() and avoid an useless\nschedule of conn_work.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: prevent soft lockup while flush writes\n\nCurrently, there is no limit for raid1/raid10 plugged bio. While flushing\nwrites, raid1 has cond_resched() while raid10 doesn't, and too many\nwrites can cause soft lockup.\n\nFollow up soft lockup can be triggered easily with writeback test for\nraid10 with ramdisks:\n\nwatchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]\nCall Trace:\n \n call_rcu+0x16/0x20\n put_object+0x41/0x80\n __delete_object+0x50/0x90\n delete_object_full+0x2b/0x40\n kmemleak_free+0x46/0xa0\n slab_free_freelist_hook.constprop.0+0xed/0x1a0\n kmem_cache_free+0xfd/0x300\n mempool_free_slab+0x1f/0x30\n mempool_free+0x3a/0x100\n bio_free+0x59/0x80\n bio_put+0xcf/0x2c0\n free_r10bio+0xbf/0xf0\n raid_end_bio_io+0x78/0xb0\n one_write_done+0x8a/0xa0\n raid10_end_write_request+0x1b4/0x430\n bio_endio+0x175/0x320\n brd_submit_bio+0x3b9/0x9b7 [brd]\n __submit_bio+0x69/0xe0\n submit_bio_noacct_nocheck+0x1e6/0x5a0\n submit_bio_noacct+0x38c/0x7e0\n flush_pending_writes+0xf0/0x240\n raid10d+0xac/0x1ed0\n\nFix the problem by adding cond_resched() to raid10 like what raid1 did.\n\nNote that unlimited plugged bio still need to be optimized, for example,\nin the case of lots of dirty pages writeback, this will take lots of\nmemory and io will spend a long time in plug, hence io latency is bad.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Pointer may be dereferenced\n\nKlocwork tool reported pointer 'rport' returned from call to function\nfc_bsg_to_rport() may be NULL and will be dereferenced.\n\nAdd a fix to validate rport before dereferencing.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid deadlock in fs reclaim with page writeback\n\nExt4 has a filesystem wide lock protecting ext4_writepages() calls to\navoid races with switching of journalled data flag or inode format. This\nlock can however cause a deadlock like:\n\nCPU0 CPU1\n\next4_writepages()\n percpu_down_read(sbi->s_writepages_rwsem);\n ext4_change_inode_journal_flag()\n percpu_down_write(sbi->s_writepages_rwsem);\n - blocks, all readers block from now on\n ext4_do_writepages()\n ext4_init_io_end()\n kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)\n fs_reclaim frees dentry...\n dentry_unlink_inode()\n iput() - last ref =>\n iput_final() - inode dirty =>\n write_inode_now()...\n ext4_writepages() tries to acquire sbi->s_writepages_rwsem\n and blocks forever\n\nMake sure we cannot recurse into filesystem reclaim from writeback code\nto avoid the deadlock.

In the Linux kernel, the following vulnerability has been resolved:\n\nigb: Fix igb_down hung on surprise removal\n\nIn a setup where a Thunderbolt hub connects to Ethernet and a display\nthrough USB Type-C, users may experience a hung task timeout when they\nremove the cable between the PC and the Thunderbolt hub.\nThis is because the igb_down function is called multiple times when\nthe Thunderbolt hub is unplugged. For example, the igb_io_error_detected\ntriggers the first call, and the igb_remove triggers the second call.\nThe second call to igb_down will block at napi_synchronize.\nHere's the call trace:\n __schedule+0x3b0/0xddb\n ? __mod_timer+0x164/0x5d3\n schedule+0x44/0xa8\n schedule_timeout+0xb2/0x2a4\n ? run_local_timers+0x4e/0x4e\n msleep+0x31/0x38\n igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]\n __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]\n igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]\n __dev_close_many+0x95/0xec\n dev_close_many+0x6e/0x103\n unregister_netdevice_many+0x105/0x5b1\n unregister_netdevice_queue+0xc2/0x10d\n unregister_netdev+0x1c/0x23\n igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]\n pci_device_remove+0x3f/0x9c\n device_release_driver_internal+0xfe/0x1b4\n pci_stop_bus_device+0x5b/0x7f\n pci_stop_bus_device+0x30/0x7f\n pci_stop_bus_device+0x30/0x7f\n pci_stop_and_remove_bus_device+0x12/0x19\n pciehp_unconfigure_device+0x76/0xe9\n pciehp_disable_slot+0x6e/0x131\n pciehp_handle_presence_or_link_change+0x7a/0x3f7\n pciehp_ist+0xbe/0x194\n irq_thread_fn+0x22/0x4d\n ? irq_thread+0x1fd/0x1fd\n irq_thread+0x17b/0x1fd\n ? irq_forced_thread_fn+0x5f/0x5f\n kthread+0x142/0x153\n ? __irq_get_irqchip_state+0x46/0x46\n ? kthread_associate_blkcg+0x71/0x71\n ret_from_fork+0x1f/0x30\n\nIn this case, igb_io_error_detected detaches the network interface\nand requests a PCIE slot reset, however, the PCIE reset callback is\nnot being invoked and thus the Ethernet connection breaks down.\nAs the PCIE error in this case is a non-fatal one, requesting a\nslot reset can be avoided.\nThis patch fixes the task hung issue and preserves Ethernet\nconnection by ignoring non-fatal PCIE errors.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix UAF of alloc->vma in race with munmap()\n\nIn commit 720c24192404 ("ANDROID: binder: change down_write to\ndown_read") binder assumed the mmap read lock is sufficient to protect\nalloc->vma inside binder_update_page_range(). This used to be accurate\nuntil commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in\nmunmap"), which now downgrades the mmap_lock after detaching the vma\nfrom the rbtree in munmap(). Then it proceeds to teardown and free the\nvma with only the read lock held.\n\nThis means that accesses to alloc->vma in binder_update_page_range() now\nwill race with vm_area_free() in munmap() and can cause a UAF as shown\nin the following KASAN trace:\n\n ==================================================================\n BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0\n Read of size 8 at addr ffff16204ad00600 by task server/558\n\n CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1\n Hardware name: linux,dummy-virt (DT)\n Call trace:\n dump_backtrace+0x0/0x2a0\n show_stack+0x18/0x2c\n dump_stack+0xf8/0x164\n print_address_description.constprop.0+0x9c/0x538\n kasan_report+0x120/0x200\n __asan_load8+0xa0/0xc4\n vm_insert_page+0x7c/0x1f0\n binder_update_page_range+0x278/0x50c\n binder_alloc_new_buf+0x3f0/0xba0\n binder_transaction+0x64c/0x3040\n binder_thread_write+0x924/0x2020\n binder_ioctl+0x1610/0x2e5c\n __arm64_sys_ioctl+0xd4/0x120\n el0_svc_common.constprop.0+0xac/0x270\n do_el0_svc+0x38/0xa0\n el0_svc+0x1c/0x2c\n el0_sync_handler+0xe8/0x114\n el0_sync+0x180/0x1c0\n\n Allocated by task 559:\n kasan_save_stack+0x38/0x6c\n __kasan_kmalloc.constprop.0+0xe4/0xf0\n kasan_slab_alloc+0x18/0x2c\n kmem_cache_alloc+0x1b0/0x2d0\n vm_area_alloc+0x28/0x94\n mmap_region+0x378/0x920\n do_mmap+0x3f0/0x600\n vm_mmap_pgoff+0x150/0x17c\n ksys_mmap_pgoff+0x284/0x2dc\n __arm64_sys_mmap+0x84/0xa4\n el0_svc_common.constprop.0+0xac/0x270\n do_el0_svc+0x38/0xa0\n el0_svc+0x1c/0x2c\n el0_sync_handler+0xe8/0x114\n el0_sync+0x180/0x1c0\n\n Freed by task 560:\n kasan_save_stack+0x38/0x6c\n kasan_set_track+0x28/0x40\n kasan_set_free_info+0x24/0x4c\n __kasan_slab_free+0x100/0x164\n kasan_slab_free+0x14/0x20\n kmem_cache_free+0xc4/0x34c\n vm_area_free+0x1c/0x2c\n remove_vma+0x7c/0x94\n __do_munmap+0x358/0x710\n __vm_munmap+0xbc/0x130\n __arm64_sys_munmap+0x4c/0x64\n el0_svc_common.constprop.0+0xac/0x270\n do_el0_svc+0x38/0xa0\n el0_svc+0x1c/0x2c\n el0_sync_handler+0xe8/0x114\n el0_sync+0x180/0x1c0\n\n [...]\n ==================================================================\n\nTo prevent the race above, revert back to taking the mmap write lock\ninside binder_update_page_range(). One might expect an increase of mmap\nlock contention. However, binder already serializes these calls via top\nlevel alloc->mutex. Also, there was no performance impact shown when\nrunning the binder benchmark tests.\n\nNote this patch is specific to stable branches 5.4 and 5.10. Since in\nnewer kernel releases binder no longer caches a pointer to the vma.\nInstead, it has been refactored to use vma_lookup() which avoids the\nissue described here. This switch was introduced in commit a43cfc87caaf\n("android: binder: stop saving a pointer to the VMA").

In the Linux kernel, the following vulnerability has been resolved:\n\nocxl: fix pci device refcount leak when calling get_function_0()\n\nget_function_0() calls pci_get_domain_bus_and_slot(), as comment\nsays, it returns a pci device with refcount increment, so after\nusing it, pci_dev_put() needs be called.\n\nGet the device reference when get_function_0() is not called, so\npci_dev_put() can be called in the error path and callers\nunconditionally. And add comment above get_dvsec_vendor0() to tell\ncallers to call pci_dev_put().

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\n9p: set req refcount to zero to avoid uninitialized usage\n\nWhen a new request is allocated, the refcount will be zero if it is\nreused, but if the request is newly allocated from slab, it is not fully\ninitialized before being added to idr.\n\nIf the p9_read_work got a response before the refcount initiated. It will\nuse a uninitialized req, which will result in a bad request data struct.\n\nHere is the logs from syzbot.\n\nCorrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x00\n0x00 0x00 . . . . . . . . ] (in kfence-#110):\n p9_fcall_fini net/9p/client.c:248 [inline]\n p9_req_put net/9p/client.c:396 [inline]\n p9_req_put+0x208/0x250 net/9p/client.c:390\n p9_client_walk+0x247/0x540 net/9p/client.c:1165\n clone_fid fs/9p/fid.h:21 [inline]\n v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118\n v9fs_xattr_set fs/9p/xattr.c:100 [inline]\n v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159\n __vfs_setxattr+0x119/0x180 fs/xattr.c:182\n __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216\n __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277\n vfs_setxattr+0x143/0x340 fs/xattr.c:309\n setxattr+0x146/0x160 fs/xattr.c:617\n path_setxattr+0x197/0x1c0 fs/xattr.c:636\n __do_sys_setxattr fs/xattr.c:652 [inline]\n __se_sys_setxattr fs/xattr.c:648 [inline]\n __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\nBelow is a similar scenario, the scenario in the syzbot log looks more\ncomplicated than this one, but this patch can fix it.\n\n T21124 p9_read_work\n======================== second trans =================================\np9_client_walk\n p9_client_rpc\n p9_client_prepare_req\n p9_tag_alloc\n req = kmem_cache_alloc(p9_req_cache, GFP_NOFS);\n tag = idr_alloc\n << preempted >>\n req->tc.tag = tag;\n /* req->[refcount/tag] == uninitialized */\n m->rreq = p9_tag_lookup(m->client, m->rc.tag);\n /* increments uninitalized refcount */\n\n refcount_set(&req->refcount, 2);\n /* cb drops one ref */\n p9_client_cb(req)\n /* reader thread drops its ref:\n request is incorrectly freed */\n p9_req_put(req)\n /* use after free and ref underflow */\n p9_req_put(req)\n\nTo fix it, we can initialize the refcount to zero before add to idr.

In the Linux kernel, the following vulnerability has been resolved:\n\nhugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param()\n\nSyzkaller reports a null-ptr-deref bug as follows:\n======================================================\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nRIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380\n[...]\nCall Trace:\n \n vfs_parse_fs_param fs/fs_context.c:148 [inline]\n vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129\n vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191\n generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231\n do_new_mount fs/namespace.c:3036 [inline]\n path_mount+0x12de/0x1e20 fs/namespace.c:3370\n do_mount fs/namespace.c:3383 [inline]\n __do_sys_mount fs/namespace.c:3591 [inline]\n __se_sys_mount fs/namespace.c:3568 [inline]\n __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n [...]\n \n======================================================\n\nAccording to commit "vfs: parse: deal with zero length string value",\nkernel will set the param->string to null pointer in vfs_parse_fs_string()\nif fs string has zero length.\n\nYet the problem is that, hugetlbfs_parse_param() will dereference the\nparam->string, without checking whether it is a null pointer. To be more\nspecific, if hugetlbfs_parse_param() parses an illegal mount parameter,\nsuch as "size=,", kernel will constructs struct fs_parameter with null\npointer in vfs_parse_fs_string(), then passes this struct fs_parameter to\nhugetlbfs_parse_param(), which triggers the above null-ptr-deref bug.\n\nThis patch solves it by adding sanity check on param->string\nin hugetlbfs_parse_param().

In the Linux kernel, the following vulnerability has been resolved:\n\nfs: jfs: fix shift-out-of-bounds in dbDiscardAG\n\nThis should be applied to most URSAN bugs found recently by syzbot,\nby guarding the dbMount. As syzbot feeding rubbish into the bmap\ndescriptor.

In the Linux kernel, the following vulnerability has been resolved:\n\nvideo/aperture: Call sysfb_disable() before removing PCI devices\n\nCall sysfb_disable() from aperture_remove_conflicting_pci_devices()\nbefore removing PCI devices. Without, simpledrm can still bind to\nsimple-framebuffer devices after the hardware driver has taken over\nthe hardware. Both drivers interfere with each other and results are\nundefined.\n\nReported modesetting errors [1] are shown below.\n\n---- snap ----\nrcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 7 jiffies s: 165 root: 0x2000/.\nrcu: blocking rcu_node structures (internal RCU debug):\nTask dump for CPU 13:\ntask:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x00000008\nCall Trace:\n \n ? commit_tail+0xd7/0x130\n ? drm_atomic_helper_commit+0x126/0x150\n ? drm_atomic_commit+0xa4/0xe0\n ? drm_plane_get_damage_clips.cold+0x1c/0x1c\n ? drm_atomic_helper_dirtyfb+0x19e/0x280\n ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0\n ? drm_mode_getfb2_ioctl+0x2d0/0x2d0\n ? drm_ioctl_kernel+0xc4/0x150\n ? drm_ioctl+0x246/0x3f0\n ? drm_mode_getfb2_ioctl+0x2d0/0x2d0\n ? __x64_sys_ioctl+0x91/0xd0\n ? do_syscall_64+0x60/0xd0\n ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5\n \n...\nrcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 30 jiffies s: 169 root: 0x2000/.\nrcu: blocking rcu_node structures (internal RCU debug):\nTask dump for CPU 13:\ntask:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x0000400e\nCall Trace:\n \n ? memcpy_toio+0x76/0xc0\n ? memcpy_toio+0x1b/0xc0\n ? drm_fb_memcpy_toio+0x76/0xb0\n ? drm_fb_blit_toio+0x75/0x2b0\n ? simpledrm_simple_display_pipe_update+0x132/0x150\n ? drm_atomic_helper_commit_planes+0xb6/0x230\n ? drm_atomic_helper_commit_tail+0x44/0x80\n ? commit_tail+0xd7/0x130\n ? drm_atomic_helper_commit+0x126/0x150\n ? drm_atomic_commit+0xa4/0xe0\n ? drm_plane_get_damage_clips.cold+0x1c/0x1c\n ? drm_atomic_helper_dirtyfb+0x19e/0x280\n ? drm_mode_dirtyfb_ioctl+0x10f/0x1e0\n ? drm_mode_getfb2_ioctl+0x2d0/0x2d0\n ? drm_ioctl_kernel+0xc4/0x150\n ? drm_ioctl+0x246/0x3f0\n ? drm_mode_getfb2_ioctl+0x2d0/0x2d0\n ? __x64_sys_ioctl+0x91/0xd0\n ? do_syscall_64+0x60/0xd0\n ? entry_SYSCALL_64_after_hwframe+0x4b/0xb5\n \n\nThe problem was added by commit 5e0137612430 ("video/aperture: Disable\nand unregister sysfb devices via aperture helpers") to v6.0.3 and does\nnot exist in the mainline branch.\n\nThe mainline commit 5e0137612430 ("video/aperture: Disable and\nunregister sysfb devices via aperture helpers") has been backported\nfrom v6.0-rc1 to stable v6.0.3 from a larger patch series [2] that\nreworks fbdev framebuffer ownership. The backport misses a change to\naperture_remove_conflicting_pci_devices(). Mainline itself is fine,\nbecause the function does not exist there as a result of the patch\nseries.\n\nInstead of backporting the whole series, fix the additional function.

In the Linux kernel, the following vulnerability has been resolved:\n\nwwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new()\n\nInject fault while probing module, if device_register() fails,\nbut the refcount of kobject is not decreased to 0, the name\nallocated in dev_set_name() is leaked. Fix this by calling\nput_device(), so that name can be freed in callback function\nkobject_cleanup().\n\nunreferenced object 0xffff88810152ad20 (size 8):\n comm "modprobe", pid 252, jiffies 4294849206 (age 22.713s)\n hex dump (first 8 bytes):\n 68 77 73 69 6d 30 00 ff hwsim0..\n backtrace:\n [<000000009c3504ed>] __kmalloc_node_track_caller+0x44/0x1b0\n [<00000000c0228a5e>] kvasprintf+0xb5/0x140\n [<00000000cff8c21f>] kvasprintf_const+0x55/0x180\n [<0000000055a1e073>] kobject_set_name_vargs+0x56/0x150\n [<000000000a80b139>] dev_set_name+0xab/0xe0

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: cavium - prevent integer overflow loading firmware\n\nThe "code_length" value comes from the firmware file. If your firmware\nis untrusted realistically there is probably very little you can do to\nprotect yourself. Still we try to limit the damage as much as possible.\nAlso Smatch marks any data read from the filesystem as untrusted and\nprints warnings if it not capped correctly.\n\nThe "ntohl(ucode->code_length) * 2" multiplication can have an\ninteger overflow.

In the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix uaf for bfqq in bfq_exit_icq_bfqq\n\nCommit 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'")\nwill access 'bic->bfqq' in bic_set_bfqq(), however, bfq_exit_icq_bfqq()\ncan free bfqq first, and then call bic_set_bfqq(), which will cause uaf.\n\nFix the problem by moving bfq_exit_bfqq() behind bic_set_bfqq().

In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: fix potential use-after-free in jbd2_fc_wait_bufs\n\nIn 'jbd2_fc_wait_bufs' use 'bh' after put buffer head reference count\nwhich may lead to use-after-free.\nSo judge buffer if uptodate before put buffer head reference count.

In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: processor: idle: Check acpi_fetch_acpi_dev() return value\n\nThe return value of acpi_fetch_acpi_dev() could be NULL, which would\ncause a NULL pointer dereference to occur in acpi_device_hid().\n\n[ rjw: Subject and changelog edits, added empty line after if () ]