No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\njfs: fix invalid free of JFS_IP(ipimap)->i_imap in diUnmount\nsyzbot found an invalid-free in diUnmount:\nBUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline]\nBUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674\nFree of addr ffff88806f410000 by task syz-executor131/3632\nCPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nCall Trace:\n\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106\nprint_address_description+0x74/0x340 mm/kasan/report.c:284\nprint_report+0x107/0x1f0 mm/kasan/report.c:395\nkasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460\n____kasan_slab_free+0xfb/0x120\nkasan_slab_free include/linux/kasan.h:177 [inline]\nslab_free_hook mm/slub.c:1724 [inline]\nslab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750\nslab_free mm/slub.c:3661 [inline]\n__kmem_cache_free+0x71/0x110 mm/slub.c:3674\ndiUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195\njfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63\njfs_put_super+0x86/0x190 fs/jfs/super.c:194\ngeneric_shutdown_super+0x130/0x310 fs/super.c:492\nkill_block_super+0x79/0xd0 fs/super.c:1428\ndeactivate_locked_super+0xa7/0xf0 fs/super.c:332\ncleanup_mnt+0x494/0x520 fs/namespace.c:1186\ntask_work_run+0x243/0x300 kernel/task_work.c:179\nexit_task_work include/linux/task_work.h:38 [inline]\ndo_exit+0x664/0x2070 kernel/exit.c:820\ndo_group_exit+0x1fd/0x2b0 kernel/exit.c:950\n__do_sys_exit_group kernel/exit.c:961 [inline]\n__se_sys_exit_group kernel/exit.c:959 [inline]\n__x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n[...]\nJFS_IP(ipimap)->i_imap is not setting to NULL after free in diUnmount.\nIf jfs_remount() free JFS_IP(ipimap)->i_imap but then failed at diMount().\nJFS_IP(ipimap)->i_imap will be freed once again.\nFix this problem by setting JFS_IP(ipimap)->i_imap to NULL after free.

In the Linux kernel, the following vulnerability has been resolved:\nscsi: qla2xxx: Fix deletion race condition\nSystem crash when using debug kernel due to link list corruption. The cause\nof the link list corruption is due to session deletion was allowed to queue\nup twice. Here's the internal trace that show the same port was allowed to\ndouble queue for deletion on different cpu.\n20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1\n20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1\nMove the clearing/setting of deleted flag lock.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\ndax: Fix dax_mapping_release() use after free\nA CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax region\nprovider (like modprobe -r dax_hmem) yields:\nkobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000)\n[..]\nDEBUG_LOCKS_WARN_ON(1)\nWARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260\n[..]\nRIP: 0010:__lock_acquire+0x9fc/0x2260\n[..]\nCall Trace:\n\n[..]\nlock_acquire+0xd4/0x2c0\n? ida_free+0x62/0x130\n_raw_spin_lock_irqsave+0x47/0x70\n? ida_free+0x62/0x130\nida_free+0x62/0x130\ndax_mapping_release+0x1f/0x30\ndevice_release+0x36/0x90\nkobject_delayed_cleanup+0x46/0x150\nDue to attempting ida_free() on an ida object that has already been\nfreed. Devices typically only hold a reference on their parent while\nregistered. If a child needs a parent object to complete its release it\nneeds to hold a reference that it drops from its release callback.\nArrange for a dax_mapping to pin its parent dev_dax instance until\ndax_mapping_release().

In the Linux kernel, the following vulnerability has been resolved:\nhwmon: (coretemp) Simplify platform device handling\nCoretemp's platform driver is unconventional. All the real work is done\nglobally by the initcall and CPU hotplug notifiers, while the "driver"\neffectively just wraps an allocation and the registration of the hwmon\ninterface in a long-winded round-trip through the driver core. The whole\nlogic of dynamically creating and destroying platform devices to bring\nthe interfaces up and down is error prone, since it assumes\nplatform_device_add() will synchronously bind the driver and set drvdata\nbefore it returns, thus results in a NULL dereference if drivers_autoprobe\nis turned off for the platform bus. Furthermore, the unusual approach of\ndoing that from within a CPU hotplug notifier, already commented in the\ncode that it deadlocks suspend, also causes lockdep issues for other\ndrivers or subsystems which may want to legitimately register a CPU\nhotplug notifier from a platform bus notifier.\nAll of these issues can be solved by ripping this unusual behaviour out\ncompletely, simply tying the platform devices to the lifetime of the\nmodule itself, and directly managing the hwmon interfaces from the\nhotplug notifiers. There is a slight user-visible change in that\n/sys/bus/platform/drivers/coretemp will no longer appear, and\n/sys/devices/platform/coretemp.n will remain present if package n is\nhotplugged off, but hwmon users should really only be looking for the\npresence of the hwmon interfaces, whose behaviour remains unchanged.

In the Linux kernel, the following vulnerability has been resolved:\nipmi_si: fix a memleak in try_smi_init()\nKmemleak reported the following leak info in try_smi_init():\nunreferenced object 0xffff00018ecf9400 (size 1024):\ncomm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s)\nbacktrace:\n[<000000004ca5b312>] __kmalloc+0x4b8/0x7b0\n[<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si]\n[<000000006460d325>] 0xffff800081b10148\n[<0000000039206ea5>] do_one_initcall+0x64/0x2a4\n[<00000000601399ce>] do_init_module+0x50/0x300\n[<000000003c12ba3c>] load_module+0x7a8/0x9e0\n[<00000000c246fffe>] __se_sys_init_module+0x104/0x180\n[<00000000eea99093>] __arm64_sys_init_module+0x24/0x30\n[<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250\n[<0000000070f4f8b7>] do_el0_svc+0x48/0xe0\n[<000000005a05337f>] el0_svc+0x24/0x3c\n[<000000005eb248d6>] el0_sync_handler+0x160/0x164\n[<0000000030a59039>] el0_sync+0x160/0x180\nThe problem was that when an error occurred before handlers registration\nand after allocating `new_smi->si_sm`, the variable wouldn't be freed in\nthe error handling afterwards since `shutdown_smi()` hadn't been\nregistered yet. Fix it by adding a `kfree()` in the error handling path\nin `try_smi_init()`.

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

In the Linux kernel, the following vulnerability has been resolved:\nscsi: Revert "scsi: core: Do not increase scsi_device's iorequest_cnt if dispatch failed"\nThe "atomic_inc(&cmd->device->iorequest_cnt)" in scsi_queue_rq() would\ncause kernel panic because cmd->device may be freed after returning from\nscsi_dispatch_cmd().\nThis reverts commit cfee29ffb45b1c9798011b19d454637d1b0fe87d.

In the Linux kernel, the following vulnerability has been resolved:\nnilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread()\nThe finalization of nilfs_segctor_thread() can race with\nnilfs_segctor_kill_thread() which terminates that thread, potentially\ncausing a use-after-free BUG as KASAN detected.\nAt the end of nilfs_segctor_thread(), it assigns NULL to "sc_task" member\nof "struct nilfs_sc_info" to indicate the thread has finished, and then\nnotifies nilfs_segctor_kill_thread() of this using waitqueue\n"sc_wait_task" on the struct nilfs_sc_info.\nHowever, here, immediately after the NULL assignment to "sc_task", it is\npossible that nilfs_segctor_kill_thread() will detect it and return to\ncontinue the deallocation, freeing the nilfs_sc_info structure before the\nthread does the notification.\nThis fixes the issue by protecting the NULL assignment to "sc_task" and\nits notification, with spinlock "sc_state_lock" of the struct\nnilfs_sc_info. Since nilfs_segctor_kill_thread() does a final check to\nsee if "sc_task" is NULL with "sc_state_lock" locked, this can eliminate\nthe race.

In the Linux kernel, the following vulnerability has been resolved:\nALSA: ymfpci: Fix BUG_ON in probe function\nThe snd_dma_buffer.bytes field now contains the aligned size, which this\nsnd_BUG_ON() did not account for, resulting in the following:\n[ 9.625915] ------------[ cut here ]------------\n[ 9.633440] WARNING: CPU: 0 PID: 126 at sound/pci/ymfpci/ymfpci_main.c:2168 snd_ymfpci_create+0x681/0x698 [snd_ymfpci]\n[ 9.648926] Modules linked in: snd_ymfpci(+) snd_intel_dspcfg kvm(+) snd_intel_sdw_acpi snd_ac97_codec snd_mpu401_uart snd_opl3_lib irqbypass snd_hda_codec gameport snd_rawmidi crct10dif_pclmul crc32_pclmul cfg80211 snd_hda_core polyval_clmulni polyval_generic gf128mul snd_seq_device ghash_clmulni_intel snd_hwdep ac97_bus sha512_ssse3 rfkill snd_pcm aesni_intel tg3 snd_timer crypto_simd snd mxm_wmi libphy cryptd k10temp fam15h_power pcspkr soundcore sp5100_tco wmi acpi_cpufreq mac_hid dm_multipath sg loop fuse dm_mod bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi firewire_ohci crc32c_intel firewire_core xhci_pci crc_itu_t pata_via xhci_pci_renesas floppy\n[ 9.711849] CPU: 0 PID: 126 Comm: kworker/0:2 Not tainted 6.1.21-1-lts #1 08d2e5ece03136efa7c6aeea9a9c40916b1bd8da\n[ 9.722200] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./990FX Extreme4, BIOS P2.70 06/05/2014\n[ 9.732204] Workqueue: events work_for_cpu_fn\n[ 9.736580] RIP: 0010:snd_ymfpci_create+0x681/0x698 [snd_ymfpci]\n[ 9.742594] Code: 8c c0 4c 89 e2 48 89 df 48 c7 c6 92 c6 8c c0 e8 15 d0 e9 ff 48 83 c4 08 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d3 7a 33 e3 <0f> 0b e9 cb fd ff ff 41 bd fb ff ff ff eb db 41 bd f4 ff ff ff eb\n[ 9.761358] RSP: 0018:ffffab64804e7da0 EFLAGS: 00010287\n[ 9.766594] RAX: ffff8fa2df06c400 RBX: ffff8fa3073a8000 RCX: ffff8fa303fbc4a8\n[ 9.773734] RDX: ffff8fa2df06d000 RSI: 0000000000000010 RDI: 0000000000000020\n[ 9.780876] RBP: ffff8fa300b5d0d0 R08: ffff8fa3073a8e50 R09: 00000000df06bf00\n[ 9.788018] R10: ffff8fa2df06bf00 R11: 00000000df068200 R12: ffff8fa3073a8918\n[ 9.795159] R13: 0000000000000000 R14: 0000000000000080 R15: ffff8fa2df068200\n[ 9.802317] FS: 0000000000000000(0000) GS:ffff8fa9fec00000(0000) knlGS:0000000000000000\n[ 9.810414] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 9.816158] CR2: 000055febaf66500 CR3: 0000000101a2e000 CR4: 00000000000406f0\n[ 9.823301] Call Trace:\n[ 9.825747] \n[ 9.827889] snd_card_ymfpci_probe+0x194/0x950 [snd_ymfpci b78a5fe64b5663a6390a909c67808567e3e73615]\n[ 9.837030] ? finish_task_switch.isra.0+0x90/0x2d0\n[ 9.841918] local_pci_probe+0x45/0x80\n[ 9.845680] work_for_cpu_fn+0x1a/0x30\n[ 9.849431] process_one_work+0x1c7/0x380\n[ 9.853464] worker_thread+0x1af/0x390\n[ 9.857225] ? rescuer_thread+0x3b0/0x3b0\n[ 9.861254] kthread+0xde/0x110\n[ 9.864414] ? kthread_complete_and_exit+0x20/0x20\n[ 9.869210] ret_from_fork+0x22/0x30\n[ 9.872792] \n[ 9.874985] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\nnfsd: clean up potential nfsd_file refcount leaks in COPY codepath\nThere are two different flavors of the nfsd4_copy struct. One is\nembedded in the compound and is used directly in synchronous copies. The\nother is dynamically allocated, refcounted and tracked in the client\nstruture. For the embedded one, the cleanup just involves releasing any\nnfsd_files held on its behalf. For the async one, the cleanup is a bit\nmore involved, and we need to dequeue it from lists, unhash it, etc.\nThere is at least one potential refcount leak in this code now. If the\nkthread_create call fails, then both the src and dst nfsd_files in the\noriginal nfsd4_copy object are leaked.\nThe cleanup in this codepath is also sort of weird. In the async copy\ncase, we'll have up to four nfsd_file references (src and dst for both\nflavors of copy structure). They are both put at the end of\nnfsd4_do_async_copy, even though the ones held on behalf of the embedded\none outlive that structure.\nChange it so that we always clean up the nfsd_file refs held by the\nembedded copy structure before nfsd4_copy returns. Rework\ncleanup_async_copy to handle both inter and intra copies. Eliminate\nnfsd4_cleanup_intra_ssc since it now becomes a no-op.

In the Linux kernel, the following vulnerability has been resolved:\ndrm: amd: display: Fix memory leakage\nThis commit fixes memory leakage in dc_construct_ctx() function.

In the Linux kernel, the following vulnerability has been resolved:\ndm integrity: call kmem_cache_destroy() in dm_integrity_init() error path\nOtherwise the journal_io_cache will leak if dm_register_target() fails.

In the Linux kernel, the following vulnerability has been resolved:\nscsi: qla2xxx: Avoid fcport pointer dereference\nKlocwork reported warning of NULL pointer may be dereferenced. The routine\nexits when sa_ctl is NULL and fcport is allocated after the exit call thus\ncausing NULL fcport pointer to dereference at the time of exit.\nTo avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: ath11k: fix memory leak in WMI firmware stats\nMemory allocated for firmware pdev, vdev and beacon statistics\nare not released during rmmod.\nFix it by calling ath11k_fw_stats_free() function before hardware\nunregister.\nWhile at it, avoid calling ath11k_fw_stats_free() while processing\nthe firmware stats received in the WMI event because the local list\nis getting spliced and reinitialised and hence there are no elements\nin the list after splicing.\nTested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\nbonding: do not assume skb mac_header is set\nDrivers must not assume in their ndo_start_xmit() that\nskbs have their mac_header set. skb->data is all what is needed.\nbonding seems to be one of the last offender as caught by syzbot:\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]\nWARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470\nModules linked in:\nCPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023\nRIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]\nRIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]\nRIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]\nRIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]\nRIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]\nRIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]\nRIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470\nCode: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe <0f> 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe\nRSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283\nRAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000\nRDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6\nRBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584\nR10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7e\nR13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76\nFS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\n[] netdev_start_xmit include/linux/netdevice.h:4925 [inline]\n[] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380\n[] dev_direct_xmit include/linux/netdevice.h:3043 [inline]\n[] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284\n[] packet_snd net/packet/af_packet.c:3112 [inline]\n[] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143\n[] sock_sendmsg_nosec net/socket.c:716 [inline]\n[] sock_sendmsg net/socket.c:736 [inline]\n[] __sys_sendto+0x472/0x5f0 net/socket.c:2139\n[] __do_sys_sendto net/socket.c:2151 [inline]\n[] __se_sys_sendto net/socket.c:2147 [inline]\n[] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147\n[] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n[] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80\n[] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\ntunnels: fix kasan splat when generating ipv4 pmtu error\nIf we try to emit an icmp error in response to a nonliner skb, we get\nBUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220\nRead of size 4 at addr ffff88811c50db00 by task iperf3/1691\nCPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309\n[..]\nkasan_report+0x105/0x140\nip_compute_csum+0x134/0x220\niptunnel_pmtud_build_icmp+0x554/0x1020\nskb_tunnel_check_pmtu+0x513/0xb80\nvxlan_xmit_one+0x139e/0x2ef0\nvxlan_xmit+0x1867/0x2760\ndev_hard_start_xmit+0x1ee/0x4f0\nbr_dev_queue_push_xmit+0x4d1/0x660\n[..]\nip_compute_csum() cannot deal with nonlinear skbs, so avoid it.\nAfter this change, splat is gone and iperf3 is no longer stuck.

In the Linux kernel, the following vulnerability has been resolved:\ncrypto: af_alg - Fix missing initialisation affecting gcm-aes-s390\nFix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point\nto the scatterlist array in areq->first_rsgl.sgl.sgl.\nWithout this, the gcm-aes-s390 driver will oops when it tries to do\ngcm_walk_start() on req->dst because req->dst is set to the value of\nareq->first_rsgl.sgl.sgl by _aead_recvmsg() calling\naead_request_set_crypt().\nThe problem comes if an empty ciphertext is passed: the loop in\naf_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl\nup.\nThis isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far\nas I can tell, that ignores req->dst and only uses req->src[*].\n[*] Is this a bug in aesni-intel_glue.c?\nThe s390x oops looks something like:\nUnable to handle kernel pointer dereference in virtual kernel address space\nFailing address: 0000000a00000000 TEID: 0000000a00000803\nFault in home space mode while using kernel ASCE.\nAS:00000000a43a0007 R3:0000000000000024\nOops: 003b ilc:2 [#1] SMP\n...\nCall Trace:\n[<000003ff7fc3d47e>] gcm_walk_start+0x16/0x28 [aes_s390]\n[<00000000a2a342f2>] crypto_aead_decrypt+0x9a/0xb8\n[<00000000a2a60888>] aead_recvmsg+0x478/0x698\n[<00000000a2e519a0>] sock_recvmsg+0x70/0xb0\n[<00000000a2e51a56>] sock_read_iter+0x76/0xa0\n[<00000000a273e066>] vfs_read+0x26e/0x2a8\n[<00000000a273e8c4>] ksys_read+0xbc/0x100\n[<00000000a311d808>] __do_syscall+0x1d0/0x1f8\n[<00000000a312ff30>] system_call+0x70/0x98\nLast Breaking-Event-Address:\n[<000003ff7fc3e6b4>] gcm_aes_crypt+0x104/0xa68 [aes_s390]

In the Linux kernel, the following vulnerability has been resolved:\nbus: mhi: host: Range check CHDBOFF and ERDBOFF\nIf the value read from the CHDBOFF and ERDBOFF registers is outside the\nrange of the MHI register space then an invalid address might be computed\nwhich later causes a kernel panic. Range check the read value to prevent\na crash due to bad data from the device.

In the Linux kernel, the following vulnerability has been resolved:\ncifs: fix mid leak during reconnection after timeout threshold\nWhen the number of responses with status of STATUS_IO_TIMEOUT\nexceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect\nthe connection. But we do not return the mid, or the credits\nreturned for the mid, or reduce the number of in-flight requests.\nThis bug could result in the server->in_flight count to go bad,\nand also cause a leak in the mids.\nThis change moves the check to a few lines below where the\nresponse is decrypted, even of the response is read from the\ntransform header. This way, the code for returning the mids\ncan be reused.\nAlso, the cifs_reconnect was reconnecting just the transport\nconnection before. In case of multi-channel, this may not be\nwhat we want to do after several timeouts. Changed that to\nreconnect the session and the tree too.\nAlso renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name\nMAX_STATUS_IO_TIMEOUT.

In the Linux kernel, the following vulnerability has been resolved:\ndrivers: base: Free devm resources when unregistering a device\nIn the current code, devres_release_all() only gets called if the device\nhas a bus and has been probed.\nThis leads to issues when using bus-less or driver-less devices where\nthe device might never get freed if a managed resource holds a reference\nto the device. This is happening in the DRM framework for example.\nWe should thus call devres_release_all() in the device_del() function to\nmake sure that the device-managed actions are properly executed when the\ndevice is unregistered, even if it has neither a bus nor a driver.\nThis is effectively the same change than commit 2f8d16a996da ("devres:\nrelease resources on device_del()") that got reverted by commit\na525a3ddeaca ("driver core: free devres in device_release") over\nmemory leaks concerns.\nThis patch effectively combines the two commits mentioned above to\nrelease the resources both on device_del() and device_release() and get\nthe best of both worlds.

In the Linux kernel, the following vulnerability has been resolved:\nocteontx2-pf: mcs: Fix NULL pointer dereferences\nWhen system is rebooted after creating macsec interface\nbelow NULL pointer dereference crashes occurred. This\npatch fixes those crashes by using correct order of teardown\n[ 3324.406942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[ 3324.415726] Mem abort info:\n[ 3324.418510] ESR = 0x96000006\n[ 3324.421557] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 3324.426865] SET = 0, FnV = 0\n[ 3324.429913] EA = 0, S1PTW = 0\n[ 3324.433047] Data abort info:\n[ 3324.435921] ISV = 0, ISS = 0x00000006\n[ 3324.439748] CM = 0, WnR = 0\n....\n[ 3324.575915] Call trace:\n[ 3324.578353] cn10k_mdo_del_secy+0x24/0x180\n[ 3324.582440] macsec_common_dellink+0xec/0x120\n[ 3324.586788] macsec_notify+0x17c/0x1c0\n[ 3324.590529] raw_notifier_call_chain+0x50/0x70\n[ 3324.594965] call_netdevice_notifiers_info+0x34/0x7c\n[ 3324.599921] rollback_registered_many+0x354/0x5bc\n[ 3324.604616] unregister_netdevice_queue+0x88/0x10c\n[ 3324.609399] unregister_netdev+0x20/0x30\n[ 3324.613313] otx2_remove+0x8c/0x310\n[ 3324.616794] pci_device_shutdown+0x30/0x70\n[ 3324.620882] device_shutdown+0x11c/0x204\n[ 966.664930] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[ 966.673712] Mem abort info:\n[ 966.676497] ESR = 0x96000006\n[ 966.679543] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 966.684848] SET = 0, FnV = 0\n[ 966.687895] EA = 0, S1PTW = 0\n[ 966.691028] Data abort info:\n[ 966.693900] ISV = 0, ISS = 0x00000006\n[ 966.697729] CM = 0, WnR = 0\n[ 966.833467] Call trace:\n[ 966.835904] cn10k_mdo_stop+0x20/0xa0\n[ 966.839557] macsec_dev_stop+0xe8/0x11c\n[ 966.843384] __dev_close_many+0xbc/0x140\n[ 966.847298] dev_close_many+0x84/0x120\n[ 966.851039] rollback_registered_many+0x114/0x5bc\n[ 966.855735] unregister_netdevice_many.part.0+0x14/0xa0\n[ 966.860952] unregister_netdevice_many+0x18/0x24\n[ 966.865560] macsec_notify+0x1ac/0x1c0\n[ 966.869303] raw_notifier_call_chain+0x50/0x70\n[ 966.873738] call_netdevice_notifiers_info+0x34/0x7c\n[ 966.878694] rollback_registered_many+0x354/0x5bc\n[ 966.883390] unregister_netdevice_queue+0x88/0x10c\n[ 966.888173] unregister_netdev+0x20/0x30\n[ 966.892090] otx2_remove+0x8c/0x310\n[ 966.895571] pci_device_shutdown+0x30/0x70\n[ 966.899660] device_shutdown+0x11c/0x204\n[ 966.903574] __do_sys_reboot+0x208/0x290\n[ 966.907487] __arm64_sys_reboot+0x20/0x30\n[ 966.911489] el0_svc_handler+0x80/0x1c0\n[ 966.915316] el0_svc+0x8/0x180\n[ 966.918362] Code: f9400000 f9400a64 91220014 f94b3403 (f9400060)\n[ 966.924448] ---[ end trace 341778e799c3d8d7 ]---

In the Linux kernel, the following vulnerability has been resolved:\ndriver core: fix resource leak in device_add()\nWhen calling kobject_add() failed in device_add(), it will call\ncleanup_glue_dir() to free resource. But in kobject_add(),\ndev->kobj.parent has been set to NULL. This will cause resource leak.\nThe process is as follows:\ndevice_add()\nget_device_parent()\nclass_dir_create_and_add()\nkobject_add()//kobject_get()\n...\ndev->kobj.parent = kobj;\n...\nkobject_add()//failed, but set dev->kobj.parent = NULL\n...\nglue_dir = get_glue_dir(dev)//glue_dir = NULL, and goto\n//"Error" label\n...\ncleanup_glue_dir()//becaues glue_dir is NULL, not call\n//kobject_put()\nThe preceding problem may cause insmod mac80211_hwsim.ko to failed.\nsysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim'\nCall Trace:\n\ndump_stack_lvl+0x8e/0xd1\nsysfs_warn_dup.cold+0x1c/0x29\nsysfs_create_dir_ns+0x224/0x280\nkobject_add_internal+0x2aa/0x880\nkobject_add+0x135/0x1a0\nget_device_parent+0x3d7/0x590\ndevice_add+0x2aa/0x1cb0\ndevice_create_groups_vargs+0x1eb/0x260\ndevice_create+0xdc/0x110\nmac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]\ninit_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]\ndo_one_initcall+0x10f/0x630\ndo_init_module+0x19f/0x5e0\nload_module+0x64b7/0x6eb0\n__do_sys_finit_module+0x140/0x200\ndo_syscall_64+0x35/0x80\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nkobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try to\nregister things with the same name in the same directory.

In the Linux kernel, the following vulnerability has been resolved:\ncifs: Release folio lock on fscache read hit.\nUnder the current code, when cifs_readpage_worker is called, the call\ncontract is that the callee should unlock the page. This is documented\nin the read_folio section of Documentation/filesystems/vfs.rst as:\n> The filesystem should unlock the folio once the read has completed,\n> whether it was successful or not.\nWithout this change, when fscache is in use and cache hit occurs during\na read, the page lock is leaked, producing the following stack on\nsubsequent reads (via mmap) to the page:\n$ cat /proc/3890/task/12864/stack\n[<0>] folio_wait_bit_common+0x124/0x350\n[<0>] filemap_read_folio+0xad/0xf0\n[<0>] filemap_fault+0x8b1/0xab0\n[<0>] __do_fault+0x39/0x150\n[<0>] do_fault+0x25c/0x3e0\n[<0>] __handle_mm_fault+0x6ca/0xc70\n[<0>] handle_mm_fault+0xe9/0x350\n[<0>] do_user_addr_fault+0x225/0x6c0\n[<0>] exc_page_fault+0x84/0x1b0\n[<0>] asm_exc_page_fault+0x27/0x30\nThis requires a reboot to resolve; it is a deadlock.\nNote however that the call to cifs_readpage_from_fscache does mark the\npage clean, but does not free the folio lock. This happens in\n__cifs_readpage_from_fscache on success. Releasing the lock at that\npoint however is not appropriate as cifs_readahead also calls\ncifs_readpage_from_fscache and *does* unconditionally release the lock\nafter its return. This change therefore effectively makes\ncifs_readpage_worker work like cifs_readahead.

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

In the Linux kernel, the following vulnerability has been resolved:\nsctp: add a refcnt in sctp_stream_priorities to avoid a nested loop\nWith this refcnt added in sctp_stream_priorities, we don't need to\ntraverse all streams to check if the prio is used by other streams\nwhen freeing one stream's prio in sctp_sched_prio_free_sid(). This\ncan avoid a nested loop (up to 65535 * 65535), which may cause a\nstuck as Ying reported:\nwatchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]\nCall Trace:\n\nsctp_sched_prio_free_sid+0xab/0x100 [sctp]\nsctp_stream_free_ext+0x64/0xa0 [sctp]\nsctp_stream_free+0x31/0x50 [sctp]\nsctp_association_free+0xa5/0x200 [sctp]\nNote that it doesn't need to use refcount_t type for this counter,\nas its accessing is always protected under the sock lock.\nv1->v2:\n- add a check in sctp_sched_prio_set to avoid the possible prio_head\nrefcnt overflow.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: mvm: don't trust firmware n_channels\nIf the firmware sends us a corrupted MCC response with\nn_channels much larger than the command response can be,\nwe might copy far too much (uninitialized) memory and\neven crash if the n_channels is large enough to make it\nrun out of the one page allocated for the FW response.\nFix that by checking the lengths. Doing a < comparison\nwould be sufficient, but the firmware should be doing\nit correctly, so check more strictly.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mac80211: check for station first in client probe\nWhen probing a client, first check if we have it, and then\ncheck for the channel context, otherwise you can trigger\nthe warning there easily by probing when the AP isn't even\nstarted yet. Since a client existing means the AP is also\noperating, we can then keep the warning.\nAlso simplify the moved code a bit.

In the Linux kernel, the following vulnerability has been resolved:\nring-buffer: Sync IRQ works before buffer destruction\nIf something was written to the buffer just before destruction,\nit may be possible (maybe not in a real system, but it did\nhappen in ARCH=um with time-travel) to destroy the ringbuffer\nbefore the IRQ work ran, leading this KASAN report (or a crash\nwithout KASAN):\nBUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a\nRead of size 8 at addr 000000006d640a48 by task swapper/0\nCPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7\nStack:\n60c4f20f 0c203d48 41b58ab3 60f224fc\n600477fa 60f35687 60c4f20f 601273dd\n00000008 6101eb00 6101eab0 615be548\nCall Trace:\n[<60047a58>] show_stack+0x25e/0x282\n[<60c609e0>] dump_stack_lvl+0x96/0xfd\n[<60c50d4c>] print_report+0x1a7/0x5a8\n[<603078d3>] kasan_report+0xc1/0xe9\n[<60308950>] __asan_report_load8_noabort+0x1b/0x1d\n[<60232844>] irq_work_run_list+0x11a/0x13a\n[<602328b4>] irq_work_tick+0x24/0x34\n[<6017f9dc>] update_process_times+0x162/0x196\n[<6019f335>] tick_sched_handle+0x1a4/0x1c3\n[<6019fd9e>] tick_sched_timer+0x79/0x10c\n[<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695\n[<60182913>] hrtimer_interrupt+0x16c/0x2c4\n[<600486a3>] um_timer+0x164/0x183\n[...]\nAllocated by task 411:\nsave_stack_trace+0x99/0xb5\nstack_trace_save+0x81/0x9b\nkasan_save_stack+0x2d/0x54\nkasan_set_track+0x34/0x3e\nkasan_save_alloc_info+0x25/0x28\n____kasan_kmalloc+0x8b/0x97\n__kasan_kmalloc+0x10/0x12\n__kmalloc+0xb2/0xe8\nload_elf_phdrs+0xee/0x182\n[...]\nThe buggy address belongs to the object at 000000006d640800\nwhich belongs to the cache kmalloc-1k of size 1024\nThe buggy address is located 584 bytes inside of\nfreed 1024-byte region [000000006d640800, 000000006d640c00)\nAdd the appropriate irq_work_sync() so the work finishes before\nthe buffers are destroyed.\nPrior to the commit in the Fixes tag below, there was only a\nsingle global IRQ work, so this issue didn't exist.

In the Linux kernel, the following vulnerability has been resolved:\nscsi: target: Fix multiple LUN_RESET handling\nThis fixes a bug where an initiator thinks a LUN_RESET has cleaned up\nrunning commands when it hasn't. The bug was added in commit 51ec502a3266\n("target: Delete tmr from list before processing").\nThe problem occurs when:\n1. We have N I/O cmds running in the target layer spread over 2 sessions.\n2. The initiator sends a LUN_RESET for each session.\n3. session1's LUN_RESET loops over all the running commands from both\nsessions and moves them to its local drain_task_list.\n4. session2's LUN_RESET does not see the LUN_RESET from session1 because\nthe commit above has it remove itself. session2 also does not see any\ncommands since the other reset moved them off the state lists.\n5. sessions2's LUN_RESET will then complete with a successful response.\n6. sessions2's inititor believes the running commands on its session are\nnow cleaned up due to the successful response and cleans up the running\ncommands from its side. It then restarts them.\n7. The commands do eventually complete on the backend and the target\nstarts to return aborted task statuses for them. The initiator will\neither throw a invalid ITT error or might accidentally lookup a new\ntask if the ITT has been reallocated already.\nFix the bug by reverting the patch, and serialize the execution of\nLUN_RESETs and Preempt and Aborts.\nAlso prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,\nbecause it turns out the original patch fixed a bug that was not\nmentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second\nLUN_RESET and wait on it. Then the second reset will run\ncore_tmr_drain_tmr_list and see the first reset and wait on it resulting in\na deadlock.

In the Linux kernel, the following vulnerability has been resolved:\nbpf: reject unhashed sockets in bpf_sk_assign\nThe semantics for bpf_sk_assign are as follows:\nsk = some_lookup_func()\nbpf_sk_assign(skb, sk)\nbpf_sk_release(sk)\nThat is, the sk is not consumed by bpf_sk_assign. The function\ntherefore needs to make sure that sk lives long enough to be\nconsumed from __inet_lookup_skb. The path through the stack for a\nTCPv4 packet is roughly:\nnetif_receive_skb_core: takes RCU read lock\n__netif_receive_skb_core:\nsch_handle_ingress:\ntcf_classify:\nbpf_sk_assign()\ndeliver_ptype_list_skb:\ndeliver_skb:\nip_packet_type->func == ip_rcv:\nip_rcv_core:\nip_rcv_finish_core:\ndst_input:\nip_local_deliver:\nip_local_deliver_finish:\nip_protocol_deliver_rcu:\ntcp_v4_rcv:\n__inet_lookup_skb:\nskb_steal_sock\nThe existing helper takes advantage of the fact that everything\nhappens in the same RCU critical section: for sockets with\nSOCK_RCU_FREE set bpf_sk_assign never takes a reference.\nskb_steal_sock then checks SOCK_RCU_FREE again and does sock_put\nif necessary.\nThis approach assumes that SOCK_RCU_FREE is never set on a sk\nbetween bpf_sk_assign and skb_steal_sock, but this invariant is\nviolated by unhashed UDP sockets. A new UDP socket is created\nin TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only\nadded in udp_lib_get_port() which happens when a socket is bound.\nWhen bpf_sk_assign was added it wasn't possible to access unhashed\nUDP sockets from BPF, so this wasn't a problem. This changed\nin commit 0c48eefae712 ("sock_map: Lift socket state restriction\nfor datagram sockets"), but the helper wasn't adjusted accordingly.\nThe following sequence of events will therefore lead to a refcount\nleak:\n1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.\n2. Pull socket out of sockmap and bpf_sk_assign it. Since\nSOCK_RCU_FREE is not set we increment the refcount.\n3. bind() or connect() the socket, setting SOCK_RCU_FREE.\n4. skb_steal_sock will now set refcounted = false due to\nSOCK_RCU_FREE.\n5. tcp_v4_rcv() skips sock_put().\nFix the problem by rejecting unhashed sockets in bpf_sk_assign().\nThis matches the behaviour of __inet_lookup_skb which is ultimately\nthe goal of bpf_sk_assign().

In the Linux kernel, the following vulnerability has been resolved:\nubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process\nThere are two states for ubifs writing pages:\n1. Dirty, Private\n2. Not Dirty, Not Private\nThe normal process cannot go to ubifs_releasepage() which means there\nexists pages being private but not dirty. Reproducer[1] shows that it\ncould occur (which maybe related to [2]) with following process:\nPA PB PC\nlock(page)[PA]\nubifs_write_end\nattach_page_private // set Private\n__set_page_dirty_nobuffers // set Dirty\nunlock(page)\nwrite_cache_pages[PA]\nlock(page)\nclear_page_dirty_for_io(page)// clear Dirty\nubifs_writepage\ndo_truncation[PB]\ntruncate_setsize\ni_size_write(inode, newsize) // newsize = 0\ni_size = i_size_read(inode)// i_size = 0\nend_index = i_size >> PAGE_SHIFT\nif (page->index > end_index)\ngoto out // jump\nout:\nunlock(page) // Private, Not Dirty\ngeneric_fadvise[PC]\nlock(page)\ninvalidate_inode_page\ntry_to_release_page\nubifs_releasepage\nubifs_assert(c, 0)\n// bad assertion!\nunlock(page)\ntruncate_pagecache[PB]\nThen we may get following assertion failed:\nUBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]:\nUBIFS assert failed: 0, in fs/ubifs/file.c:1513\nUBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]:\nswitched to read-only mode, error -22\nCPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308\nCall Trace:\ndump_stack+0x13/0x1b\nubifs_ro_mode+0x54/0x60 [ubifs]\nubifs_assert_failed+0x4b/0x80 [ubifs]\nubifs_releasepage+0x67/0x1d0 [ubifs]\ntry_to_release_page+0x57/0xe0\ninvalidate_inode_page+0xfb/0x130\n__invalidate_mapping_pages+0xb9/0x280\ninvalidate_mapping_pagevec+0x12/0x20\ngeneric_fadvise+0x303/0x3c0\nksys_fadvise64_64+0x4c/0xb0\n[1] https://bugzilla.kernel.org/show_bug.cgi?id=215373\n[2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty

In the Linux kernel, the following vulnerability has been resolved:\nperf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()\nSince commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the\nperf_sample_event_took() function was added to report time spent in\noverflow interrupts. If the interrupt takes too long, the perf framework\nwill lower the sysctl_perf_event_sample_rate and max_samples_per_tick.\nWhen hwc->interrupts is larger than max_samples_per_tick, the\nhwc->interrupts will be set to MAX_INTERRUPTS, and events will be\nthrottled within the __perf_event_account_interrupt() function.\nHowever, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the\nPERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()\nfunction to avoid throttling. When the perf framework unthrottled the event\nin the timer interrupt handler, it triggers riscv_pmu_start() function\nand causes a WARN_ON_ONCE() warning, as shown below:\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e\nModules linked in:\nCPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1\nHardware name: SiFive (DT)\nepc : riscv_pmu_start+0x7c/0x8e\nra : riscv_pmu_start+0x28/0x8e\nepc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0\ngp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0\nt1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720\ns1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000\na2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000\na5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030\ns2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00\ns5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000\ns8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340\ns11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796\nt5 : 0000000700000000 t6 : ffffaf8005269870\nstatus: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003\n[] riscv_pmu_start+0x7c/0x8e\n[] perf_adjust_freq_unthr_context+0x15e/0x174\n[] perf_event_task_tick+0x88/0x9c\n[] scheduler_tick+0xfe/0x27c\n[] update_process_times+0x9a/0xba\n[] tick_sched_handle+0x32/0x66\n[] tick_sched_timer+0x64/0xb0\n[] __hrtimer_run_queues+0x156/0x2f4\n[] hrtimer_interrupt+0xe2/0x1fe\n[] riscv_timer_interrupt+0x38/0x42\n[] handle_percpu_devid_irq+0x90/0x1d2\n[] generic_handle_domain_irq+0x28/0x36\nAfter referring other PMU drivers like Arm, Loongarch, Csky, and Mips,\nthey don't call *_pmu_stop() to update with PERF_HES_STOPPED flag\nafter perf_event_overflow() function nor do they add PERF_HES_STOPPED\nflag checking in *_pmu_start() which don't cause this warning.\nThus, it's recommended to remove this unnecessary check in\nriscv_pmu_start() function to prevent this warning.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds\nFix a stack-out-of-bounds read in brcmfmac that occurs\nwhen 'buf' that is not null-terminated is passed as an argument of\nstrreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with\na CLM version string by memcpy() in brcmf_fil_iovar_data_get().\nEnsure buf is null-terminated.\nFound by a modified version of syzkaller.\n[ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available\n[ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22\n[ 33.021554][ T1896] ==================================================================\n[ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110\n[ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896\n[ 33.023852][ T1896]\n[ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132\n[ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\n[ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event\n[ 33.026581][ T1896] Call Trace:\n[ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d\n[ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334\n[ 33.028037][ T1896] ? strreplace+0xf2/0x110\n[ 33.028403][ T1896] ? strreplace+0xf2/0x110\n[ 33.028807][ T1896] kasan_report.cold+0x83/0xdf\n[ 33.029283][ T1896] ? strreplace+0xf2/0x110\n[ 33.029666][ T1896] strreplace+0xf2/0x110\n[ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40\n[ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100\n[ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0\n[ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0\n[ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0\n[ 33.032091][ T1896] ? find_held_lock+0x2d/0x110\n[ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260\n[ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0\n[ 33.033582][ T1896] brcmf_attach+0x246/0xd40\n[ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50\n[ 33.034383][ T1896] ? kmemdup+0x30/0x40\n[ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690\n[ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470\n[ 33.035833][ T1896] usb_probe_interface+0x25f/0x710\n[ 33.036315][ T1896] really_probe+0x1be/0xa90\n[ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460\n[ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0\n[ 33.037383][ T1896] driver_probe_device+0x49/0x120\n[ 33.037790][ T1896] __device_attach_driver+0x18a/0x250\n[ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120\n[ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0\n[ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20\n[ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0\n[ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120\n[ 33.042330][ T1896] __device_attach+0x207/0x330\n[ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0\n[ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0\n[ 33.043515][ T1896] bus_probe_device+0x1a2/0x260\n[ 33.043914][ T1896] device_add+0xa61/0x1ce0\n[ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660\n[ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550\n[ 33.045531][ T1896] usb_set_configuration+0x984/0x1770\n[ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230\n[ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90\n[ 33.046931][ T1896] usb_probe_device+0x9c/0x220\n[ 33.047434][ T1896] really_probe+0x1be/0xa90\n[ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460\n[ 33.048134][ T1896] driver_probe_device+0x49/0x120\n[ 33.048516][ T1896] __device_attach_driver+0x18a/0x250\n[ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nnet/mlx5e: Check for NOT_READY flag state after locking\nCurrently the check for NOT_READY flag is performed before obtaining the\nnecessary lock. This opens a possibility for race condition when the flow\nis concurrently removed from unready_flows list by the workqueue task,\nwhich causes a double-removal from the list and a crash[0]. Fix the issue\nby moving the flag check inside the section protected by\nuplink_priv->unready_flows_lock mutex.\n[0]:\n[44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP\n[44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1\n[44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]\n[44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06\n[44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246\n[44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00\n[44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0\n[44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001\n[44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000\n[44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000\n[44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000\n[44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0\n[44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[44376.406339] Call Trace:\n[44376.406651] \n[44376.406939] ? die_addr+0x33/0x90\n[44376.407311] ? exc_general_protection+0x192/0x390\n[44376.407795] ? asm_exc_general_protection+0x22/0x30\n[44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]\n[44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core]\n[44376.409482] mlx5e_tc_del_flow+0x42/0x210 [mlx5_core]\n[44376.410055] mlx5e_flow_put+0x25/0x50 [mlx5_core]\n[44376.410529] mlx5e_delete_flower+0x24b/0x350 [mlx5_core]\n[44376.411043] tc_setup_cb_reoffload+0x22/0x80\n[44376.411462] fl_reoffload+0x261/0x2f0 [cls_flower]\n[44376.411907] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]\n[44376.412481] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]\n[44376.413044] tcf_block_playback_offloads+0x76/0x170\n[44376.413497] tcf_block_unbind+0x7b/0xd0\n[44376.413881] tcf_block_setup+0x17d/0x1c0\n[44376.414269] tcf_block_offload_cmd.isra.0+0xf1/0x130\n[44376.414725] tcf_block_offload_unbind+0x43/0x70\n[44376.415153] __tcf_block_put+0x82/0x150\n[44376.415532] ingress_destroy+0x22/0x30 [sch_ingress]\n[44376.415986] qdisc_destroy+0x3b/0xd0\n[44376.416343] qdisc_graft+0x4d0/0x620\n[44376.416706] tc_get_qdisc+0x1c9/0x3b0\n[44376.417074] rtnetlink_rcv_msg+0x29c/0x390\n[44376.419978] ? rep_movs_alternative+0x3a/0xa0\n[44376.420399] ? rtnl_calcit.isra.0+0x120/0x120\n[44376.420813] netlink_rcv_skb+0x54/0x100\n[44376.421192] netlink_unicast+0x1f6/0x2c0\n[44376.421573] netlink_sendmsg+0x232/0x4a0\n[44376.421980] sock_sendmsg+0x38/0x60\n[44376.422328] ____sys_sendmsg+0x1d0/0x1e0\n[44376.422709] ? copy_msghdr_from_user+0x6d/0xa0\n[44376.423127] ___sys_sendmsg+0x80/0xc0\n[44376.423495] ? ___sys_recvmsg+0x8b/0xc0\n[44376.423869] __sys_sendmsg+0x51/0x90\n[44376.424226] do_syscall_64+0x3d/0x90\n[44376.424587] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[44376.425046] RIP: 0033:0x7f045134f887\n[44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00\n---truncated---