In the Linux kernel, the following vulnerability has been resolved:\n\nfou: fix initialization of grc\n\nThe grc must be initialize first. There can be a condition where if\nfou is NULL, goto out will be executed and grc would be used\nuninitialized.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: dp83822: Fix NULL pointer dereference on DP83825 devices\n\nThe probe() function is only used for DP83822 and DP83826 PHY,\nleaving the private data pointer uninitialized for the DP83825 models\nwhich causes a NULL pointer dereference in the recently introduced/changed\nfunctions dp8382x_config_init() and dp83822_set_wol().\n\nAdd the dp8382x_probe() function, so all PHY models will have a valid\nprivate data pointer to fix this issue and also prevent similar issues\nin the future.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct()\n\ndc_state_destruct() nulls the resource context of the DC state. The pipe\ncontext passed to dcn10_set_drr() is a member of this resource context.\n\nIf dc_state_destruct() is called parallel to the IRQ processing (which\ncalls dcn10_set_drr() at some point), we can end up using already nulled\nfunction callback fields of struct stream_resource.\n\nThe logic in dcn10_set_drr() already tries to avoid this, by checking tg\nagainst NULL. But if the nulling happens exactly after the NULL check and\nbefore the next access, then we get a race.\n\nAvoid this by copying tg first to a local variable, and then use this\nvariable for all the operations. This should work, as long as nobody\nfrees the resource pool where the timing generators live.\n\n(cherry picked from commit a3cc326a43bdc48fbdf53443e1027a03e309b643)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Avoid race between dcn35_set_drr() and dc_state_destruct()\n\ndc_state_destruct() nulls the resource context of the DC state. The pipe\ncontext passed to dcn35_set_drr() is a member of this resource context.\n\nIf dc_state_destruct() is called parallel to the IRQ processing (which\ncalls dcn35_set_drr() at some point), we can end up using already nulled\nfunction callback fields of struct stream_resource.\n\nThe logic in dcn35_set_drr() already tries to avoid this, by checking tg\nagainst NULL. But if the nulling happens exactly after the NULL check and\nbefore the next access, then we get a race.\n\nAvoid this by copying tg first to a local variable, and then use this\nvariable for all the operations. This should work, as long as nobody\nfrees the resource pool where the timing generators live.\n\n(cherry picked from commit 0607a50c004798a96e62c089a4c34c220179dcb5)

In the Linux kernel, the following vulnerability has been resolved:\n\nuserfaultfd: don't BUG_ON() if khugepaged yanks our page table\n\nSince khugepaged was changed to allow retracting page tables in file\nmappings without holding the mmap lock, these BUG_ON()s are wrong - get\nrid of them.\n\nWe could also remove the preceding "if (unlikely(...))" block, but then we\ncould reach pte_offset_map_lock() with transhuge pages not just for file\nmappings but also for anonymous mappings - which would probably be fine\nbut I think is not necessarily expected.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/panthor: Restrict high priorities on group_create\n\nWe were allowing any users to create a high priority group without any\npermission checks. As a result, this was allowing possible denial of\nservice.\n\nWe now only allow the DRM master or users with the CAP_SYS_NICE\ncapability to set higher priorities than PANTHOR_GROUP_PRIORITY_MEDIUM.\n\nAs the sole user of that uAPI lives in Mesa and hardcode a value of\nMEDIUM [1], this should be safe to do.\n\nAdditionally, as those checks are performed at the ioctl level,\npanthor_group_create now only check for priority level validity.\n\n[1]https://gitlab.freedesktop.org/mesa/mesa/-/blob/f390835074bdf162a63deb0311d1a6de527f9f89/src/gallium/drivers/panfrost/pan_csf.c#L1038

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: microchip: vcap: Fix use-after-free error in kunit test\n\nThis is a clear use-after-free error. We remove it, and rely on checking\nthe return code of vcap_del_rule.

In the Linux kernel, the following vulnerability has been resolved:\n\nlibfs: fix get_stashed_dentry()\n\nget_stashed_dentry() tries to optimistically retrieve a stashed dentry\nfrom a provided location. It needs to ensure to hold rcu lock before it\ndereference the stashed location to prevent UAF issues. Use\nrcu_dereference() instead of READ_ONCE() it's effectively equivalent\nwith some lockdep bells and whistles and it communicates clearly that\nthis expects rcu protection.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: Fix NULL dereference on XDP_TX\n\nIf number of TX queues are set to 1 we get a NULL pointer\ndereference during XDP_TX.\n\n~# ethtool -L eth0 tx 1\n~# ./xdp-trafficgen udp -A <ipv6-src> -a <ipv6-dst> eth0 -t 2\nTransmitting on eth0 (ifindex 2)\n[ 241.135257] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030\n\nFix this by using actual TX queues instead of max TX queues\nwhen picking the TX channel in am65_cpsw_ndo_xdp_xmit().

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: unset the binding mark of a reused connection\n\nSteve French reported null pointer dereference error from sha256 lib.\ncifs.ko can send session setup requests on reused connection.\nIf reused connection is used for binding session, conn->binding can\nstill remain true and generate_preauth_hash() will not set\nsess->Preauth_HashValue and it will be NULL.\nIt is used as a material to create an encryption key in\nksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer\ndereference error from crypto_shash_update().\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 8 PID: 429254 Comm: kworker/8:39\nHardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )\nWorkqueue: ksmbd-io handle_ksmbd_work [ksmbd]\nRIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n<TASK>\n? show_regs+0x6d/0x80\n? __die+0x24/0x80\n? page_fault_oops+0x99/0x1b0\n? do_user_addr_fault+0x2ee/0x6b0\n? exc_page_fault+0x83/0x1b0\n? asm_exc_page_fault+0x27/0x30\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n_sha256_update+0x77/0xa0 [sha256_ssse3]\nsha256_avx2_update+0x15/0x30 [sha256_ssse3]\ncrypto_shash_update+0x1e/0x40\nhmac_update+0x12/0x20\ncrypto_shash_update+0x1e/0x40\ngenerate_key+0x234/0x380 [ksmbd]\ngenerate_smb3encryptionkey+0x40/0x1c0 [ksmbd]\nksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]\nntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]\nsmb2_sess_setup+0x952/0xaa0 [ksmbd]\n__process_request+0xa3/0x1d0 [ksmbd]\n__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]\nhandle_ksmbd_work+0x2d/0xa0 [ksmbd]\nprocess_one_work+0x16c/0x350\nworker_thread+0x306/0x440\n? __pfx_worker_thread+0x10/0x10\nkthread+0xef/0x120\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x44/0x70\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1b/0x30\n</TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards harder\n\nSince commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component\nvia COMP_DUMMY()") dummy codecs declared like this:\n\nSND_SOC_DAILINK_DEF(dummy,\n DAILINK_COMP_ARRAY(COMP_DUMMY()));\n\nexpand to:\n\nstatic struct snd_soc_dai_link_component dummy[] = {\n};\n\nWhich means that dummy is a zero sized array and thus dais[i].codecs should\nnot be dereferenced *at all* since it points to the address of the next\nvariable stored in the data section as the "dummy" variable has an address\nbut no size, so even dereferencing dais[0] is already an out of bounds\narray reference.\n\nWhich means that the if (dais[i].codecs->name) check added in\ncommit 7d99a70b6595 ("ASoC: Intel: Boards: Fix NULL pointer deref\nin BYT/CHT boards") relies on that the part of the next variable which\nthe name member maps to just happens to be NULL.\n\nWhich apparently so far it usually is, except when it isn't\nand then it results in crashes like this one:\n\n[ 28.795659] BUG: unable to handle page fault for address: 0000000000030011\n...\n[ 28.795780] Call Trace:\n[ 28.795787] <TASK>\n...\n[ 28.795862] ? strcmp+0x18/0x40\n[ 28.795872] 0xffffffffc150c605\n[ 28.795887] platform_probe+0x40/0xa0\n...\n[ 28.795979] ? __pfx_init_module+0x10/0x10 [snd_soc_sst_bytcr_wm5102]\n\nReally fix things this time around by checking dais.num_codecs != 0.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: misaligned: Restrict user access to kernel memory\n\nraw_copy_{to,from}_user() do not call access_ok(), so this code allowed\nuserspace to access any virtual memory address.

In the Linux kernel, the following vulnerability has been resolved:\n\ncodetag: debug: mark codetags for poisoned page as empty\n\nWhen PG_hwpoison pages are freed they are treated differently in\nfree_pages_prepare() and instead of being released they are isolated.\n\nPage allocation tag counters are decremented at this point since the page\nis considered not in use. Later on when such pages are released by\nunpoison_memory(), the allocation tag counters will be decremented again\nand the following warning gets reported:\n\n[ 113.930443][ T3282] ------------[ cut here ]------------\n[ 113.931105][ T3282] alloc_tag was not set\n[ 113.931576][ T3282] WARNING: CPU: 2 PID: 3282 at ./include/linux/alloc_tag.h:130 pgalloc_tag_sub.part.66+0x154/0x164\n[ 113.932866][ T3282] Modules linked in: hwpoison_inject fuse ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute ip6table_nat ip6table_man4\n[ 113.941638][ T3282] CPU: 2 UID: 0 PID: 3282 Comm: madvise11 Kdump: loaded Tainted: G W 6.11.0-rc4-dirty #18\n[ 113.943003][ T3282] Tainted: [W]=WARN\n[ 113.943453][ T3282] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022\n[ 113.944378][ T3282] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 113.945319][ T3282] pc : pgalloc_tag_sub.part.66+0x154/0x164\n[ 113.946016][ T3282] lr : pgalloc_tag_sub.part.66+0x154/0x164\n[ 113.946706][ T3282] sp : ffff800087093a10\n[ 113.947197][ T3282] x29: ffff800087093a10 x28: ffff0000d7a9d400 x27: ffff80008249f0a0\n[ 113.948165][ T3282] x26: 0000000000000000 x25: ffff80008249f2b0 x24: 0000000000000000\n[ 113.949134][ T3282] x23: 0000000000000001 x22: 0000000000000001 x21: 0000000000000000\n[ 113.950597][ T3282] x20: ffff0000c08fcad8 x19: ffff80008251e000 x18: ffffffffffffffff\n[ 113.952207][ T3282] x17: 0000000000000000 x16: 0000000000000000 x15: ffff800081746210\n[ 113.953161][ T3282] x14: 0000000000000000 x13: 205d323832335420 x12: 5b5d353031313339\n[ 113.954120][ T3282] x11: ffff800087093500 x10: 000000000000005d x9 : 00000000ffffffd0\n[ 113.955078][ T3282] x8 : 7f7f7f7f7f7f7f7f x7 : ffff80008236ba90 x6 : c0000000ffff7fff\n[ 113.956036][ T3282] x5 : ffff000b34bf4dc8 x4 : ffff8000820aba90 x3 : 0000000000000001\n[ 113.956994][ T3282] x2 : ffff800ab320f000 x1 : 841d1e35ac932e00 x0 : 0000000000000000\n[ 113.957962][ T3282] Call trace:\n[ 113.958350][ T3282] pgalloc_tag_sub.part.66+0x154/0x164\n[ 113.959000][ T3282] pgalloc_tag_sub+0x14/0x1c\n[ 113.959539][ T3282] free_unref_page+0xf4/0x4b8\n[ 113.960096][ T3282] __folio_put+0xd4/0x120\n[ 113.960614][ T3282] folio_put+0x24/0x50\n[ 113.961103][ T3282] unpoison_memory+0x4f0/0x5b0\n[ 113.961678][ T3282] hwpoison_unpoison+0x30/0x48 [hwpoison_inject]\n[ 113.962436][ T3282] simple_attr_write_xsigned.isra.34+0xec/0x1cc\n[ 113.963183][ T3282] simple_attr_write+0x38/0x48\n[ 113.963750][ T3282] debugfs_attr_write+0x54/0x80\n[ 113.964330][ T3282] full_proxy_write+0x68/0x98\n[ 113.964880][ T3282] vfs_write+0xdc/0x4d0\n[ 113.965372][ T3282] ksys_write+0x78/0x100\n[ 113.965875][ T3282] __arm64_sys_write+0x24/0x30\n[ 113.966440][ T3282] invoke_syscall+0x7c/0x104\n[ 113.966984][ T3282] el0_svc_common.constprop.1+0x88/0x104\n[ 113.967652][ T3282] do_el0_svc+0x2c/0x38\n[ 113.968893][ T3282] el0_svc+0x3c/0x1b8\n[ 113.969379][ T3282] el0t_64_sync_handler+0x98/0xbc\n[ 113.969980][ T3282] el0t_64_sync+0x19c/0x1a0\n[ 113.970511][ T3282] ---[ end trace 0000000000000000 ]---\n\nTo fix this, clear the page tag reference after the page got isolated\nand accounted for.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/osnoise: Use a cpumask to know what threads are kthreads\n\nThe start_kthread() and stop_thread() code was not always called with the\ninterface_lock held. This means that the kthread variable could be\nunexpectedly changed causing the kthread_stop() to be called on it when it\nshould not have been, leading to:\n\n while true; do\n rtla timerlat top -u -q & PID=$!;\n sleep 5;\n kill -INT $PID;\n sleep 0.001;\n kill -TERM $PID;\n wait $PID;\n done\n\nCausing the following OOPS:\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:hrtimer_active+0x58/0x300\n Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 <0f> b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f\n RSP: 0018:ffff88811d97f940 EFLAGS: 00010202\n RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b\n RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28\n RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60\n R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d\n R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28\n FS: 0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0\n Call Trace:\n <TASK>\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x154/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? hrtimer_active+0x58/0x300\n ? __pfx_mutex_lock+0x10/0x10\n ? __pfx_locks_remove_file+0x10/0x10\n hrtimer_cancel+0x15/0x40\n timerlat_fd_release+0x8e/0x1f0\n ? security_file_release+0x43/0x80\n __fput+0x372/0xb10\n task_work_run+0x11e/0x1f0\n ? _raw_spin_lock+0x85/0xe0\n ? __pfx_task_work_run+0x10/0x10\n ? poison_slab_object+0x109/0x170\n ? do_exit+0x7a0/0x24b0\n do_exit+0x7bd/0x24b0\n ? __pfx_migrate_enable+0x10/0x10\n ? __pfx_do_exit+0x10/0x10\n ? __pfx_read_tsc+0x10/0x10\n ? ktime_get+0x64/0x140\n ? _raw_spin_lock_irq+0x86/0xe0\n do_group_exit+0xb0/0x220\n get_signal+0x17ba/0x1b50\n ? vfs_read+0x179/0xa40\n ? timerlat_fd_read+0x30b/0x9d0\n ? __pfx_get_signal+0x10/0x10\n ? __pfx_timerlat_fd_read+0x10/0x10\n arch_do_signal_or_restart+0x8c/0x570\n ? __pfx_arch_do_signal_or_restart+0x10/0x10\n ? vfs_read+0x179/0xa40\n ? ksys_read+0xfe/0x1d0\n ? __pfx_ksys_read+0x10/0x10\n syscall_exit_to_user_mode+0xbc/0x130\n do_syscall_64+0x74/0x110\n ? __pfx___rseq_handle_notify_resume+0x10/0x10\n ? __pfx_ksys_read+0x10/0x10\n ? fpregs_restore_userregs+0xdb/0x1e0\n ? fpregs_restore_userregs+0xdb/0x1e0\n ? syscall_exit_to_user_mode+0x116/0x130\n ? do_syscall_64+0x74/0x110\n ? do_syscall_64+0x74/0x110\n ? do_syscall_64+0x74/0x110\n entry_SYSCALL_64_after_hwframe+0x71/0x79\n RIP: 0033:0x7ff0070eca9c\n Code: Unable to access opcode bytes at 0x7ff0070eca72.\n RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c\n RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003\n RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0\n R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003\n R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008\n </TASK>\n Modules linked in: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core\n ---[ end trace 0000000000000000 ]---\n\nThis is because it would mistakenly call kthread_stop() on a user space\nthread making it "exit" before it actually exits.\n\nSince kthreads are created based on global behavior, use a cpumask to know\nwhen kthreads are running and that they need to be shutdown before\nproceeding to do new work.\n\n\nThis was debugged by using the persistent ring buffer:\n\n\nNote, locking was originally used to fix this, but that proved to cause too\nmany deadlocks to work around:\n\n https://lore.kernel.org/linux-trace-kernel/20240823102816.5e55753b@gandalf.local.home/

In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (hp-wmi-sensors) Check if WMI event data exists\n\nThe BIOS can choose to return no event data in response to a\nWMI event, so the ACPI object passed to the WMI notify handler\ncan be NULL.\n\nCheck for such a situation and ignore the event in such a case.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: move netif_queue_set_napi to rtnl-protected sections\n\nCurrently, netif_queue_set_napi() is called from ice_vsi_rebuild() that is\nnot rtnl-locked when called from the reset. This creates the need to take\nthe rtnl_lock just for a single function and complicates the\nsynchronization with .ndo_bpf. At the same time, there no actual need to\nfill napi-to-queue information at this exact point.\n\nFill napi-to-queue information when opening the VSI and clear it when the\nVSI is being closed. Those routines are already rtnl-locked.\n\nAlso, rewrite napi-to-queue assignment in a way that prevents inclusion of\nXDP queues, as this leads to out-of-bounds writes, such as one below.\n\n[ +0.000004] BUG: KASAN: slab-out-of-bounds in netif_queue_set_napi+0x1c2/0x1e0\n[ +0.000012] Write of size 8 at addr ffff889881727c80 by task bash/7047\n[ +0.000006] CPU: 24 PID: 7047 Comm: bash Not tainted 6.10.0-rc2+ #2\n[ +0.000004] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021\n[ +0.000003] Call Trace:\n[ +0.000003] <TASK>\n[ +0.000002] dump_stack_lvl+0x60/0x80\n[ +0.000007] print_report+0xce/0x630\n[ +0.000007] ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ +0.000007] ? __virt_addr_valid+0x1c9/0x2c0\n[ +0.000005] ? netif_queue_set_napi+0x1c2/0x1e0\n[ +0.000003] kasan_report+0xe9/0x120\n[ +0.000004] ? netif_queue_set_napi+0x1c2/0x1e0\n[ +0.000004] netif_queue_set_napi+0x1c2/0x1e0\n[ +0.000005] ice_vsi_close+0x161/0x670 [ice]\n[ +0.000114] ice_dis_vsi+0x22f/0x270 [ice]\n[ +0.000095] ice_pf_dis_all_vsi.constprop.0+0xae/0x1c0 [ice]\n[ +0.000086] ice_prepare_for_reset+0x299/0x750 [ice]\n[ +0.000087] pci_dev_save_and_disable+0x82/0xd0\n[ +0.000006] pci_reset_function+0x12d/0x230\n[ +0.000004] reset_store+0xa0/0x100\n[ +0.000006] ? __pfx_reset_store+0x10/0x10\n[ +0.000002] ? __pfx_mutex_lock+0x10/0x10\n[ +0.000004] ? __check_object_size+0x4c1/0x640\n[ +0.000007] kernfs_fop_write_iter+0x30b/0x4a0\n[ +0.000006] vfs_write+0x5d6/0xdf0\n[ +0.000005] ? fd_install+0x180/0x350\n[ +0.000005] ? __pfx_vfs_write+0x10/0xA10\n[ +0.000004] ? do_fcntl+0x52c/0xcd0\n[ +0.000004] ? kasan_save_track+0x13/0x60\n[ +0.000003] ? kasan_save_free_info+0x37/0x60\n[ +0.000006] ksys_write+0xfa/0x1d0\n[ +0.000003] ? __pfx_ksys_write+0x10/0x10\n[ +0.000002] ? __x64_sys_fcntl+0x121/0x180\n[ +0.000004] ? _raw_spin_lock+0x87/0xe0\n[ +0.000005] do_syscall_64+0x80/0x170\n[ +0.000007] ? _raw_spin_lock+0x87/0xe0\n[ +0.000004] ? __pfx__raw_spin_lock+0x10/0x10\n[ +0.000003] ? file_close_fd_locked+0x167/0x230\n[ +0.000005] ? syscall_exit_to_user_mode+0x7d/0x220\n[ +0.000005] ? do_syscall_64+0x8c/0x170\n[ +0.000004] ? do_syscall_64+0x8c/0x170\n[ +0.000003] ? do_syscall_64+0x8c/0x170\n[ +0.000003] ? fput+0x1a/0x2c0\n[ +0.000004] ? filp_close+0x19/0x30\n[ +0.000004] ? do_dup2+0x25a/0x4c0\n[ +0.000004] ? __x64_sys_dup2+0x6e/0x2e0\n[ +0.000002] ? syscall_exit_to_user_mode+0x7d/0x220\n[ +0.000004] ? do_syscall_64+0x8c/0x170\n[ +0.000003] ? __count_memcg_events+0x113/0x380\n[ +0.000005] ? handle_mm_fault+0x136/0x820\n[ +0.000005] ? do_user_addr_fault+0x444/0xa80\n[ +0.000004] ? clear_bhb_loop+0x25/0x80\n[ +0.000004] ? clear_bhb_loop+0x25/0x80\n[ +0.000002] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ +0.000005] RIP: 0033:0x7f2033593154

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: add check for invalid name in btf_name_valid_section()\n\nIf the length of the name string is 1 and the value of name[0] is NULL\nbyte, an OOB vulnerability occurs in btf_name_valid_section() and the\nreturn value is true, so the invalid name passes the check.\n\nTo solve this, you need to check if the first position is NULL byte and\nif the first character is printable.

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: Fix double free of 'buf' in error path\n\nsmatch warning:\ndrivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of 'buf'\n\nIn fastrpc_req_mmap() error path, the fastrpc buffer is freed in\nfastrpc_req_munmap_impl() if unmap is successful.\n\nBut in the end, there is an unconditional call to fastrpc_buf_free().\nSo the above case triggers the double free of fastrpc buf.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double put of @cfile in smb2_rename_path()\n\nIf smb2_set_path_attr() is called with a valid @cfile and returned\n-EINVAL, we need to call cifs_get_writable_path() again as the\nreference of @cfile was already dropped by previous smb2_compound_op()\ncall.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race between direct IO write and fsync when using same fd\n\nIf we have 2 threads that are using the same file descriptor and one of\nthem is doing direct IO writes while the other is doing fsync, we have a\nrace where we can end up either:\n\n1) Attempt a fsync without holding the inode's lock, triggering an\n assertion failures when assertions are enabled;\n\n2) Do an invalid memory access from the fsync task because the file private\n points to memory allocated on stack by the direct IO task and it may be\n used by the fsync task after the stack was destroyed.\n\nThe race happens like this:\n\n1) A user space program opens a file descriptor with O_DIRECT;\n\n2) The program spawns 2 threads using libpthread for example;\n\n3) One of the threads uses the file descriptor to do direct IO writes,\n while the other calls fsync using the same file descriptor.\n\n4) Call task A the thread doing direct IO writes and task B the thread\n doing fsyncs;\n\n5) Task A does a direct IO write, and at btrfs_direct_write() sets the\n file's private to an on stack allocated private with the member\n 'fsync_skip_inode_lock' set to true;\n\n6) Task B enters btrfs_sync_file() and sees that there's a private\n structure associated to the file which has 'fsync_skip_inode_lock' set\n to true, so it skips locking the inode's VFS lock;\n\n7) Task A completes the direct IO write, and resets the file's private to\n NULL since it had no prior private and our private was stack allocated.\n Then it unlocks the inode's VFS lock;\n\n8) Task B enters btrfs_get_ordered_extents_for_logging(), then the\n assertion that checks the inode's VFS lock is held fails, since task B\n never locked it and task A has already unlocked it.\n\nThe stack trace produced is the following:\n\n assertion failed: inode_is_locked(&inode->vfs_inode), in fs/btrfs/ordered-data.c:983\n ------------[ cut here ]------------\n kernel BUG at fs/btrfs/ordered-data.c:983!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI\n CPU: 9 PID: 5072 Comm: worker Tainted: G U OE 6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8\n Hardware name: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 07/28/2020\n RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs]\n Code: 50 d6 86 c0 e8 (...)\n RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246\n RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800\n RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38\n R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800\n R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000\n FS: 00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0\n Call Trace:\n \n ? __die_body.cold+0x14/0x24\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x6a/0x90\n ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n ? exc_invalid_op+0x50/0x70\n ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n ? asm_exc_invalid_op+0x1a/0x20\n ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n ? btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n btrfs_sync_file+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a]\n ? __seccomp_filter+0x31d/0x4f0\n __x64_sys_fdatasync+0x4f/0x90\n do_syscall_64+0x82/0x160\n ? do_futex+0xcb/0x190\n ? __x64_sys_futex+0x10e/0x1d0\n ? switch_fpu_return+0x4f/0xd0\n ? syscall_exit_to_user_mode+0x72/0x220\n ? do_syscall_64+0x8e/0x160\n ? syscall_exit_to_user_mod\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Disable coherent dumb buffers without 3d\n\nCoherent surfaces make only sense if the host renders to them using\naccelerated apis. Without 3d the entire content of dumb buffers stays\nin the guest making all of the extra work they're doing to synchronize\nbetween guest and host useless.\n\nConfigurations without 3d also tend to run with very low graphics\nmemory limits. The pinned console fb, mob cursors and graphical login\nmanager tend to run out of 16MB graphics memory that those guests use.\n\nFix it by making sure the coherent dumb buffers are only used on\nconfigs with 3d enabled.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: fix ID 0 endp usage after multiple re-creations\n\n'local_addr_used' and 'add_addr_accepted' are decremented for addresses\nnot related to the initial subflow (ID0), because the source and\ndestination addresses of the initial subflows are known from the\nbeginning: they don't count as "additional local address being used" or\n"ADD_ADDR being accepted".\n\nIt is then required not to increment them when the entrypoint used by\nthe initial subflow is removed and re-added during a connection. Without\nthis modification, this entrypoint cannot be removed and re-added more\nthan once.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix prime with external buffers\n\nMake sure that for external buffers mapping goes through the dma_buf\ninterface instead of trying to access pages directly.\n\nExternal buffers might not provide direct access to readable/writable\npages so to make sure the bo's created from external dma_bufs can be\nread dma_buf interface has to be used.\n\nFixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't\ntrigger this due to the fact that virtual machines will not have\nmultiple GPUs but it enables better test coverage in IGT.

In the Linux kernel, the following vulnerability has been resolved:\n\nworkqueue: Fix spruious data race in __flush_work()\n\nWhen flushing a work item for cancellation, __flush_work() knows that it\nexclusively owns the work item through its PENDING bit. 134874e2eee9\n("workqueue: Allow cancel_work_sync() and disable_work() from atomic\ncontexts on BH work items") added a read of @work->data to determine whether\nto use busy wait for BH work items that are being canceled. While the read\nis safe when @from_cancel, @work->data was read before testing @from_cancel\nto simplify code structure:\n\n data = *work_data_bits(work);\n if (from_cancel &&\n !WARN_ON_ONCE(data & WORK_STRUCT_PWQ) && (data & WORK_OFFQ_BH)) {\n\nWhile the read data was never used if !@from_cancel, this could trigger\nKCSAN data race detection spuriously:\n\n ==================================================================\n BUG: KCSAN: data-race in __flush_work / __flush_work\n\n write to 0xffff8881223aa3e8 of 8 bytes by task 3998 on cpu 0:\n instrument_write include/linux/instrumented.h:41 [inline]\n ___set_bit include/asm-generic/bitops/instrumented-non-atomic.h:28 [inline]\n insert_wq_barrier kernel/workqueue.c:3790 [inline]\n start_flush_work kernel/workqueue.c:4142 [inline]\n __flush_work+0x30b/0x570 kernel/workqueue.c:4178\n flush_work kernel/workqueue.c:4229 [inline]\n ...\n\n read to 0xffff8881223aa3e8 of 8 bytes by task 50 on cpu 1:\n __flush_work+0x42a/0x570 kernel/workqueue.c:4188\n flush_work kernel/workqueue.c:4229 [inline]\n flush_delayed_work+0x66/0x70 kernel/workqueue.c:4251\n ...\n\n value changed: 0x0000000000400000 -> 0xffff88810006c00d\n\nReorganize the code so that @from_cancel is tested before @work->data is\naccessed. The only problem is triggering KCSAN detection spuriously. This\nshouldn't need READ_ONCE() or other access qualifiers.\n\nNo functional changes.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Disable preemption while updating GPU stats\n\nWe forgot to disable preemption around the write_seqcount_begin/end() pair\nwhile updating GPU stats:\n\n [ ] WARNING: CPU: 2 PID: 12 at include/linux/seqlock.h:221 __seqprop_assert.isra.0+0x128/0x150 [v3d]\n [ ] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched]\n <...snip...>\n [ ] Call trace:\n [ ] __seqprop_assert.isra.0+0x128/0x150 [v3d]\n [ ] v3d_job_start_stats.isra.0+0x90/0x218 [v3d]\n [ ] v3d_bin_job_run+0x23c/0x388 [v3d]\n [ ] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched]\n [ ] process_one_work+0x62c/0xb48\n [ ] worker_thread+0x468/0x5b0\n [ ] kthread+0x1c4/0x1e0\n [ ] ret_from_fork+0x10/0x20\n\nFix it.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: ensure that nfsd4_fattr_args.context is zeroed out\n\nIf nfsd4_encode_fattr4 ends up doing a "goto out" before we get to\nchecking for the security label, then args.context will be set to\nuninitialized junk on the stack, which we'll then try to free.\nInitialize it early.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix potential UAF in nfsd4_cb_getattr_release\n\nOnce we drop the delegation reference, the fields embedded in it are no\nlonger safe to access. Do that last.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: avoid using null object of framebuffer\n\nInstead of using state->fb->obj[0] directly, get object from framebuffer\nby calling drm_gem_fb_get_obj() and return error code when object is\nnull to avoid using null object of framebuffer.\n\n(cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)

In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pmic_glink: Fix race during initialization\n\nAs pointed out by Stephen Boyd it is possible that during initialization\nof the pmic_glink child drivers, the protection-domain notifiers fires,\nand the associated work is scheduled, before the client registration\nreturns and as a result the local "client" pointer has been initialized.\n\nThe outcome of this is a NULL pointer dereference as the "client"\npointer is blindly dereferenced.\n\nTimeline provided by Stephen:\n CPU0 CPU1\n ---- ----\n ucsi->client = NULL;\n devm_pmic_glink_register_client()\n client->pdr_notify(client->priv, pg->client_state)\n pmic_glink_ucsi_pdr_notify()\n schedule_work(&ucsi->register_work)\n <schedule away>\n pmic_glink_ucsi_register()\n ucsi_register()\n pmic_glink_ucsi_read_version()\n pmic_glink_ucsi_read()\n pmic_glink_ucsi_read()\n pmic_glink_send(ucsi->client)\n <client is NULL BAD>\n ucsi->client = client // Too late!\n\nThis code is identical across the altmode, battery manager and usci\nchild drivers.\n\nResolve this by splitting the allocation of the "client" object and the\nregistration thereof into two operations.\n\nThis only happens if the protection domain registry is populated at the\ntime of registration, which by the introduction of commit '1ebcde047c54\n("soc: qcom: add pd-mapper implementation")' became much more likely.

In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: qcom: scm: Mark get_wq_ctx() as atomic call\n\nCurrently get_wq_ctx() is wrongly configured as a standard call. When two\nSMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to\nresume the corresponding sleeping thread. But if get_wq_ctx() is\ninterrupted, goes to sleep and another SMC call is waiting to be allocated\na waitq context, it leads to a deadlock.\n\nTo avoid this get_wq_ctx() must be an atomic call and can't be a standard\nSMC call. Hence mark get_wq_ctx() as a fast call.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: Move unregister out of atomic section\n\nCommit '9329933699b3 ("soc: qcom: pmic_glink: Make client-lock\nnon-sleeping")' moved the pmic_glink client list under a spinlock, as it\nis accessed by the rpmsg/glink callback, which in turn is invoked from\nIRQ context.\n\nThis means that ucsi_unregister() is now called from atomic context,\nwhich isn't feasible as it's expecting a sleepable context. An effort is\nunder way to get GLINK to invoke its callbacks in a sleepable context,\nbut until then lets schedule the unregistration.\n\nA side effect of this is that ucsi_unregister() can now happen\nafter the remote processor, and thereby the communication link with it, is\ngone. pmic_glink_send() is amended with a check to avoid the resulting NULL\npointer dereference.\nThis does however result in the user being informed about this error by\nthe following entry in the kernel log:\n\n ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5

In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix out-of-bound access when z_erofs_gbuf_growsize() partially fails\n\nIf z_erofs_gbuf_growsize() partially fails on a global buffer due to\nmemory allocation failure or fault injection (as reported by syzbot [1]),\nnew pages need to be freed by comparing to the existing pages to avoid\nmemory leaks.\n\nHowever, the old gbuf->pages[] array may not be large enough, which can\nlead to null-ptr-deref or out-of-bound access.\n\nFix this by checking against gbuf->nrpages in advance.\n\n[1] https://lore.kernel.org/r/000000000000f7b96e062018c6e3@google.com

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()\n\n[BUG]\nThere is an internal report that KASAN is reporting use-after-free, with\nthe following backtrace:\n\n BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs]\n Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45\n CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\n Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]\n Call Trace:\n dump_stack_lvl+0x61/0x80\n print_address_description.constprop.0+0x5e/0x2f0\n print_report+0x118/0x216\n kasan_report+0x11d/0x1f0\n btrfs_check_read_bio+0xa68/0xb70 [btrfs]\n process_one_work+0xce0/0x12a0\n worker_thread+0x717/0x1250\n kthread+0x2e3/0x3c0\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x11/0x20\n\n Allocated by task 20917:\n kasan_save_stack+0x37/0x60\n kasan_save_track+0x10/0x30\n __kasan_slab_alloc+0x7d/0x80\n kmem_cache_alloc_noprof+0x16e/0x3e0\n mempool_alloc_noprof+0x12e/0x310\n bio_alloc_bioset+0x3f0/0x7a0\n btrfs_bio_alloc+0x2e/0x50 [btrfs]\n submit_extent_page+0x4d1/0xdb0 [btrfs]\n btrfs_do_readpage+0x8b4/0x12a0 [btrfs]\n btrfs_readahead+0x29a/0x430 [btrfs]\n read_pages+0x1a7/0xc60\n page_cache_ra_unbounded+0x2ad/0x560\n filemap_get_pages+0x629/0xa20\n filemap_read+0x335/0xbf0\n vfs_read+0x790/0xcb0\n ksys_read+0xfd/0x1d0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n Freed by task 20917:\n kasan_save_stack+0x37/0x60\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x50\n __kasan_slab_free+0x4b/0x60\n kmem_cache_free+0x214/0x5d0\n bio_free+0xed/0x180\n end_bbio_data_read+0x1cc/0x580 [btrfs]\n btrfs_submit_chunk+0x98d/0x1880 [btrfs]\n btrfs_submit_bio+0x33/0x70 [btrfs]\n submit_one_bio+0xd4/0x130 [btrfs]\n submit_extent_page+0x3ea/0xdb0 [btrfs]\n btrfs_do_readpage+0x8b4/0x12a0 [btrfs]\n btrfs_readahead+0x29a/0x430 [btrfs]\n read_pages+0x1a7/0xc60\n page_cache_ra_unbounded+0x2ad/0x560\n filemap_get_pages+0x629/0xa20\n filemap_read+0x335/0xbf0\n vfs_read+0x790/0xcb0\n ksys_read+0xfd/0x1d0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[CAUSE]\nAlthough I cannot reproduce the error, the report itself is good enough\nto pin down the cause.\n\nThe call trace is the regular endio workqueue context, but the\nfree-by-task trace is showing that during btrfs_submit_chunk() we\nalready hit a critical error, and is calling btrfs_bio_end_io() to error\nout. And the original endio function called bio_put() to free the whole\nbio.\n\nThis means a double freeing thus causing use-after-free, e.g.:\n\n1. Enter btrfs_submit_bio() with a read bio\n The read bio length is 128K, crossing two 64K stripes.\n\n2. The first run of btrfs_submit_chunk()\n\n2.1 Call btrfs_map_block(), which returns 64K\n2.2 Call btrfs_split_bio()\n Now there are two bios, one referring to the first 64K, the other\n referring to the second 64K.\n2.3 The first half is submitted.\n\n3. The second run of btrfs_submit_chunk()\n\n3.1 Call btrfs_map_block(), which by somehow failed\n Now we call btrfs_bio_end_io() to handle the error\n\n3.2 btrfs_bio_end_io() calls the original endio function\n Which is end_bbio_data_read(), and it calls bio_put() for the\n original bio.\n\n Now the original bio is freed.\n\n4. The submitted first 64K bio finished\n Now we call into btrfs_check_read_bio() and tries to advance the bio\n iter.\n But since the original bio (thus its iter) is already freed, we\n trigger the above use-after free.\n\n And even if the memory is not poisoned/corrupted, we will later call\n the original endio function, causing a double freeing.\n\n[FIX]\nInstead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(),\nwhich has the extra check on split bios and do the proper refcounting\nfor cloned bios.\n\nFurthermore there is already one extra btrfs_cleanup_bio() call, but\nthat is duplicated to btrfs_orig_bbio_end_io() call, so remove that\nlabel completely.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()\n\nThis happens when called from SMB2_read() while using rdma\nand reaching the rdma_readwrite_threshold.

In the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined\n\ncreate_elf_fdpic_tables() does not correctly account the space for the\nAUX vector when an architecture has ELF_HWCAP2 defined. Prior to the\ncommit 10e29251be0e ("binfmt_elf_fdpic: fix /proc/<pid>/auxv") it\nresulted in the last entry of the AUX vector being set to zero, but with\nthat change it results in a kernel BUG.\n\nFix that by adding one to the number of AUXV entries (nitems) when\nELF_HWCAP2 is defined.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: prevent UAF around preempt fence\n\nThe fence lock is part of the queue, therefore in the current design\nanything locking the fence should then also hold a ref to the queue to\nprevent the queue from being freed.\n\nHowever, currently it looks like we signal the fence and then drop the\nqueue ref, but if something is waiting on the fence, the waiter is\nkicked to wake up at some later point, where upon waking up it first\ngrabs the lock before checking the fence state. But if we have already\ndropped the queue ref, then the lock might already be freed as part of\nthe queue, leading to uaf.\n\nTo prevent this, move the fence lock into the fence itself so we don't\nrun into lifetime issues. Alternative might be to have device level\nlock, or only release the queue in the fence release callback, however\nthat might require pushing to another worker to avoid locking issues.\n\nReferences: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454\nReferences: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342\nReferences: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020\n(cherry picked from commit 7116c35aacedc38be6d15bd21b2fc936eed0008b)

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btnxpuart: Fix random crash seen while removing driver\n\nThis fixes the random kernel crash seen while removing the driver, when\nrunning the load/unload test over multiple iterations.\n\n1) modprobe btnxpuart\n2) hciconfig hci0 reset\n3) hciconfig (check hci0 interface up with valid BD address)\n4) modprobe -r btnxpuart\nRepeat steps 1 to 4\n\nThe ps_wakeup() call in btnxpuart_close() schedules the psdata->work(),\nwhich gets scheduled after module is removed, causing a kernel crash.\n\nThis hidden issue got highlighted after enabling Power Save by default\nin 4183a7be7700 (Bluetooth: btnxpuart: Enable Power Save feature on\nstartup)\n\nThe new ps_cleanup() deasserts UART break immediately while closing\nserdev device, cancels any scheduled ps_work and destroys the ps_lock\nmutex.\n\n[ 85.884604] Unable to handle kernel paging request at virtual address ffffd4a61638f258\n[ 85.884624] Mem abort info:\n[ 85.884625] ESR = 0x0000000086000007\n[ 85.884628] EC = 0x21: IABT (current EL), IL = 32 bits\n[ 85.884633] SET = 0, FnV = 0\n[ 85.884636] EA = 0, S1PTW = 0\n[ 85.884638] FSC = 0x07: level 3 translation fault\n[ 85.884642] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041dd0000\n[ 85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000\n[ 85.884662] Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP\n[ 85.890932] Modules linked in: algif_hash algif_skcipher af_alg overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv rc_core fuse [last unloaded: btnxpuart(O)]\n[ 85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Tainted: G O 6.1.36+g937b1be4345a #1\n[ 85.936176] Hardware name: FSL i.MX8MM EVK board (DT)\n[ 85.936182] Workqueue: events 0xffffd4a61638f380\n[ 85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 85.952817] pc : 0xffffd4a61638f258\n[ 85.952823] lr : 0xffffd4a61638f258\n[ 85.952827] sp : ffff8000084fbd70\n[ 85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000\n[ 85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305\n[ 85.963119] x23: ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970\n[ 85.977382] x20: 0000000000000000 x19: ffff4bf1c8540880 x18: 0000000000000000\n[ 85.977391] x17: 0000000000000000 x16: 0000000000000133 x15: 0000ffffe2217090\n[ 85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139\n[ 85.977407] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff8000084fbc50\n[ 85.977417] x8 : ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8\n[ 85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000\n[ 85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000\n[ 85.977443] Call trace:\n[ 85.977446] 0xffffd4a61638f258\n[ 85.977451] 0xffffd4a61638f3e8\n[ 85.977455] process_one_work+0x1d4/0x330\n[ 85.977464] worker_thread+0x6c/0x430\n[ 85.977471] kthread+0x108/0x10c\n[ 85.977476] ret_from_fork+0x10/0x20\n[ 85.977488] Code: bad PC value\n[ 85.977491] ---[ end trace 0000000000000000 ]---\n\nPreset since v6.9.11

In the Linux kernel, the following vulnerability has been resolved:\n\nigb: cope with large MAX_SKB_FRAGS\n\nSabrina reports that the igb driver does not cope well with large\nMAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload\ncorruption on TX.\n\nAn easy reproducer is to run ssh to connect to the machine. With\nMAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has\nbeen reported originally in\nhttps://bugzilla.redhat.com/show_bug.cgi?id=2265320\n\nThe root cause of the issue is that the driver does not take into\naccount properly the (possibly large) shared info size when selecting\nthe ring layout, and will try to fit two packets inside the same 4K\npage even when the 1st fraglist will trump over the 2nd head.\n\nAddress the issue by checking if 2K buffers are insufficient.

In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: tegra: Do not mark ACPI devices as irq safe\n\nOn ACPI machines, the tegra i2c module encounters an issue due to a\nmutex being called inside a spinlock. This leads to the following bug:\n\n BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585\n ...\n\n Call trace:\n __might_sleep\n __mutex_lock_common\n mutex_lock_nested\n acpi_subsys_runtime_resume\n rpm_resume\n tegra_i2c_xfer\n\nThe problem arises because during __pm_runtime_resume(), the spinlock\n&dev->power.lock is acquired before rpm_resume() is called. Later,\nrpm_resume() invokes acpi_subsys_runtime_resume(), which relies on\nmutexes, triggering the error.\n\nTo address this issue, devices on ACPI are now marked as not IRQ-safe,\nconsidering the dependency of acpi_subsys_runtime_resume() on mutexes.

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: mmc_test: Fix NULL dereference on allocation failure\n\nIf the "test->highmem = alloc_pages()" allocation fails then calling\n__free_pages(test->highmem) will result in a NULL dereference. Also\nchange the error code to -ENOMEM instead of returning success.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()\n\nIf xhci_mem_init() fails, it calls into xhci_mem_cleanup() to mop\nup the damage. If it fails early enough, before xhci->interrupters\nis allocated but after xhci->max_interrupters has been set, which\nhappens in most (all?) cases, things get uglier, as xhci_mem_cleanup()\nunconditionally derefences xhci->interrupters. With prejudice.\n\nGate the interrupt freeing loop with a check on xhci->interrupters\nbeing non-NULL.\n\nFound while debugging a DMA allocation issue that led the XHCI driver\non this exact path.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix hugetlb vs. core-mm PT locking\n\nWe recently made GUP's common page table walking code to also walk hugetlb\nVMAs without most hugetlb special-casing, preparing for the future of\nhaving less hugetlb-specific page table walking code in the codebase. \nTurns out that we missed one page table locking detail: page table locking\nfor hugetlb folios that are not mapped using a single PMD/PUD.\n\nAssume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB\nhugetlb folios on arm64 with 4 KiB base page size). GUP, as it walks the\npage tables, will perform a pte_offset_map_lock() to grab the PTE table\nlock.\n\nHowever, hugetlb that concurrently modifies these page tables would\nactually grab the mm->page_table_lock: with USE_SPLIT_PTE_PTLOCKS, the\nlocks would differ. Something similar can happen right now with hugetlb\nfolios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS.\n\nThis issue can be reproduced [1], for example triggering:\n\n[ 3105.936100] ------------[ cut here ]------------\n[ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188\n[ 3105.944634] Modules linked in: [...]\n[ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1\n[ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024\n[ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 3105.991108] pc : try_grab_folio+0x11c/0x188\n[ 3105.994013] lr : follow_page_pte+0xd8/0x430\n[ 3105.996986] sp : ffff80008eafb8f0\n[ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43\n[ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48\n[ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978\n[ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001\n[ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000\n[ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000\n[ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0\n[ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080\n[ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000\n[ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000\n[ 3106.047957] Call trace:\n[ 3106.049522] try_grab_folio+0x11c/0x188\n[ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0\n[ 3106.055527] follow_page_mask+0x1a0/0x2b8\n[ 3106.058118] __get_user_pages+0xf0/0x348\n[ 3106.060647] faultin_page_range+0xb0/0x360\n[ 3106.063651] do_madvise+0x340/0x598\n\nLet's make huge_pte_lockptr() effectively use the same PT locks as any\ncore-mm page table walker would. Add ptep_lockptr() to obtain the PTE\npage table lock using a pte pointer -- unfortunately we cannot convert\npte_lockptr() because virt_to_page() doesn't work with kmap'ed page tables\nwe can have with CONFIG_HIGHPTE.\n\nHandle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such\nthat when e.g., CONFIG_PGTABLE_LEVELS==2 with\nPGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected. Document\nwhy that works.\n\nThere is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb\nfolio being mapped using two PTE page tables. While hugetlb wants to take\nthe PMD table lock, core-mm would grab the PTE table lock of one of both\nPTE page tables. In such corner cases, we have to make sure that both\nlocks match, which is (fortunately!) currently guaranteed for 8xx as it\ndoes not support SMP and consequently doesn't use split PT locks.\n\n[1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1: Fix data corruption for degraded array with slow disk\n\nread_balance() will avoid reading from slow disks as much as possible,\nhowever, if valid data only lands in slow disks, and a new normal disk\nis still in recovery, unrecovered data can be read:\n\nraid1_read_request\n read_balance\n raid1_should_read_first\n -> return false\n choose_best_rdev\n -> normal disk is not recovered, return -1\n choose_bb_rdev\n -> missing the checking of recovery, return the normal disk\n -> read unrecovered data\n\nRoot cause is that the checking of recovery is missing in\nchoose_bb_rdev(). Hence add such checking to fix the problem.\n\nAlso fix similar problem in choose_slow_rdev().

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a kernel verifier crash in stacksafe()\n\nDaniel Hodges reported a kernel verifier crash when playing with sched-ext.\nFurther investigation shows that the crash is due to invalid memory access\nin stacksafe(). More specifically, it is the following code:\n\n if (exact != NOT_EXACT &&\n old->stack[spi].slot_type[i % BPF_REG_SIZE] !=\n cur->stack[spi].slot_type[i % BPF_REG_SIZE])\n return false;\n\nThe 'i' iterates old->allocated_stack.\nIf cur->allocated_stack < old->allocated_stack the out-of-bound\naccess will happen.\n\nTo fix the issue add 'i >= cur->allocated_stack' check such that if\nthe condition is true, stacksafe() should fail. Otherwise,\ncur->stack[spi].slot_type[i % BPF_REG_SIZE] memory access is legal.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/boot: Avoid possible physmem_info segment corruption\n\nWhen physical memory for the kernel image is allocated it does not\nconsider extra memory required for offsetting the image start to\nmatch it with the lower 20 bits of KASLR virtual base address. That\nmight lead to kernel access beyond its memory range.

In the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/firmware: use dma non-coherent allocator\n\nCurrently, enabling SG_DEBUG in the kernel will cause nouveau to hit a\nBUG() on startup, when the iommu is enabled:\n\nkernel BUG at include/linux/scatterlist.h:187!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30\nHardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019\nRIP: 0010:sg_init_one+0x85/0xa0\nCode: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54\n24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b\n0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00\nRSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b\nRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000\nRBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508\nR13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018\nFS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0\nCall Trace:\n \n ? die+0x36/0x90\n ? do_trap+0xdd/0x100\n ? sg_init_one+0x85/0xa0\n ? do_error_trap+0x65/0x80\n ? sg_init_one+0x85/0xa0\n ? exc_invalid_op+0x50/0x70\n ? sg_init_one+0x85/0xa0\n ? asm_exc_invalid_op+0x1a/0x20\n ? sg_init_one+0x85/0xa0\n nvkm_firmware_ctor+0x14a/0x250 [nouveau]\n nvkm_falcon_fw_ctor+0x42/0x70 [nouveau]\n ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau]\n r535_gsp_oneinit+0xb3/0x15f0 [nouveau]\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? nvkm_udevice_new+0x95/0x140 [nouveau]\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? ktime_get+0x47/0xb0\n\nFix this by using the non-coherent allocator instead, I think there\nmight be a better answer to this, but it involve ripping up some of\nAPIs using sg lists.

In the Linux kernel, the following vulnerability has been resolved:\n\nchar: xillybus: Check USB endpoints when probing device\n\nEnsure, as the driver probes the device, that all endpoints that the\ndriver may attempt to access exist and are of the correct type.\n\nAll XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at\naddress 1. This is verified in xillyusb_setup_base_eps().\n\nOn top of that, a XillyUSB device may have additional Bulk OUT\nendpoints. The information about these endpoints' addresses is deduced\nfrom a data structure (the IDT) that the driver fetches from the device\nwhile probing it. These endpoints are checked in setup_channels().\n\nA XillyUSB device never has more than one IN endpoint, as all data\ntowards the host is multiplexed in this single Bulk IN endpoint. This is\nwhy setup_channels() only checks OUT endpoints.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: only mark 'subflow' endp as available\n\nAdding the following warning ...\n\n WARN_ON_ONCE(msk->pm.local_addr_used == 0)\n\n... before decrementing the local_addr_used counter helped to find a bug\nwhen running the "remove single address" subtest from the mptcp_join.sh\nselftests.\n\nRemoving a 'signal' endpoint will trigger the removal of all subflows\nlinked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with\nrm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used\ncounter, which is wrong in this case because this counter is linked to\n'subflow' endpoints, and here it is a 'signal' endpoint that is being\nremoved.\n\nNow, the counter is decremented, only if the ID is being used outside\nof mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and\nif the ID is not 0 -- local_addr_used is not taking into account these\nones. This marking of the ID as being available, and the decrement is\ndone no matter if a subflow using this ID is currently available,\nbecause the subflow could have been closed before.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: fix validity interception issue when gisa is switched off\n\nWe might run into a SIE validity if gisa has been disabled either via using\nkernel parameter "kvm.use_gisa=0" or by setting the related sysfs\nattribute to N (echo N >/sys/module/kvm/parameters/use_gisa).\n\nThe validity is caused by an invalid value in the SIE control block's\ngisa designation. That happens because we pass the uninitialized gisa\norigin to virt_to_phys() before writing it to the gisa designation.\n\nTo fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0.\nkvm_s390_get_gisa_desc() is used to determine which gisa designation to\nset in the SIE control block. A value of 0 in the gisa designation disables\ngisa usage.\n\nThe issue surfaces in the host kernel with the following kernel message as\nsoon a new kvm guest start is attemted.\n\nkvm: unhandled validity intercept 0x1011\nWARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]\nModules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci]\nCPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6\nHardware name: IBM 3931 A01 701 (LPAR)\nKrnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm])\n R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\nKrnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000\n 000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff\n 000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412\n 000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960\nKrnl Code: 000003d93deb0112: c020fffe7259\tlarl\t%r2,000003d93de7e5c4\n 000003d93deb0118: c0e53fa8beac\tbrasl\t%r14,000003d9bd3c7e70\n #000003d93deb011e: af000000\t\tmc\t0,0\n >000003d93deb0122: a728ffea\t\tlhi\t%r2,-22\n 000003d93deb0126: a7f4fe24\t\tbrc\t15,000003d93deafd6e\n 000003d93deb012a: 9101f0b0\t\ttm\t176(%r15),1\n 000003d93deb012e: a774fe48\t\tbrc\t7,000003d93deafdbe\n 000003d93deb0132: 40a0f0ae\t\tsth\t%r10,174(%r15)\nCall Trace:\n [<000003d93deb0122>] kvm_handle_sie_intercept+0x432/0x4d0 [kvm]\n([<000003d93deb011e>] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm])\n [<000003d93deacc10>] vcpu_post_run+0x1d0/0x3b0 [kvm]\n [<000003d93deaceda>] __vcpu_run+0xea/0x2d0 [kvm]\n [<000003d93dead9da>] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm]\n [<000003d93de93ee0>] kvm_vcpu_ioctl+0x190/0x7c0 [kvm]\n [<000003d9bd728b4e>] vfs_ioctl+0x2e/0x70\n [<000003d9bd72a092>] __s390x_sys_ioctl+0xc2/0xd0\n [<000003d9be0e9222>] __do_syscall+0x1f2/0x2e0\n [<000003d9be0f9a90>] system_call+0x70/0x98\nLast Breaking-Event-Address:\n [<000003d9bd3c7f58>] __warn_printk+0xe8/0xf0

In the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: dcp: fix leak of blob encryption key\n\nTrusted keys unseal the key blob on load, but keep the sealed payload in\nthe blob field so that every subsequent read (export) will simply\nconvert this field to hex and send it to userspace.\n\nWith DCP-based trusted keys, we decrypt the blob encryption key (BEK)\nin the Kernel due hardware limitations and then decrypt the blob payload.\nBEK decryption is done in-place which means that the trusted key blob\nfield is modified and it consequently holds the BEK in plain text.\nEvery subsequent read of that key thus send the plain text BEK instead\nof the encrypted BEK to userspace.\n\nThis issue only occurs when importing a trusted DCP-based key and\nthen exporting it again. This should rarely happen as the common use cases\nare to either create a new trusted key and export it, or import a key\nblob and then just use it without exporting it again.\n\nFix this by performing BEK decryption and encryption in a dedicated\nbuffer. Further always wipe the plain text BEK buffer to prevent leaking\nthe key via uninitialized memory.

In the Linux kernel, the following vulnerability has been resolved:\n\nrtla/osnoise: Prevent NULL dereference in error handling\n\nIf the "tool->data" allocation fails then there is no need to call\nosnoise_free_top() and, in fact, doing so will lead to a NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mana: Fix RX buf alloc_size alignment and atomic op panic\n\nThe MANA driver's RX buffer alloc_size is passed into napi_build_skb() to\ncreate SKB. skb_shinfo(skb) is located at the end of skb, and its alignment\nis affected by the alloc_size passed into napi_build_skb(). The size needs\nto be aligned properly for better performance and atomic operations.\nOtherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic\noperations may panic on the skb_shinfo(skb)->dataref due to alignment fault.\n\nTo fix this bug, add proper alignment to the alloc_size calculation.\n\nSample panic info:\n[ 253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce\n[ 253.300900] Mem abort info:\n[ 253.301760] ESR = 0x0000000096000021\n[ 253.302825] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 253.304268] SET = 0, FnV = 0\n[ 253.305172] EA = 0, S1PTW = 0\n[ 253.306103] FSC = 0x21: alignment fault\nCall trace:\n __skb_clone+0xfc/0x198\n skb_clone+0x78/0xe0\n raw6_local_deliver+0xfc/0x228\n ip6_protocol_deliver_rcu+0x80/0x500\n ip6_input_finish+0x48/0x80\n ip6_input+0x48/0xc0\n ip6_sublist_rcv_finish+0x50/0x78\n ip6_sublist_rcv+0x1cc/0x2b8\n ipv6_list_rcv+0x100/0x150\n __netif_receive_skb_list_core+0x180/0x220\n netif_receive_skb_list_internal+0x198/0x2a8\n __napi_poll+0x138/0x250\n net_rx_action+0x148/0x330\n handle_softirqs+0x12c/0x3a0

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/netfs/fscache_cookie: add missing "n_accesses" check\n\nThis fixes a NULL pointer dereference bug due to a data race which\nlooks like this:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] SMP PTI\n CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43\n Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018\n Workqueue: events_unbound netfs_rreq_write_to_cache_work\n RIP: 0010:cachefiles_prepare_write+0x30/0xa0\n Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10\n RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286\n RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000\n RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438\n RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001\n R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68\n R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00\n FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0\n Call Trace:\n \n ? __die+0x1f/0x70\n ? page_fault_oops+0x15d/0x440\n ? search_module_extables+0xe/0x40\n ? fixup_exception+0x22/0x2f0\n ? exc_page_fault+0x5f/0x100\n ? asm_exc_page_fault+0x22/0x30\n ? cachefiles_prepare_write+0x30/0xa0\n netfs_rreq_write_to_cache_work+0x135/0x2e0\n process_one_work+0x137/0x2c0\n worker_thread+0x2e9/0x400\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xcc/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \n Modules linked in:\n CR2: 0000000000000008\n ---[ end trace 0000000000000000 ]---\n\nThis happened because fscache_cookie_state_machine() was slow and was\nstill running while another process invoked fscache_unuse_cookie();\nthis led to a fscache_cookie_lru_do_one() call, setting the\nFSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by\nfscache_cookie_state_machine(), withdrawing the cookie via\ncachefiles_withdraw_cookie(), clearing cookie->cache_priv.\n\nAt the same time, yet another process invoked\ncachefiles_prepare_write(), which found a NULL pointer in this code\nline:\n\n struct cachefiles_object *object = cachefiles_cres_object(cres);\n\nThe next line crashes, obviously:\n\n struct cachefiles_cache *cache = object->volume->cache;\n\nDuring cachefiles_prepare_write(), the "n_accesses" counter is\nnon-zero (via fscache_begin_operation()). The cookie must not be\nwithdrawn until it drops to zero.\n\nThe counter is checked by fscache_cookie_state_machine() before\nswitching to FSCACHE_COOKIE_STATE_RELINQUISHING and\nFSCACHE_COOKIE_STATE_WITHDRAWING (in "case\nFSCACHE_COOKIE_STATE_FAILED"), but not for\nFSCACHE_COOKIE_STATE_LRU_DISCARDING ("case\nFSCACHE_COOKIE_STATE_ACTIVE").\n\nThis patch adds the missing check. With a non-zero access counter,\nthe function returns and the next fscache_end_cookie_access() call\nwill queue another fscache_cookie_state_machine() call to handle the\nstill-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: mtk_wed: fix use-after-free panic in mtk_wed_setup_tc_block_cb()\n\nWhen there are multiple ap interfaces on one band and with WED on,\nturning the interface down will cause a kernel panic on MT798X.\n\nPreviously, cb_priv was freed in mtk_wed_setup_tc_block() without\nmarking NULL,and mtk_wed_setup_tc_block_cb() didn't check the value, too.\n\nAssign NULL after free cb_priv in mtk_wed_setup_tc_block() and check NULL\nin mtk_wed_setup_tc_block_cb().\n\n----------\nUnable to handle kernel paging request at virtual address 0072460bca32b4f5\nCall trace:\n mtk_wed_setup_tc_block_cb+0x4/0x38\n 0xffffffc0794084bc\n tcf_block_playback_offloads+0x70/0x1e8\n tcf_block_unbind+0x6c/0xc8\n...\n---------

In the Linux kernel, the following vulnerability has been resolved:\n\nvsock: fix recursive ->recvmsg calls\n\nAfter a vsock socket has been added to a BPF sockmap, its prot->recvmsg\nhas been replaced with vsock_bpf_recvmsg(). Thus the following\nrecursiion could happen:\n\nvsock_bpf_recvmsg()\n -> __vsock_recvmsg()\n -> vsock_connectible_recvmsg()\n -> prot->recvmsg()\n -> vsock_bpf_recvmsg() again\n\nWe need to fix it by calling the original ->recvmsg() without any BPF\nsockmap logic in __vsock_recvmsg().

In the Linux kernel, the following vulnerability has been resolved:\n\niommu: Restore lost return in iommu_report_device_fault()\n\nWhen iommu_report_device_fault gets called with a partial fault it is\nsupposed to collect the fault into the group and then return.\n\nInstead the return was accidently deleted which results in trying to\nprocess the fault and an eventual crash.\n\nDeleting the return was a typo, put it back.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Fix out-of-bounds read in `v3d_csd_job_run()`\n\nWhen enabling UBSAN on Raspberry Pi 5, we get the following warning:\n\n[ 387.894977] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/v3d/v3d_sched.c:320:3\n[ 387.903868] index 7 is out of range for type '__u32 [7]'\n[ 387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G WC 6.10.3-v8-16k-numa #151\n[ 387.919166] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)\n[ 387.925961] Workqueue: v3d_csd drm_sched_run_job_work [gpu_sched]\n[ 387.932525] Call trace:\n[ 387.935296] dump_backtrace+0x170/0x1b8\n[ 387.939403] show_stack+0x20/0x38\n[ 387.942907] dump_stack_lvl+0x90/0xd0\n[ 387.946785] dump_stack+0x18/0x28\n[ 387.950301] __ubsan_handle_out_of_bounds+0x98/0xd0\n[ 387.955383] v3d_csd_job_run+0x3a8/0x438 [v3d]\n[ 387.960707] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched]\n[ 387.966862] process_one_work+0x62c/0xb48\n[ 387.971296] worker_thread+0x468/0x5b0\n[ 387.975317] kthread+0x1c4/0x1e0\n[ 387.978818] ret_from_fork+0x10/0x20\n[ 387.983014] ---[ end trace ]---\n\nThis happens because the UAPI provides only seven configuration\nregisters and we are reading the eighth position of this u32 array.\n\nTherefore, fix the out-of-bounds read in `v3d_csd_job_run()` by\naccessing only seven positions on the '__u32 [7]' array. The eighth\nregister exists indeed on V3D 7.1, but it isn't currently used. That\nbeing so, let's guarantee that it remains unused and add a note that it\ncould be set in a future patch.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb/client: avoid possible NULL dereference in cifs_free_subrequest()\n\nClang static checker (scan-build) warning:\n cifsglob.h:line 890, column 3\n Access to field 'ops' results in a dereference of a null pointer.\n\nCommit 519be989717c ("cifs: Add a tracepoint to track credits involved in\nR/W requests") adds a check for 'rdata->server', and let clang throw this\nwarning about NULL dereference.\n\nWhen 'rdata->credits.value != 0 && rdata->server == NULL' happens,\nadd_credits_and_wake_if() will call rdata->server->ops->add_credits().\nThis will cause NULL dereference problem. Add a check for 'rdata->server'\nto avoid NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: prevent concurrent execution of tcp_sk_exit_batch\n\nIts possible that two threads call tcp_sk_exit_batch() concurrently,\nonce from the cleanup_net workqueue, once from a task that failed to clone\na new netns. In the latter case, error unwinding calls the exit handlers\nin reverse order for the 'failed' netns.\n\ntcp_sk_exit_batch() calls tcp_twsk_purge().\nProblem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"),\nthis function picks up twsk in any dying netns, not just the one passed\nin via exit_batch list.\n\nThis means that the error unwind of setup_net() can "steal" and destroy\ntimewait sockets belonging to the exiting netns.\n\nThis allows the netns exit worker to proceed to call\n\nWARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount));\n\nwithout the expected 1 -> 0 transition, which then splats.\n\nAt same time, error unwind path that is also running inet_twsk_purge()\nwill splat as well:\n\nWARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210\n...\n refcount_dec include/linux/refcount.h:351 [inline]\n inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70\n inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221\n inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304\n tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522\n ops_exit_list+0x128/0x180 net/core/net_namespace.c:178\n setup_net+0x714/0xb40 net/core/net_namespace.c:375\n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\n\n... because refcount_dec() of tw_refcount unexpectedly dropped to 0.\n\nThis doesn't seem like an actual bug (no tw sockets got lost and I don't\nsee a use-after-free) but as erroneous trigger of debug check.\n\nAdd a mutex to force strict ordering: the task that calls tcp_twsk_purge()\nblocks other task from doing final _dec_and_test before mutex-owner has\nremoved all tw sockets of dying netns.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible UAF in ip6_xmit()\n\nIf skb_expand_head() returns NULL, skb has been freed\nand the associated dst/idev could also have been freed.\n\nWe must use rcu_read_lock() to prevent a possible UAF.

In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix double DMA unmapping for XDP_REDIRECT\n\nRemove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT\ncode path. This should have been removed when we let the page pool\nhandle the DMA mapping. This bug causes the warning:\n\nWARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100\nCPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu\nHardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024\nRIP: 0010:iommu_dma_unmap_page+0xd5/0x100\nCode: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9\nRSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c\nR10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000\nR13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002\nFS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0\n? show_regs+0x6d/0x80\n? __warn+0x89/0x150\n? iommu_dma_unmap_page+0xd5/0x100\n? report_bug+0x16a/0x190\n? handle_bug+0x51/0xa0\n? exc_invalid_op+0x18/0x80\n? iommu_dma_unmap_page+0xd5/0x100\n? iommu_dma_unmap_page+0x35/0x100\ndma_unmap_page_attrs+0x55/0x220\n? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f\nbnxt_rx_xdp+0x237/0x520 [bnxt_en]\nbnxt_rx_pkt+0x640/0xdd0 [bnxt_en]\n__bnxt_poll_work+0x1a1/0x3d0 [bnxt_en]\nbnxt_poll+0xaa/0x1e0 [bnxt_en]\n__napi_poll+0x33/0x1e0\nnet_rx_action+0x18a/0x2f0

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix missing workqueue destroy in xe_gt_pagefault\n\nOn driver reload we never free up the memory for the pagefault and\naccess counter workqueues. Add those destroy calls here.\n\n(cherry picked from commit 7586fc52b14e0b8edd0d1f8a434e0de2078b7b2b)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Free job before xe_exec_queue_put\n\nFree job depends on job->vm being valid, the last xe_exec_queue_put can\ndestroy the VM. Prevent UAF by freeing job before xe_exec_queue_put.\n\n(cherry picked from commit 32a42c93b74c8ca6d0915ea3eba21bceff53042f)

In the Linux kernel, the following vulnerability has been resolved:\n\nata: pata_macio: Fix DMA table overflow\n\nKolbjørn and Jonáš reported that their 32-bit PowerMacs were crashing\nin pata-macio since commit 09fe2bfa6b83 ("ata: pata_macio: Fix\nmax_segment_size with PAGE_SIZE == 64K").\n\nFor example:\n\n kernel BUG at drivers/ata/pata_macio.c:544!\n Oops: Exception in kernel mode, sig: 5 [#1]\n BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 DEBUG_PAGEALLOC PowerMac\n ...\n NIP pata_macio_qc_prep+0xf4/0x190\n LR pata_macio_qc_prep+0xfc/0x190\n Call Trace:\n 0xc1421660 (unreliable)\n ata_qc_issue+0x14c/0x2d4\n __ata_scsi_queuecmd+0x200/0x53c\n ata_scsi_queuecmd+0x50/0xe0\n scsi_queue_rq+0x788/0xb1c\n __blk_mq_issue_directly+0x58/0xf4\n blk_mq_plug_issue_direct+0x8c/0x1b4\n blk_mq_flush_plug_list.part.0+0x584/0x5e0\n __blk_flush_plug+0xf8/0x194\n __submit_bio+0x1b8/0x2e0\n submit_bio_noacct_nocheck+0x230/0x304\n btrfs_work_helper+0x200/0x338\n process_one_work+0x1a8/0x338\n worker_thread+0x364/0x4c0\n kthread+0x100/0x104\n start_kernel_thread+0x10/0x14\n\nThat commit increased max_segment_size to 64KB, with the justification\nthat the SCSI core was already using that size when PAGE_SIZE == 64KB,\nand that there was existing logic to split over-sized requests.\n\nHowever with a sufficiently large request, the splitting logic causes\neach sg to be split into two commands in the DMA table, leading to\noverflow of the DMA table, triggering the BUG_ON().\n\nWith default settings the bug doesn't trigger, because the request size\nis limited by max_sectors_kb == 1280, however max_sectors_kb can be\nincreased, and apparently some distros do that by default using udev\nrules.\n\nFix the bug for 4KB kernels by reverting to the old max_segment_size.\n\nFor 64KB kernels the sg_tablesize needs to be halved, to allow for the\npossibility that each sg will be split into two.

In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/cpuset: fix panic caused by partcmd_update\n\nWe find a bug as below:\nBUG: unable to handle page fault for address: 00000003\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 358 Comm: bash Tainted: G W I 6.6.0-10893-g60d6\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4\nRIP: 0010:partition_sched_domains_locked+0x483/0x600\nCode: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9\nRSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202\nRAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000002fe80\nRBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000\nR10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002\nR13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000\nFS: 00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0\nCall Trace:\n \n ? show_regs+0x8c/0xa0\n ? __die_body+0x23/0xa0\n ? __die+0x3a/0x50\n ? page_fault_oops+0x1d2/0x5c0\n ? partition_sched_domains_locked+0x483/0x600\n ? search_module_extables+0x2a/0xb0\n ? search_exception_tables+0x67/0x90\n ? kernelmode_fixup_or_oops+0x144/0x1b0\n ? __bad_area_nosemaphore+0x211/0x360\n ? up_read+0x3b/0x50\n ? bad_area_nosemaphore+0x1a/0x30\n ? exc_page_fault+0x890/0xd90\n ? __lock_acquire.constprop.0+0x24f/0x8d0\n ? __lock_acquire.constprop.0+0x24f/0x8d0\n ? asm_exc_page_fault+0x26/0x30\n ? partition_sched_domains_locked+0x483/0x600\n ? partition_sched_domains_locked+0xf0/0x600\n rebuild_sched_domains_locked+0x806/0xdc0\n update_partition_sd_lb+0x118/0x130\n cpuset_write_resmask+0xffc/0x1420\n cgroup_file_write+0xb2/0x290\n kernfs_fop_write_iter+0x194/0x290\n new_sync_write+0xeb/0x160\n vfs_write+0x16f/0x1d0\n ksys_write+0x81/0x180\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x2f25/0x4630\n do_syscall_64+0x44/0xb0\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\nRIP: 0033:0x7f44a553c887\n\nIt can be reproduced with cammands:\ncd /sys/fs/cgroup/\nmkdir test\ncd test/\necho +cpuset > ../cgroup.subtree_control\necho root > cpuset.cpus.partition\ncat /sys/fs/cgroup/cpuset.cpus.effective\n0-3\necho 0-3 > cpuset.cpus // taking away all cpus from root\n\nThis issue is caused by the incorrect rebuilding of scheduling domains.\nIn this scenario, test/cpuset.cpus.partition should be an invalid root\nand should not trigger the rebuilding of scheduling domains. When calling\nupdate_parent_effective_cpumask with partcmd_update, if newmask is not\nnull, it should recheck newmask whether there are cpus is available\nfor parect/cs that has tasks.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm, slub: do not call do_slab_free for kfence object\n\nIn 782f8906f805 the freeing of kfence objects was moved from deep\ninside do_slab_free to the wrapper functions outside. This is a nice\nchange, but unfortunately it missed one spot in __kmem_cache_free_bulk.\n\nThis results in a crash like this:\n\nBUG skbuff_head_cache (Tainted: G S B E ): Padding overwritten. 0xffff88907fea0f00-0xffff88907fea0fff @offset=3840\n\nslab_err (mm/slub.c:1129)\nfree_to_partial_list (mm/slub.c:? mm/slub.c:4036)\nslab_pad_check (mm/slub.c:864 mm/slub.c:1290)\ncheck_slab (mm/slub.c:?)\nfree_to_partial_list (mm/slub.c:3171 mm/slub.c:4036)\nkmem_cache_alloc_bulk (mm/slub.c:? mm/slub.c:4495 mm/slub.c:4586 mm/slub.c:4635)\nnapi_build_skb (net/core/skbuff.c:348 net/core/skbuff.c:527 net/core/skbuff.c:549)\n\nAll the other callers to do_slab_free appear to be ok.\n\nAdd a kfence_free check in __kmem_cache_free_bulk to avoid the crash.

In the Linux kernel, the following vulnerability has been resolved:\n\ntick/broadcast: Move per CPU pointer access into the atomic section\n\nThe recent fix for making the take over of the broadcast timer more\nreliable retrieves a per CPU pointer in preemptible context.\n\nThis went unnoticed as compilers hoist the access into the non-preemptible\nregion where the pointer is actually used. But of course it's valid that\nthe compiler keeps it at the place where the code puts it which rightfully\ntriggers:\n\n BUG: using smp_processor_id() in preemptible [00000000] code:\n caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0\n\nMove it to the actual usage site which is in a non-preemptible region.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mgag200: Bind I2C lifetime to DRM device\n\nManaged cleanup with devm_add_action_or_reset() will release the I2C\nadapter when the underlying Linux device goes away. But the connector\nstill refers to it, so this cleanup leaves behind a stale pointer\nin struct drm_connector.ddc.\n\nBind the lifetime of the I2C adapter to the connector's lifetime by\nusing DRM's managed release. When the DRM device goes away (after\nthe Linux device) DRM will first clean up the connector and then\nclean up the I2C adapter.

In the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_flat: Fix corruption when not offsetting data start\n\nCommit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start")\nintroduced a RISC-V specific variant of the FLAT format which does\nnot allocate any space for the (obsolete) array of shared library\npointers. However, it did not disable the code which initializes the\narray, resulting in the corruption of sizeof(long) bytes before the DATA\nsegment, generally the end of the TEXT segment.\n\nIntroduce MAX_SHARED_LIBS_UPDATE which depends on the state of\nCONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of\nthe shared library pointer region so that it will only be initialized\nif space is reserved for it.

In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix memory leaks and crashes while performing a soft reset\n\nThe second tagged commit introduced a UAF, as it removed restoring\nq_vector->vport pointers after reinitializating the structures.\nThis is due to that all queue allocation functions are performed here\nwith the new temporary vport structure and those functions rewrite\nthe backpointers to the vport. Then, this new struct is freed and\nthe pointers start leading to nowhere.\n\nBut generally speaking, the current logic is very fragile. It claims\nto be more reliable when the system is low on memory, but in fact, it\nconsumes two times more memory as at the moment of running this\nfunction, there are two vports allocated with their queues and vectors.\nMoreover, it claims to prevent the driver from running into "bad state",\nbut in fact, any error during the rebuild leaves the old vport in the\npartially allocated state.\nFinally, if the interface is down when the function is called, it always\nallocates a new queue set, but when the user decides to enable the\ninterface later on, vport_open() allocates them once again, IOW there's\na clear memory leak here.\n\nJust don't allocate a new queue set when performing a reset, that solves\ncrashes and memory leaks. Readd the old queue number and reopen the\ninterface on rollback - that solves limbo states when the device is left\ndisabled and/or without HW queues enabled.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracefs: Use generic inode RCU for synchronizing freeing\n\nWith structure layout randomization enabled for 'struct inode' we need to\navoid overlapping any of the RCU-used / initialized-only-once members,\ne.g. i_lru or i_sb_list to not corrupt related list traversals when making\nuse of the rcu_head.\n\nFor an unlucky structure layout of 'struct inode' we may end up with the\nfollowing splat when running the ftrace selftests:\n\n[<...>] list_del corruption, ffff888103ee2cb0->next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object])\n[<...>] ------------[ cut here ]------------\n[<...>] kernel BUG at lib/list_debug.c:54!\n[<...>] invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n[<...>] CPU: 3 PID: 2550 Comm: mount Tainted: G N 6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65\n[<...>] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n[<...>] RIP: 0010:[] __list_del_entry_valid_or_report+0x138/0x3e0\n[<...>] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff <0f> 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f\n[<...>] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283\n[<...>] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000\n[<...>] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001\n[<...>] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25\n[<...>] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d\n[<...>] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000\n[<...>] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[<...>] RDX: __list_del_entry_valid_or_report+0x108/0x3e0\n[<...>] RSI: __func__.47+0x4340/0x4400\n[<...>] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[<...>] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550]\n[<...>] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550]\n[<...>] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550]\n[<...>] R14: tracefs_inode_cache+0x78/0x4e0 [slab object]\n[<...>] FS: 00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000\n[<...>] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[<...>] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0\n[<...>] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[<...>] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[<...>] ASID: 0003\n[<...>] Stack:\n[<...>] ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0\n[<...>] ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f\n[<...>] 0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392\n[<...>] Call Trace:\n[<...>] \n[<...>] [] ? lock_release+0x175/0x380 fffffe80416afaf0\n[<...>] [] list_lru_del+0x152/0x740 fffffe80416afb48\n[<...>] [] list_lru_del_obj+0x113/0x280 fffffe80416afb88\n[<...>] [] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90\n[<...>] [] iput_final+0x1c4/0x9a0 fffffe80416afbb8\n[<...>] [] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8\n[<...>] [] __dentry_kill+0x23c/0xf00 fffffe80416afc40\n[<...>] [] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48\n[<...>] [] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70\n[<...>] [] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78\n[<...>] [] shrink_dentry_list+0x288/0x760 fffffe80416afc80\n[<...>] [] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8\n[<...>] [] ? debug_smp_processor_id+0x23/0xa0 fffffe80416afce0\n[<...>] [] ? do_one_tre\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix deadlock during RTC update\n\nThere is a deadlock when runtime suspend waits for the flush of RTC work,\nand the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume.\n\nHere is deadlock backtrace:\n\nkworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367\nptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff\n __switch_to+0x1a8/0x2d4\n __schedule+0x684/0xa98\n schedule+0x48/0xc8\n schedule_timeout+0x48/0x170\n do_wait_for_common+0x108/0x1b0\n wait_for_completion+0x44/0x60\n __flush_work+0x39c/0x424\n __cancel_work_sync+0xd8/0x208\n cancel_delayed_work_sync+0x14/0x28\n __ufshcd_wl_suspend+0x19c/0x480\n ufshcd_wl_runtime_suspend+0x3c/0x1d4\n scsi_runtime_suspend+0x78/0xc8\n __rpm_callback+0x94/0x3e0\n rpm_suspend+0x2d4/0x65c\n __pm_runtime_suspend+0x80/0x114\n scsi_runtime_idle+0x38/0x6c\n rpm_idle+0x264/0x338\n __pm_runtime_idle+0x80/0x110\n ufshcd_rtc_work+0x128/0x1e4\n process_one_work+0x26c/0x650\n worker_thread+0x260/0x3d8\n kthread+0x110/0x134\n ret_from_fork+0x10/0x20\n\nSkip updating RTC if RPM state is not RPM_ACTIVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: sc16is7xx: fix TX fifo corruption\n\nSometimes, when a packet is received on channel A at almost the same time\nas a packet is about to be transmitted on channel B, we observe with a\nlogic analyzer that the received packet on channel A is transmitted on\nchannel B. In other words, the Tx buffer data on channel B is corrupted\nwith data from channel A.\n\nThe problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change\nEFR lock to operate on each channels"), which changed the EFR locking to\noperate on each channel instead of chip-wise.\n\nThis commit has introduced a regression, because the EFR lock is used not\nonly to protect the EFR registers access, but also, in a very obscure and\nundocumented way, to protect access to the data buffer, which is shared by\nthe Tx and Rx handlers, but also by each channel of the IC.\n\nFix this regression first by switching to kfifo_out_linear_ptr() in\nsc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.\n\nSecondly, replace the chip-wise Rx buffer with a separate Rx buffer for\neach channel.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mtrr: Check if fixed MTRRs exist before saving them\n\nMTRRs have an obsolete fixed variant for fine grained caching control\nof the 640K-1MB region that uses separate MSRs. This fixed variant has\na separate capability bit in the MTRR capability MSR.\n\nSo far all x86 CPUs which support MTRR have this separate bit set, so it\nwent unnoticed that mtrr_save_state() does not check the capability bit\nbefore accessing the fixed MTRR MSRs.\n\nThough on a CPU that does not support the fixed MTRR capability this\nresults in a #GP. The #GP itself is harmless because the RDMSR fault is\nhandled gracefully, but results in a WARN_ON().\n\nAdd the missing capability check to prevent this.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink: Initialise extack before use in ACKs\n\nAdd missing extack initialisation when ACKing BATCH_BEGIN and BATCH_END.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: gup: stop abusing try_grab_folio\n\nA kernel warning was reported when pinning folio in CMA memory when\nlaunching SEV virtual machine. The splat looks like:\n\n[ 464.325306] WARNING: CPU: 13 PID: 6734 at mm/gup.c:1313 __get_user_pages+0x423/0x520\n[ 464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: loaded Not tainted 6.6.33+ #6\n[ 464.325477] RIP: 0010:__get_user_pages+0x423/0x520\n[ 464.325515] Call Trace:\n[ 464.325520] \n[ 464.325523] ? __get_user_pages+0x423/0x520\n[ 464.325528] ? __warn+0x81/0x130\n[ 464.325536] ? __get_user_pages+0x423/0x520\n[ 464.325541] ? report_bug+0x171/0x1a0\n[ 464.325549] ? handle_bug+0x3c/0x70\n[ 464.325554] ? exc_invalid_op+0x17/0x70\n[ 464.325558] ? asm_exc_invalid_op+0x1a/0x20\n[ 464.325567] ? __get_user_pages+0x423/0x520\n[ 464.325575] __gup_longterm_locked+0x212/0x7a0\n[ 464.325583] internal_get_user_pages_fast+0xfb/0x190\n[ 464.325590] pin_user_pages_fast+0x47/0x60\n[ 464.325598] sev_pin_memory+0xca/0x170 [kvm_amd]\n[ 464.325616] sev_mem_enc_register_region+0x81/0x130 [kvm_amd]\n\nPer the analysis done by yangge, when starting the SEV virtual machine, it\nwill call pin_user_pages_fast(..., FOLL_LONGTERM, ...) to pin the memory. \nBut the page is in CMA area, so fast GUP will fail then fallback to the\nslow path due to the longterm pinnalbe check in try_grab_folio().\n\nThe slow path will try to pin the pages then migrate them out of CMA area.\nBut the slow path also uses try_grab_folio() to pin the page, it will\nalso fail due to the same check then the above warning is triggered.\n\nIn addition, the try_grab_folio() is supposed to be used in fast path and\nit elevates folio refcount by using add ref unless zero. We are guaranteed\nto have at least one stable reference in slow path, so the simple atomic add\ncould be used. The performance difference should be trivial, but the\nmisuse may be confusing and misleading.\n\nRedefined try_grab_folio() to try_grab_folio_fast(), and try_grab_page()\nto try_grab_folio(), and use them in the proper paths. This solves both\nthe abuse and the kernel warning.\n\nThe proper naming makes their usecase more clear and should prevent from\nabusing in the future.\n\npeterx said:\n\n: The user will see the pin fails, for gpu-slow it further triggers the WARN\n: right below that failure (as in the original report):\n: \n: folio = try_grab_folio(page, page_increm - 1,\n: foll_flags);\n: if (WARN_ON_ONCE(!folio)) { <------------------------ here\n: /*\n: * Release the 1st page ref if the\n: * folio is problematic, fail hard.\n: */\n: gup_put_folio(page_folio(page), 1,\n: foll_flags);\n: ret = -EFAULT;\n: goto out;\n: }\n\n[1] https://lore.kernel.org/linux-mm/1719478388-31917-1-git-send-email-yangge1116@126.com/\n\n[shy828301@gmail.com: fix implicit declaration of function try_grab_folio_fast]\n Link: https://lkml.kernel.org/r/CAHbLzkowMSso-4Nufc9hcMehQsK9PNz3OSu-+eniU-2Mm-xjhA@mail.gmail.com

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: intel-vbtn: Protect ACPI notify handler against recursion\n\nSince commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on\nall CPUs") ACPI notify handlers like the intel-vbtn notify_handler() may\nrun on multiple CPU cores racing with themselves.\n\nThis race gets hit on Dell Venue 7140 tablets when undocking from\nthe keyboard, causing the handler to try and register priv->switches_dev\ntwice, as can be seen from the dev_info() message getting logged twice:\n\n[ 83.861800] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event\n[ 83.861858] input: Intel Virtual Switches as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17\n[ 83.861865] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event\n\nAfter which things go seriously wrong:\n[ 83.861872] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17'\n...\n[ 83.861967] kobject: kobject_add_internal failed for input17 with -EEXIST, don't try to register things with the same name in the same directory.\n[ 83.877338] BUG: kernel NULL pointer dereference, address: 0000000000000018\n...\n\nProtect intel-vbtn notify_handler() from racing with itself with a mutex\nto fix this.

In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en : Fix memory out-of-bounds in bnxt_fill_hw_rss_tbl()\n\nA recent commit has modified the code in __bnxt_reserve_rings() to\nset the default RSS indirection table to default only when the number\nof RX rings is changing. While this works for newer firmware that\nrequires RX ring reservations, it causes the regression on older\nfirmware not requiring RX ring resrvations (BNXT_NEW_RM() returns\nfalse).\n\nWith older firmware, RX ring reservations are not required and so\nhw_resc->resv_rx_rings is not always set to the proper value. The\ncomparison:\n\nif (old_rx_rings != bp->hw_resc.resv_rx_rings)\n\nin __bnxt_reserve_rings() may be false even when the RX rings are\nchanging. This will cause __bnxt_reserve_rings() to skip setting\nthe default RSS indirection table to default to match the current\nnumber of RX rings. This may later cause bnxt_fill_hw_rss_tbl() to\nuse an out-of-range index.\n\nWe already have bnxt_check_rss_tbl_no_rmgr() to handle exactly this\nscenario. We just need to move it up in bnxt_need_reserve_rings()\nto be called unconditionally when using older firmware. Without the\nfix, if the TX rings are changing, we'll skip the\nbnxt_check_rss_tbl_no_rmgr() call and __bnxt_reserve_rings() may also\nskip the bnxt_set_dflt_rss_indir_tbl() call for the reason explained\nin the last paragraph. Without setting the default RSS indirection\ntable to default, it causes the regression:\n\nBUG: KASAN: slab-out-of-bounds in __bnxt_hwrm_vnic_set_rss+0xb79/0xe40\nRead of size 2 at addr ffff8881c5809618 by task ethtool/31525\nCall Trace:\n__bnxt_hwrm_vnic_set_rss+0xb79/0xe40\n bnxt_hwrm_vnic_rss_cfg_p5+0xf7/0x460\n __bnxt_setup_vnic_p5+0x12e/0x270\n __bnxt_open_nic+0x2262/0x2f30\n bnxt_open_nic+0x5d/0xf0\n ethnl_set_channels+0x5d4/0xb30\n ethnl_default_set_doit+0x2f1/0x620

In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix UAFs when destroying the queues\n\nThe second tagged commit started sometimes (very rarely, but possible)\nthrowing WARNs from\nnet/core/page_pool.c:page_pool_disable_direct_recycling().\nTurned out idpf frees interrupt vectors with embedded NAPIs *before*\nfreeing the queues making page_pools' NAPI pointers lead to freed\nmemory before these pools are destroyed by libeth.\nIt's not clear whether there are other accesses to the freed vectors\nwhen destroying the queues, but anyway, we usually free queue/interrupt\nvectors only when the queues are destroyed and the NAPIs are guaranteed\nto not be referenced anywhere.\n\nInvert the allocation and freeing logic making queue/interrupt vectors\nbe allocated first and freed last. Vectors don't require queues to be\npresent, so this is safe. Additionally, this change allows to remove\nthat useless queue->q_vector pointer cleanup, as vectors are still\nvalid when freeing the queues (+ both are freed within one function,\nso it's not clear why nullify the pointers at all).

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: drop bad gso csum_start and offset in virtio_net_hdr\n\nTighten csum_start and csum_offset checks in virtio_net_hdr_to_skb\nfor GSO packets.\n\nThe function already checks that a checksum requested with\nVIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets\nthis might not hold for segs after segmentation.\n\nSyzkaller demonstrated to reach this warning in skb_checksum_help\n\n offset = skb_checksum_start_offset(skb);\n ret = -EINVAL;\n if (WARN_ON_ONCE(offset >= skb_headlen(skb)))\n\nBy injecting a TSO packet:\n\nWARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0\n ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774\n ip_finish_output_gso net/ipv4/ip_output.c:279 [inline]\n __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301\n iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82\n ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813\n __gre_xmit net/ipv4/ip_gre.c:469 [inline]\n ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661\n __netdev_start_xmit include/linux/netdevice.h:4850 [inline]\n netdev_start_xmit include/linux/netdevice.h:4864 [inline]\n xmit_one net/core/dev.c:3595 [inline]\n dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611\n __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261\n packet_snd net/packet/af_packet.c:3073 [inline]\n\nThe geometry of the bad input packet at tcp_gso_segment:\n\n[ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0\n[ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244\n[ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0))\n[ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536\nip_summed=3 complete_sw=0 valid=0 level=0)\n\nMitigate with stricter input validation.\n\ncsum_offset: for GSO packets, deduce the correct value from gso_type.\nThis is already done for USO. Extend it to TSO. Let UFO be:\nudp[46]_ufo_fragment ignores these fields and always computes the\nchecksum in software.\n\ncsum_start: finding the real offset requires parsing to the transport\nheader. Do not add a parser, use existing segmentation parsing. Thanks\nto SKB_GSO_DODGY, that also catches bad packets that are hw offloaded.\nAgain test both TSO and USO. Do not test UFO for the above reason, and\ndo not test UDP tunnel offload.\n\nGSO packet are almost always CHECKSUM_PARTIAL. USO packets may be\nCHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit\nfrom devices with no checksum offload"), but then still these fields\nare initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no\nneed to test for ip_summed == CHECKSUM_PARTIAL first.\n\nThis revises an existing fix mentioned in the Fixes tag, which broke\nsmall packets with GSO offload, as detected by kselftests.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: cs-amp-lib: Fix NULL pointer crash if efi.get_variable is NULL\n\nCall efi_rt_services_supported() to check that efi.get_variable exists\nbefore calling it.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Have format file honor EVENT_FILE_FL_FREED\n\nWhen eventfs was introduced, special care had to be done to coordinate the\nfreeing of the file meta data with the files that are exposed to user\nspace. The file meta data would have a ref count that is set when the file\nis created and would be decremented and freed after the last user that\nopened the file closed it. When the file meta data was to be freed, it\nwould set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed,\nand any new references made (like new opens or reads) would fail as it is\nmarked freed. This allowed other meta data to be freed after this flag was\nset (under the event_mutex).\n\nAll the files that were dynamically created in the events directory had a\npointer to the file meta data and would call event_release() when the last\nreference to the user space file was closed. This would be the time that it\nis safe to free the file meta data.\n\nA shortcut was made for the "format" file. It's i_private would point to\nthe "call" entry directly and not point to the file's meta data. This is\nbecause all format files are the same for the same "call", so it was\nthought there was no reason to differentiate them. The other files\nmaintain state (like the "enable", "trigger", etc). But this meant if the\nfile were to disappear, the "format" file would be unaware of it.\n\nThis caused a race that could be trigger via the user_events test (that\nwould create dynamic events and free them), and running a loop that would\nread the user_events format files:\n\nIn one console run:\n\n # cd tools/testing/selftests/user_events\n # while true; do ./ftrace_test; done\n\nAnd in another console run:\n\n # cd /sys/kernel/tracing/\n # while true; do cat events/user_events/__test_event/format; done 2>/dev/null\n\nWith KASAN memory checking, it would trigger a use-after-free bug report\n(which was a real bug). This was because the format file was not checking\nthe file's meta data flag "EVENT_FILE_FL_FREED", so it would access the\nevent that the file meta data pointed to after the event was freed.\n\nAfter inspection, there are other locations that were found to not check\nthe EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a\nnew helper function: event_file_file() that will make sure that the\nevent_mutex is held, and will return NULL if the trace_event_file has the\nEVENT_FILE_FL_FREED flag set. Have the first reference of the struct file\npointer use event_file_file() and check for NULL. Later uses can still use\nthe event_file_data() helper function if the event_mutex is still held and\nwas not released since the event_file_file() call.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: list_lru: fix UAF for memory cgroup\n\nThe mem_cgroup_from_slab_obj() is supposed to be called under rcu lock or\ncgroup_mutex or others which could prevent returned memcg from being\nfreed. Fix it by adding missing rcu read lock.\n\nFound by code inspection.\n\n[songmuchun@bytedance.com: only grab rcu lock when necessary, per Vlastimil]\n Link: https://lkml.kernel.org/r/20240801024603.1865-1-songmuchun@bytedance.com

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tcp: Disable TCP-AO static key after RCU grace period\n\nThe lifetime of TCP-AO static_key is the same as the last\ntcp_ao_info. On the socket destruction tcp_ao_info ceases to be\nwith RCU grace period, while tcp-ao static branch is currently deferred\ndestructed. The static key definition is\n: DEFINE_STATIC_KEY_DEFERRED_FALSE(tcp_ao_needed, HZ);\n\nwhich means that if RCU grace period is delayed by more than a second\nand tcp_ao_needed is in the process of disablement, other CPUs may\nyet see tcp_ao_info which atent dead, but soon-to-be.\nAnd that breaks the assumption of static_key_fast_inc_not_disabled().\n\nSee the comment near the definition:\n> * The caller must make sure that the static key can't get disabled while\n> * in this function. It doesn't patch jump labels, only adds a user to\n> * an already enabled static key.\n\nOriginally it was introduced in commit eb8c507296f6 ("jump_label:\nPrevent key->enabled int overflow"), which is needed for the atomic\ncontexts, one of which would be the creation of a full socket from a\nrequest socket. In that atomic context, it's known by the presence\nof the key (md5/ao) that the static branch is already enabled.\nSo, the ref counter for that static branch is just incremented\ninstead of holding the proper mutex.\nstatic_key_fast_inc_not_disabled() is just a helper for such usage\ncase. But it must not be used if the static branch could get disabled\nin parallel as it's not protected by jump_label_mutex and as a result,\nraces with jump_label_update() implementation details.\n\nHappened on netdev test-bot[1], so not a theoretical issue:\n\n[] jump_label: Fatal kernel bug, unexpected op at tcp_inbound_hash+0x1a7/0x870 [ffffffffa8c4e9b7] (eb 50 0f 1f 44 != 66 90 0f 1f 00)) size:2 type:1\n[] ------------[ cut here ]------------\n[] kernel BUG at arch/x86/kernel/jump_label.c:73!\n[] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\n[] CPU: 3 PID: 243 Comm: kworker/3:3 Not tainted 6.10.0-virtme #1\n[] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[] Workqueue: events jump_label_update_timeout\n[] RIP: 0010:__jump_label_patch+0x2f6/0x350\n...\n[] Call Trace:\n[] \n[] arch_jump_label_transform_queue+0x6c/0x110\n[] __jump_label_update+0xef/0x350\n[] __static_key_slow_dec_cpuslocked.part.0+0x3c/0x60\n[] jump_label_update_timeout+0x2c/0x40\n[] process_one_work+0xe3b/0x1670\n[] worker_thread+0x587/0xce0\n[] kthread+0x28a/0x350\n[] ret_from_fork+0x31/0x70\n[] ret_from_fork_asm+0x1a/0x30\n[] \n[] Modules linked in: veth\n[] ---[ end trace 0000000000000000 ]---\n[] RIP: 0010:__jump_label_patch+0x2f6/0x350\n\n[1]: https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/696681/5-connect-deny-ipv6/stderr

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: change DMA direction while mapping reinjected packets\n\nFor fragmented packets, ath12k reassembles each fragment as a normal\npacket and then reinjects it into HW ring. In this case, the DMA\ndirection should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise,\nan invalid payload may be reinjected into the HW and\nsubsequently delivered to the host.\n\nGiven that arbitrary memory can be allocated to the skb buffer,\nknowledge about the data contained in the reinjected buffer is lacking.\nConsequently, there’s a risk of private information being leaked.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Fix input error path memory access\n\nWhen there is a misconfiguration of input state slow path\nKASAN report error. Fix this error.\nwest login:\n[ 52.987278] eth1: renamed from veth11\n[ 53.078814] eth1: renamed from veth21\n[ 53.181355] eth1: renamed from veth31\n[ 54.921702] ==================================================================\n[ 54.922602] BUG: KASAN: wild-memory-access in xfrmi_rcv_cb+0x2d/0x295\n[ 54.923393] Read of size 8 at addr 6b6b6b6b00000000 by task ping/512\n[ 54.924169]\n[ 54.924386] CPU: 0 PID: 512 Comm: ping Not tainted 6.9.0-08574-gcd29a4313a1b #25\n[ 54.925290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 54.926401] Call Trace:\n[ 54.926731] \n[ 54.927009] dump_stack_lvl+0x2a/0x3b\n[ 54.927478] kasan_report+0x84/0xa6\n[ 54.927930] ? xfrmi_rcv_cb+0x2d/0x295\n[ 54.928410] xfrmi_rcv_cb+0x2d/0x295\n[ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e\n[ 54.929354] xfrm4_rcv_cb+0x46/0x5e\n[ 54.929804] xfrm_rcv_cb+0x7e/0xa1\n[ 54.930240] xfrm_input+0x1b3a/0x1b96\n[ 54.930715] ? xfrm_offload+0x41/0x41\n[ 54.931182] ? raw_rcv+0x292/0x292\n[ 54.931617] ? nf_conntrack_confirm+0xa2/0xa2\n[ 54.932158] ? skb_sec_path+0xd/0x3f\n[ 54.932610] ? xfrmi_input+0x90/0xce\n[ 54.933066] xfrm4_esp_rcv+0x33/0x54\n[ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2\n[ 54.934089] ip_local_deliver_finish+0x110/0x120\n[ 54.934659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2\n[ 54.935248] NF_HOOK.constprop.0+0xf8/0x138\n[ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68\n[ 54.936317] ? secure_tcpv6_ts_off+0x23/0x168\n[ 54.936859] ? ip_protocol_deliver_rcu+0x1b2/0x1b2\n[ 54.937454] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d\n[ 54.938135] NF_HOOK.constprop.0+0xf8/0x138\n[ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68\n[ 54.939220] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d\n[ 54.939904] ? ip_local_deliver_finish+0x120/0x120\n[ 54.940497] __netif_receive_skb_one_core+0xc9/0x107\n[ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2\n[ 54.941771] ? blk_mq_start_stopped_hw_queues+0xc7/0xf9\n[ 54.942413] ? blk_mq_start_stopped_hw_queue+0x38/0x38\n[ 54.943044] ? virtqueue_get_buf_ctx+0x295/0x46b\n[ 54.943618] process_backlog+0xb3/0x187\n[ 54.944102] __napi_poll.constprop.0+0x57/0x1a7\n[ 54.944669] net_rx_action+0x1cb/0x380\n[ 54.945150] ? __napi_poll.constprop.0+0x1a7/0x1a7\n[ 54.945744] ? vring_new_virtqueue+0x17a/0x17a\n[ 54.946300] ? note_interrupt+0x2cd/0x367\n[ 54.946805] handle_softirqs+0x13c/0x2c9\n[ 54.947300] do_softirq+0x5f/0x7d\n[ 54.947727] \n[ 54.948014] \n[ 54.948300] __local_bh_enable_ip+0x48/0x62\n[ 54.948832] __neigh_event_send+0x3fd/0x4ca\n[ 54.949361] neigh_resolve_output+0x1e/0x210\n[ 54.949896] ip_finish_output2+0x4bf/0x4f0\n[ 54.950410] ? __ip_finish_output+0x171/0x1b8\n[ 54.950956] ip_send_skb+0x25/0x57\n[ 54.951390] raw_sendmsg+0xf95/0x10c0\n[ 54.951850] ? check_new_pages+0x45/0x71\n[ 54.952343] ? raw_hash_sk+0x21b/0x21b\n[ 54.952815] ? kernel_init_pages+0x42/0x51\n[ 54.953337] ? prep_new_page+0x44/0x51\n[ 54.953811] ? get_page_from_freelist+0x72b/0x915\n[ 54.954390] ? signal_pending_state+0x77/0x77\n[ 54.954936] ? preempt_count_sub+0x14/0xb3\n[ 54.955450] ? __might_resched+0x8a/0x240\n[ 54.955951] ? __might_sleep+0x25/0xa0\n[ 54.956424] ? first_zones_zonelist+0x2c/0x43\n[ 54.956977] ? __rcu_read_lock+0x2d/0x3a\n[ 54.957476] ? __pte_offset_map+0x32/0xa4\n[ 54.957980] ? __might_resched+0x8a/0x240\n[ 54.958483] ? __might_sleep+0x25/0xa0\n[ 54.958963] ? inet_send_prepare+0x54/0x54\n[ 54.959478] ? sock_sendmsg_nosec+0x42/0x6c\n[ 54.960000] sock_sendmsg_nosec+0x42/0x6c\n[ 54.960502] __sys_sendto+0x15d/0x1cc\n[ 54.960966] ? __x64_sys_getpeername+0x44/0x44\n[ 54.961522] ? __handle_mm_fault+0x679/0xae4\n[ 54.962068] ? find_vma+0x6b/0x\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pci: ivtv: Add check for DMA map result\n\nIn case DMA fails, 'dma->SG_length' is 0. This value is later used to\naccess 'dma->SGarray[dma->SG_length - 1]', which will cause out of\nbounds access.\n\nAdd check to return early on invalid value. Adjust warnings accordingly.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup()\n\nAvoid large backtrace, it is sufficient to warn the user that there has\nbeen a link problem. Either the link has failed and the system is in need\nof maintenance, or the link continues to work and user has been informed.\nThe message from the warning can be looked up in the sources.\n\nThis makes an actual link issue less verbose.\n\nFirst of all, this controller has a limitation in that the controller\ndriver has to assist the hardware with transition to L1 link state by\nwriting L1IATN to PMCTRL register, the L1 and L0 link state switching\nis not fully automatic on this controller.\n\nIn case of an ASMedia ASM1062 PCIe SATA controller which does not support\nASPM, on entry to suspend or during platform pm_test, the SATA controller\nenters D3hot state and the link enters L1 state. If the SATA controller\nwakes up before rcar_pcie_wakeup() was called and returns to D0, the link\nreturns to L0 before the controller driver even started its transition to\nL1 link state. At this point, the SATA controller did send an PM_ENTER_L1\nDLLP to the PCIe controller and the PCIe controller received it, and the\nPCIe controller did set PMSR PMEL1RX bit.\n\nOnce rcar_pcie_wakeup() is called, if the link is already back in L0 state\nand PMEL1RX bit is set, the controller driver has no way to determine if\nit should perform the link transition to L1 state, or treat the link as if\nit is in L0 state. Currently the driver attempts to perform the transition\nto L1 link state unconditionally, which in this specific case fails with a\nPMSR L1FAEG poll timeout, however the link still works as it is already\nback in L0 state.\n\nReduce this warning verbosity. In case the link is really broken, the\nrcar_pcie_config_access() would fail, otherwise it will succeed and any\nsystem with this controller and ASM1062 can suspend without generating\na backtrace.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: Clean up error handling in vpci_scan_bus()\n\nSmatch complains about inconsistent NULL checking in vpci_scan_bus():\n\n drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021)\n\nInstead of printing an error message and then crashing we should return\nan error code and clean up.\n\nAlso the NULL check is reversed so it prints an error for success\ninstead of failure.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Fix null pointer dereference in __sev_snp_shutdown_locked\n\nFix a null pointer dereference induced by DEBUG_TEST_DRIVER_REMOVE.\nReturn from __sev_snp_shutdown_locked() if the psp_device or the\nsev_device structs are not initialized. Without the fix, the driver will\nproduce the following splat:\n\n ccp 0000:55:00.5: enabling device (0000 -> 0002)\n ccp 0000:55:00.5: sev enabled\n ccp 0000:55:00.5: psp enabled\n BUG: kernel NULL pointer dereference, address: 00000000000000f0\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI\n CPU: 262 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1+ #29\n RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150\n Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83\n RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286\n RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808\n RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0\n R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8\n R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000\n FS: 0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0\n PKRU: 55555554\n Call Trace:\n \n ? __die_body+0x6f/0xb0\n ? __die+0xcc/0xf0\n ? page_fault_oops+0x330/0x3a0\n ? save_trace+0x2a5/0x360\n ? do_user_addr_fault+0x583/0x630\n ? exc_page_fault+0x81/0x120\n ? asm_exc_page_fault+0x2b/0x30\n ? __sev_snp_shutdown_locked+0x2e/0x150\n __sev_firmware_shutdown+0x349/0x5b0\n ? pm_runtime_barrier+0x66/0xe0\n sev_dev_destroy+0x34/0xb0\n psp_dev_destroy+0x27/0x60\n sp_destroy+0x39/0x90\n sp_pci_remove+0x22/0x60\n pci_device_remove+0x4e/0x110\n really_probe+0x271/0x4e0\n __driver_probe_device+0x8f/0x160\n driver_probe_device+0x24/0x120\n __driver_attach+0xc7/0x280\n ? driver_attach+0x30/0x30\n bus_for_each_dev+0x10d/0x130\n driver_attach+0x22/0x30\n bus_add_driver+0x171/0x2b0\n ? unaccepted_memory_init_kdump+0x20/0x20\n driver_register+0x67/0x100\n __pci_register_driver+0x83/0x90\n sp_pci_init+0x22/0x30\n sp_mod_init+0x13/0x30\n do_one_initcall+0xb8/0x290\n ? sched_clock_noinstr+0xd/0x10\n ? local_clock_noinstr+0x3e/0x100\n ? stack_depot_save_flags+0x21e/0x6a0\n ? local_clock+0x1c/0x60\n ? stack_depot_save_flags+0x21e/0x6a0\n ? sched_clock_noinstr+0xd/0x10\n ? local_clock_noinstr+0x3e/0x100\n ? __lock_acquire+0xd90/0xe30\n ? sched_clock_noinstr+0xd/0x10\n ? local_clock_noinstr+0x3e/0x100\n ? __create_object+0x66/0x100\n ? local_clock+0x1c/0x60\n ? __create_object+0x66/0x100\n ? parameq+0x1b/0x90\n ? parse_one+0x6d/0x1d0\n ? parse_args+0xd7/0x1f0\n ? do_initcall_level+0x180/0x180\n do_initcall_level+0xb0/0x180\n do_initcalls+0x60/0xa0\n ? kernel_init+0x1f/0x1d0\n do_basic_setup+0x41/0x50\n kernel_init_freeable+0x1ac/0x230\n ? rest_init+0x1f0/0x1f0\n kernel_init+0x1f/0x1d0\n ? rest_init+0x1f0/0x1f0\n ret_from_fork+0x3d/0x50\n ? rest_init+0x1f0/0x1f0\n ret_from_fork_asm+0x11/0x20\n \n Modules linked in:\n CR2: 00000000000000f0\n ---[ end trace 0000000000000000 ]---\n RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150\n Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83\n RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286\n RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000\n RDX: 0000000\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nvhost/vsock: always initialize seqpacket_allow\n\nThere are two issues around seqpacket_allow:\n1. seqpacket_allow is not initialized when socket is\n created. Thus if features are never set, it will be\n read uninitialized.\n2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,\n then seqpacket_allow will not be cleared appropriately\n (existing apps I know about don't usually do this but\n it's legal and there's no way to be sure no one relies\n on this).\n\nTo fix:\n - initialize seqpacket_allow after allocation\n - set it unconditionally in set_features

In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix event leak upon exit\n\nWhen a task is scheduled out, pending sigtrap deliveries are deferred\nto the target task upon resume to userspace via task_work.\n\nHowever failures while adding an event's callback to the task_work\nengine are ignored. And since the last call for events exit happen\nafter task work is eventually closed, there is a small window during\nwhich pending sigtrap can be queued though ignored, leaking the event\nrefcount addition such as in the following scenario:\n\n TASK A\n -----\n\n do_exit()\n exit_task_work(tsk);\n\n \n perf_event_overflow()\n event->pending_sigtrap = pending_id;\n irq_work_queue(&event->pending_irq);\n \n =========> PREEMPTION: TASK A -> TASK B\n event_sched_out()\n event->pending_sigtrap = 0;\n atomic_long_inc_not_zero(&event->refcount)\n // FAILS: task work has exited\n task_work_add(&event->pending_task)\n [...]\n \n perf_pending_irq()\n // early return: event->oncpu = -1\n \n [...]\n =========> TASK B -> TASK A\n perf_event_exit_task(tsk)\n perf_event_exit_event()\n free_event()\n WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1)\n // leak event due to unexpected refcount == 2\n\nAs a result the event is never released while the task exits.\n\nFix this with appropriate task_work_add()'s error handling.

In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix event leak upon exec and file release\n\nThe perf pending task work is never waited upon the matching event\nrelease. In the case of a child event, released via free_event()\ndirectly, this can potentially result in a leaked event, such as in the\nfollowing scenario that doesn't even require a weak IRQ work\nimplementation to trigger:\n\nschedule()\n prepare_task_switch()\n=======> \n perf_event_overflow()\n event->pending_sigtrap = ...\n irq_work_queue(&event->pending_irq)\n<======= \n perf_event_task_sched_out()\n event_sched_out()\n event->pending_sigtrap = 0;\n atomic_long_inc_not_zero(&event->refcount)\n task_work_add(&event->pending_task)\n finish_lock_switch()\n=======> \n perf_pending_irq()\n //do nothing, rely on pending task work\n<======= \n\nbegin_new_exec()\n perf_event_exit_task()\n perf_event_exit_event()\n // If is child event\n free_event()\n WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1)\n // event is leaked\n\nSimilar scenarios can also happen with perf_event_remove_on_exec() or\nsimply against concurrent perf_event_release().\n\nFix this with synchonizing against the possibly remaining pending task\nwork while freeing the event, just like is done with remaining pending\nIRQ work. This means that the pending task callback neither need nor\nshould hold a reference to the event, preventing it from ever beeing\nfreed.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv/purgatory: align riscv_kernel_entry\n\nWhen alignment handling is delegated to the kernel, everything must be\nword-aligned in purgatory, since the trap handler is then set to the\nkexec one. Without the alignment, hitting the exception would\nultimately crash. On other occasions, the kernel's handler would take\ncare of exceptions.\nThis has been tested on a JH7110 SoC with oreboot and its SBI delegating\nunaligned access exceptions and the kernel configured to handle them.