In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix double put of request\n\nIf a netfs request finishes during the pause loop, it will have the ref\nthat belongs to the IN_PROGRESS flag removed at that point - however, if it\nthen goes to the final wait loop, that will *also* put the ref because it\nsees that the IN_PROGRESS flag is clear and incorrectly assumes that this\nhappened when it called the collector.\n\nIn fact, since IN_PROGRESS is clear, we shouldn't call the collector again\nsince it's done all the cleanup, such as calling ->ki_complete().\n\nFix this by making netfs_collect_in_app() just return, indicating that\nwe're done if IN_PROGRESS is removed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix memory leak of bio integrity\n\nIf nvmet receives commands with metadata there is a continuous memory\nleak of kmalloc-128 slab or more precisely bio->bi_integrity.\n\nSince commit bf4c89fc8797 ("block: don't call bio_uninit from bio_endio")\neach user of bio_init has to use bio_uninit as well. Otherwise the bio\nintegrity is not getting free. Nvmet uses bio_init for inline bios.\n\nUninit the inline bio to complete deallocation of integrity in bio.

In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: return 0 size for RSS key if not supported\n\nReturning -EOPNOTSUPP from function returning u32 is leading to\ncast and invalid size value as a result.\n\n-EOPNOTSUPP as a size probably will lead to allocation fail.\n\nCommand: ethtool -x eth0\nIt is visible on all devices that don't have RSS caps set.\n\n[ 136.615917] Call Trace:\n[ 136.615921] \n[ 136.615927] ? __warn+0x89/0x130\n[ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330\n[ 136.615953] ? report_bug+0x164/0x190\n[ 136.615968] ? handle_bug+0x58/0x90\n[ 136.615979] ? exc_invalid_op+0x17/0x70\n[ 136.615987] ? asm_exc_invalid_op+0x1a/0x20\n[ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170\n[ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330\n[ 136.616028] __alloc_pages_noprof+0xe/0x20\n[ 136.616038] ___kmalloc_large_node+0x80/0x110\n[ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0\n[ 136.616081] __kmalloc_noprof+0x32c/0x4c0\n[ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170\n[ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170\n[ 136.616114] ethnl_default_doit+0x107/0x3d0\n[ 136.616131] genl_family_rcv_msg_doit+0x100/0x160\n[ 136.616147] genl_rcv_msg+0x1b8/0x2c0\n[ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10\n[ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10\n[ 136.616176] netlink_rcv_skb+0x58/0x110\n[ 136.616186] genl_rcv+0x28/0x40\n[ 136.616195] netlink_unicast+0x19b/0x290\n[ 136.616206] netlink_sendmsg+0x222/0x490\n[ 136.616215] __sys_sendto+0x1fd/0x210\n[ 136.616233] __x64_sys_sendto+0x24/0x30\n[ 136.616242] do_syscall_64+0x82/0x160\n[ 136.616252] ? __sys_recvmsg+0x83/0xe0\n[ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210\n[ 136.616275] ? do_syscall_64+0x8e/0x160\n[ 136.616282] ? __count_memcg_events+0xa1/0x130\n[ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30\n[ 136.616306] ? handle_mm_fault+0xae/0x2d0\n[ 136.616319] ? do_user_addr_fault+0x379/0x670\n[ 136.616328] ? clear_bhb_loop+0x45/0xa0\n[ 136.616340] ? clear_bhb_loop+0x45/0xa0\n[ 136.616349] ? clear_bhb_loop+0x45/0xa0\n[ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 136.616369] RIP: 0033:0x7fd30ba7b047\n[ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44\n[ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c\n[ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047\n[ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003\n[ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c\n[ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340\n[ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000

In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.\n\nsyzbot reported a warning below [1] following a fault injection in\nnfs_fs_proc_net_init(). [0]\n\nWhen nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.\n\nLater, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning\nis logged as the directory is not empty.\n\nLet's handle the error of nfs_fs_proc_net_init() properly.\n\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n \n dump_stack_lvl (lib/dump_stack.c:123)\n should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174)\n should_failslab (mm/failslab.c:46)\n kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204)\n __proc_create (fs/proc/generic.c:427)\n proc_create_reg (fs/proc/generic.c:554)\n proc_create_net_data (fs/proc/proc_net.c:120)\n nfs_fs_proc_net_init (fs/nfs/client.c:1409)\n nfs_net_init (fs/nfs/inode.c:2600)\n ops_init (net/core/net_namespace.c:138)\n setup_net (net/core/net_namespace.c:443)\n copy_net_ns (net/core/net_namespace.c:576)\n create_new_namespaces (kernel/nsproxy.c:110)\n unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4))\n ksys_unshare (kernel/fork.c:3123)\n __x64_sys_unshare (kernel/fork.c:3190)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n \n\n[1]:\nremove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs'\n WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727\nModules linked in:\nCPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727\nCode: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00\nRSP: 0018:ffffc90003637b08 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8\nRDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001\nRBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00\nR13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000\nFS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76\n ops_exit_list net/core/net_namespace.c:200 [inline]\n ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253\n setup_net+0x2e1/0x510 net/core/net_namespace.c:457\n copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574\n create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218\n ksys_unshare+0x45b/0xa40 kernel/fork.c:3121\n __do_sys_unshare kernel/fork.c:3192 [inline]\n __se_sys_unshare kernel/fork.c:3190 [inline]\n __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fa1a6b8e929\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spi-qpic-snand: reallocate BAM transactions\n\nUsing the mtd_nandbiterrs module for testing the driver occasionally\nresults in weird things like below.\n\n1. swiotlb mapping fails with the following message:\n\n [ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots)\n [ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc\n [ 87.999314] qcom_snand 79b0000.spi: failure to write raw page\n [ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110)\n\n Rebooting the board after this causes a panic due to a NULL pointer\n dereference.\n\n2. If the swiotlb mapping does not fail, rebooting the board may result\n in a different panic due to a bad spinlock magic:\n\n [ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241\n [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b\n ...\n\nInvestigating the issue revealed that these symptoms are results of\nmemory corruption which is caused by out of bounds access within the\ndriver.\n\nThe driver uses a dynamically allocated structure for BAM transactions,\nwhich structure must have enough space for all possible variations of\ndifferent flash operations initiated by the driver. The required space\nheavily depends on the actual number of 'codewords' which is calculated\nfrom the pagesize of the actual NAND chip.\n\nAlthough the qcom_nandc_alloc() function allocates memory for the BAM\ntransactions during probe, but since the actual number of 'codewords'\nis not yet know the allocation is done for one 'codeword' only.\n\nBecause of this, whenever the driver does a flash operation, and the\nnumber of the required transactions exceeds the size of the allocated\narrays the driver accesses memory out of the allocated range.\n\nTo avoid this, change the code to free the initially allocated BAM\ntransactions memory, and allocate a new one once the actual number of\n'codewords' required for a given NAND chip is known.

In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-multipath: fix suspicious RCU usage warning\n\nWhen I run the NVME over TCP test in virtme-ng, I get the following\n"suspicious RCU usage" warning in nvme_mpath_add_sysfs_link():\n\n'''\n[ 5.024557][ T44] nvmet: Created nvm controller 1 for subsystem nqn.2025-06.org.nvmexpress.mptcp for NQN nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77.\n[ 5.027401][ T183] nvme nvme0: creating 2 I/O queues.\n[ 5.029017][ T183] nvme nvme0: mapped 2/0/0 default/read/poll queues.\n[ 5.032587][ T183] nvme nvme0: new ctrl: NQN "nqn.2025-06.org.nvmexpress.mptcp", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77\n[ 5.042214][ T25]\n[ 5.042440][ T25] =============================\n[ 5.042579][ T25] WARNING: suspicious RCU usage\n[ 5.042705][ T25] 6.16.0-rc3+ #23 Not tainted\n[ 5.042812][ T25] -----------------------------\n[ 5.042934][ T25] drivers/nvme/host/multipath.c:1203 RCU-list traversed in non-reader section!!\n[ 5.043111][ T25]\n[ 5.043111][ T25] other info that might help us debug this:\n[ 5.043111][ T25]\n[ 5.043341][ T25]\n[ 5.043341][ T25] rcu_scheduler_active = 2, debug_locks = 1\n[ 5.043502][ T25] 3 locks held by kworker/u9:0/25:\n[ 5.043615][ T25] #0: ffff888008730948 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x7ed/0x1350\n[ 5.043830][ T25] #1: ffffc900001afd40 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0xcf3/0x1350\n[ 5.044084][ T25] #2: ffff888013ee0020 (&head->srcu){.+.+}-{0:0}, at: nvme_mpath_add_sysfs_link.part.0+0xb4/0x3a0\n[ 5.044300][ T25]\n[ 5.044300][ T25] stack backtrace:\n[ 5.044439][ T25] CPU: 0 UID: 0 PID: 25 Comm: kworker/u9:0 Not tainted 6.16.0-rc3+ #23 PREEMPT(full)\n[ 5.044441][ T25] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[ 5.044442][ T25] Workqueue: async async_run_entry_fn\n[ 5.044445][ T25] Call Trace:\n[ 5.044446][ T25] \n[ 5.044449][ T25] dump_stack_lvl+0x6f/0xb0\n[ 5.044453][ T25] lockdep_rcu_suspicious.cold+0x4f/0xb1\n[ 5.044457][ T25] nvme_mpath_add_sysfs_link.part.0+0x2fb/0x3a0\n[ 5.044459][ T25] ? queue_work_on+0x90/0xf0\n[ 5.044461][ T25] ? lockdep_hardirqs_on+0x78/0x110\n[ 5.044466][ T25] nvme_mpath_set_live+0x1e9/0x4f0\n[ 5.044470][ T25] nvme_mpath_add_disk+0x240/0x2f0\n[ 5.044472][ T25] ? __pfx_nvme_mpath_add_disk+0x10/0x10\n[ 5.044475][ T25] ? add_disk_fwnode+0x361/0x580\n[ 5.044480][ T25] nvme_alloc_ns+0x81c/0x17c0\n[ 5.044483][ T25] ? kasan_quarantine_put+0x104/0x240\n[ 5.044487][ T25] ? __pfx_nvme_alloc_ns+0x10/0x10\n[ 5.044495][ T25] ? __pfx_nvme_find_get_ns+0x10/0x10\n[ 5.044496][ T25] ? rcu_read_lock_any_held+0x45/0xa0\n[ 5.044498][ T25] ? validate_chain+0x232/0x4f0\n[ 5.044503][ T25] nvme_scan_ns+0x4c8/0x810\n[ 5.044506][ T25] ? __pfx_nvme_scan_ns+0x10/0x10\n[ 5.044508][ T25] ? find_held_lock+0x2b/0x80\n[ 5.044512][ T25] ? ktime_get+0x16d/0x220\n[ 5.044517][ T25] ? kvm_clock_get_cycles+0x18/0x30\n[ 5.044520][ T25] ? __pfx_nvme_scan_ns_async+0x10/0x10\n[ 5.044522][ T25] async_run_entry_fn+0x97/0x560\n[ 5.044523][ T25] ? rcu_is_watching+0x12/0xc0\n[ 5.044526][ T25] process_one_work+0xd3c/0x1350\n[ 5.044532][ T25] ? __pfx_process_one_work+0x10/0x10\n[ 5.044536][ T25] ? assign_work+0x16c/0x240\n[ 5.044539][ T25] worker_thread+0x4da/0xd50\n[ 5.044545][ T25] ? __pfx_worker_thread+0x10/0x10\n[ 5.044546][ T25] kthread+0x356/0x5c0\n[ 5.044548][ T25] ? __pfx_kthread+0x10/0x10\n[ 5.044549][ T25] ? ret_from_fork+0x1b/0x2e0\n[ 5.044552][ T25] ? __lock_release.isra.0+0x5d/0x180\n[ 5.044553][ T25] ? ret_from_fork+0x1b/0x2e0\n[ 5.044555][ T25] ? rcu_is_watching+0x12/0xc0\n[ 5.044557][ T25] ? __pfx_kthread+0x10/0x10\n[ 5.04\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nfs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass\n\nExport anon_inode_make_secure_inode() to allow KVM guest_memfd to create\nanonymous inodes with proper security context. This replaces the current\npattern of calling alloc_anon_inode() followed by\ninode_init_security_anon() for creating security context manually.\n\nThis change also fixes a security regression in secretmem where the\nS_PRIVATE flag was not cleared after alloc_anon_inode(), causing\nLSM/SELinux checks to be bypassed for secretmem file descriptors.\n\nAs guest_memfd currently resides in the KVM module, we need to export this\nsymbol for use outside the core kernel. In the future, guest_memfd might be\nmoved to core-mm, at which point the symbols no longer would have to be\nexported. When/if that happens is still unclear.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: appletb-kbd: fix memory corruption of input_handler_list\n\nIn appletb_kbd_probe an input handler is initialised and then registered\nwith input core through input_register_handler(). When this happens input\ncore will add the input handler (specifically its node) to the global\ninput_handler_list. The input_handler_list is central to the functionality\nof input core and is traversed in various places in input core. An example\nof this is when a new input device is plugged in and gets registered with\ninput core.\n\nThe input_handler in probe is allocated as device managed memory. If a\nprobe failure occurs after input_register_handler() the input_handler\nmemory is freed, yet it will remain in the input_handler_list. This\neffectively means the input_handler_list contains a dangling pointer\nto data belonging to a freed input handler.\n\nThis causes an issue when any other input device is plugged in - in my\ncase I had an old PixArt HP USB optical mouse and I decided to\nplug it in after a failure occurred after input_register_handler().\nThis lead to the registration of this input device via\ninput_register_device which involves traversing over every handler\nin the corrupted input_handler_list and calling input_attach_handler(),\ngiving each handler a chance to bind to newly registered device.\n\nThe core of this bug is a UAF which causes memory corruption of\ninput_handler_list and to fix it we must ensure the input handler is\nunregistered from input core, this is done through\ninput_unregister_handler().\n\n[ 63.191597] ==================================================================\n[ 63.192094] BUG: KASAN: slab-use-after-free in input_attach_handler.isra.0+0x1a9/0x1e0\n[ 63.192094] Read of size 8 at addr ffff888105ea7c80 by task kworker/0:2/54\n[ 63.192094]\n[ 63.192094] CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.16.0-rc2-00321-g2aa6621d\n[ 63.192094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.164\n[ 63.192094] Workqueue: usb_hub_wq hub_event\n[ 63.192094] Call Trace:\n[ 63.192094] \n[ 63.192094] dump_stack_lvl+0x53/0x70\n[ 63.192094] print_report+0xce/0x670\n[ 63.192094] kasan_report+0xce/0x100\n[ 63.192094] input_attach_handler.isra.0+0x1a9/0x1e0\n[ 63.192094] input_register_device+0x76c/0xd00\n[ 63.192094] hidinput_connect+0x686d/0xad60\n[ 63.192094] hid_connect+0xf20/0x1b10\n[ 63.192094] hid_hw_start+0x83/0x100\n[ 63.192094] hid_device_probe+0x2d1/0x680\n[ 63.192094] really_probe+0x1c3/0x690\n[ 63.192094] __driver_probe_device+0x247/0x300\n[ 63.192094] driver_probe_device+0x49/0x210\n[ 63.192094] __device_attach_driver+0x160/0x320\n[ 63.192094] bus_for_each_drv+0x10f/0x190\n[ 63.192094] __device_attach+0x18e/0x370\n[ 63.192094] bus_probe_device+0x123/0x170\n[ 63.192094] device_add+0xd4d/0x1460\n[ 63.192094] hid_add_device+0x30b/0x910\n[ 63.192094] usbhid_probe+0x920/0xe00\n[ 63.192094] usb_probe_interface+0x363/0x9a0\n[ 63.192094] really_probe+0x1c3/0x690\n[ 63.192094] __driver_probe_device+0x247/0x300\n[ 63.192094] driver_probe_device+0x49/0x210\n[ 63.192094] __device_attach_driver+0x160/0x320\n[ 63.192094] bus_for_each_drv+0x10f/0x190\n[ 63.192094] __device_attach+0x18e/0x370\n[ 63.192094] bus_probe_device+0x123/0x170\n[ 63.192094] device_add+0xd4d/0x1460\n[ 63.192094] usb_set_configuration+0xd14/0x1880\n[ 63.192094] usb_generic_driver_probe+0x78/0xb0\n[ 63.192094] usb_probe_device+0xaa/0x2e0\n[ 63.192094] really_probe+0x1c3/0x690\n[ 63.192094] __driver_probe_device+0x247/0x300\n[ 63.192094] driver_probe_device+0x49/0x210\n[ 63.192094] __device_attach_driver+0x160/0x320\n[ 63.192094] bus_for_each_drv+0x10f/0x190\n[ 63.192094] __device_attach+0x18e/0x370\n[ 63.192094] bus_probe_device+0x123/0x170\n[ 63.192094] device_add+0xd4d/0x1460\n[ 63.192094] usb_new_device+0x7b4/0x1000\n[ 63.192094] hub_event+0x234d/0x3\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: convert control queue mutex to a spinlock\n\nWith VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated\non module load:\n\n[ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578\n[ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager\n[ 324.701689] preempt_count: 201, expected: 0\n[ 324.701693] RCU nest depth: 0, expected: 0\n[ 324.701697] 2 locks held by NetworkManager/1582:\n[ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0\n[ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870\n[ 324.701749] Preemption disabled at:\n[ 324.701752] [] __dev_open+0x3dd/0x870\n[ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)\n[ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022\n[ 324.701774] Call Trace:\n[ 324.701777] \n[ 324.701779] dump_stack_lvl+0x5d/0x80\n[ 324.701788] ? __dev_open+0x3dd/0x870\n[ 324.701793] __might_resched.cold+0x1ef/0x23d\n<..>\n[ 324.701818] __mutex_lock+0x113/0x1b80\n<..>\n[ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf]\n[ 324.701935] ? kasan_save_track+0x14/0x30\n[ 324.701941] idpf_mb_clean+0x143/0x380 [idpf]\n<..>\n[ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf]\n[ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf]\n[ 324.702021] ? rcu_is_watching+0x12/0xc0\n[ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]\n<..>\n[ 324.702122] __hw_addr_sync_dev+0x1cf/0x300\n[ 324.702126] ? find_held_lock+0x32/0x90\n[ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf]\n[ 324.702152] __dev_open+0x3f8/0x870\n[ 324.702159] ? __pfx___dev_open+0x10/0x10\n[ 324.702174] __dev_change_flags+0x443/0x650\n<..>\n[ 324.702208] netif_change_flags+0x80/0x160\n[ 324.702218] do_setlink.isra.0+0x16a0/0x3960\n<..>\n[ 324.702349] rtnl_newlink+0x12fd/0x21e0\n\nThe sequence is as follows:\n rtnl_newlink()->\n __dev_change_flags()->\n __dev_open()->\n dev_set_rx_mode() - > # disables BH and grabs "dev->addr_list_lock"\n idpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON\n __dev_uc_sync() ->\n idpf_add_mac_filter ->\n idpf_add_del_mac_filters ->\n idpf_send_mb_msg() ->\n idpf_mb_clean() ->\n idpf_ctlq_clean_sq() # mutex_lock(cq_lock)\n\nFix by converting cq_lock to a spinlock. All operations under the new\nlock are safe except freeing the DMA memory, which may use vunmap(). Fix\nby requesting a contiguous physical memory for the DMA mapping.

In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_ffa: Fix memory leak by freeing notifier callback node\n\nCommit e0573444edbf ("firmware: arm_ffa: Add interfaces to request\nnotification callbacks") adds support for notifier callbacks by allocating\nand inserting a callback node into a hashtable during registration of\nnotifiers. However, during unregistration, the code only removes the\nnode from the hashtable without freeing the associated memory, resulting\nin a memory leak.\n\nResolve the memory leak issue by ensuring the allocated notifier callback\nnode is properly freed after it is removed from the hashtable entry.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: fix data race in show_numa_info()\n\nThe following data-race was found in show_numa_info():\n\n==================================================================\nBUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show\n\nread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0:\n show_numa_info mm/vmalloc.c:4936 [inline]\n vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nwrite to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1:\n show_numa_info mm/vmalloc.c:4934 [inline]\n vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nvalue changed: 0x0000008f -> 0x00000000\n==================================================================\n\nAccording to this report,there is a read/write data-race because\nm->private is accessible to multiple CPUs. To fix this, instead of\nallocating the heap in proc_vmalloc_init() and passing the heap address to\nm->private, vmalloc_info_show() should allocate the heap.

In the Linux kernel, the following vulnerability has been resolved:\n\nInput: cs40l50-vibra - fix potential NULL dereference in cs40l50_upload_owt()\n\nThe cs40l50_upload_owt() function allocates memory via kmalloc()\nwithout checking for allocation failure, which could lead to a\nNULL pointer dereference.\n\nReturn -ENOMEM in case allocation fails.

In the Linux kernel, the following vulnerability has been resolved:\n\ni2c/designware: Fix an initialization issue\n\nThe i2c_dw_xfer_init() function requires msgs and msg_write_idx from the\ndev context to be initialized.\n\namd_i2c_dw_xfer_quirk() inits msgs and msgs_num, but not msg_write_idx.\n\nThis could allow an out of bounds access (of msgs).\n\nInitialize msg_write_idx before calling i2c_dw_xfer_init().

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix warning when reconnecting channel\n\nWhen reconnecting a channel in smb2_reconnect_server(), a dummy tcon\nis passed down to smb2_reconnect() with ->query_interface\nuninitialized, so we can't call queue_delayed_work() on it.\n\nFix the following warning by ensuring that we're queueing the delayed\nworker from correct tcon.\n\nWARNING: CPU: 4 PID: 1126 at kernel/workqueue.c:2498 __queue_delayed_work+0x1d2/0x200\nModules linked in: cifs cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]\nCPU: 4 UID: 0 PID: 1126 Comm: kworker/4:0 Not tainted 6.16.0-rc3 #5 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-4.fc42 04/01/2014\nWorkqueue: cifsiod smb2_reconnect_server [cifs]\nRIP: 0010:__queue_delayed_work+0x1d2/0x200\nCode: 41 5e 41 5f e9 7f ee ff ff 90 0f 0b 90 e9 5d ff ff ff bf 02 00\n00 00 e8 6c f3 07 00 89 c3 eb bd 90 0f 0b 90 e9 57 f> 0b 90 e9 65 fe\nff ff 90 0f 0b 90 e9 72 fe ff ff 90 0f 0b 90 e9\nRSP: 0018:ffffc900014afad8 EFLAGS: 00010003\nRAX: 0000000000000000 RBX: ffff888124d99988 RCX: ffffffff81399cc1\nRDX: dffffc0000000000 RSI: ffff888114326e00 RDI: ffff888124d999f0\nRBP: 000000000000ea60 R08: 0000000000000001 R09: ffffed10249b3331\nR10: ffff888124d9998f R11: 0000000000000004 R12: 0000000000000040\nR13: ffff888114326e00 R14: ffff888124d999d8 R15: ffff888114939020\nFS: 0000000000000000(0000) GS:ffff88829f7fe000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffe7a2b4038 CR3: 0000000120a6f000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \n queue_delayed_work_on+0xb4/0xc0\n smb2_reconnect+0xb22/0xf50 [cifs]\n smb2_reconnect_server+0x413/0xd40 [cifs]\n ? __pfx_smb2_reconnect_server+0x10/0x10 [cifs]\n ? local_clock_noinstr+0xd/0xd0\n ? local_clock+0x15/0x30\n ? lock_release+0x29b/0x390\n process_one_work+0x4c5/0xa10\n ? __pfx_process_one_work+0x10/0x10\n ? __list_add_valid_or_report+0x37/0x120\n worker_thread+0x2f1/0x5a0\n ? __kthread_parkme+0xde/0x100\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x1fe/0x380\n ? kthread+0x10f/0x380\n ? __pfx_kthread+0x10/0x10\n ? local_clock_noinstr+0xd/0xd0\n ? ret_from_fork+0x1b/0x1f0\n ? local_clock+0x15/0x30\n ? lock_release+0x29b/0x390\n ? rcu_is_watching+0x20/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x15b/0x1f0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \nirq event stamp: 1116206\nhardirqs last enabled at (1116205): [] __up_console_sem+0x52/0x60\nhardirqs last disabled at (1116206): [] queue_delayed_work_on+0x6e/0xc0\nsoftirqs last enabled at (1116138): [] __smb_send_rqst+0x42d/0x950 [cifs]\nsoftirqs last disabled at (1116136): [] release_sock+0x21/0xf0

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: appletb-kbd: fix slab use-after-free bug in appletb_kbd_probe\n\nIn probe appletb_kbd_probe() a "struct appletb_kbd *kbd" is allocated\nvia devm_kzalloc() to store touch bar keyboard related data.\nLater on if backlight_device_get_by_name() finds a backlight device\nwith name "appletb_backlight" a timer (kbd->inactivity_timer) is setup\nwith appletb_inactivity_timer() and the timer is armed to run after\nappletb_tb_dim_timeout (60) seconds.\n\nA use-after-free is triggered when failure occurs after the timer is\narmed. This ultimately means probe failure occurs and as a result the\n"struct appletb_kbd *kbd" which is device managed memory is freed.\nAfter 60 seconds the timer will have expired and __run_timers will\nattempt to access the timer (kbd->inactivity_timer) however the kdb\nstructure has been freed causing a use-after free.\n\n[ 71.636938] ==================================================================\n[ 71.637915] BUG: KASAN: slab-use-after-free in __run_timers+0x7ad/0x890\n[ 71.637915] Write of size 8 at addr ffff8881178c5958 by task swapper/1/0\n[ 71.637915]\n[ 71.637915] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.16.0-rc2-00318-g739a6c93cc75-dirty #12 PREEMPT(voluntary)\n[ 71.637915] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n[ 71.637915] Call Trace:\n[ 71.637915] \n[ 71.637915] dump_stack_lvl+0x53/0x70\n[ 71.637915] print_report+0xce/0x670\n[ 71.637915] ? __run_timers+0x7ad/0x890\n[ 71.637915] kasan_report+0xce/0x100\n[ 71.637915] ? __run_timers+0x7ad/0x890\n[ 71.637915] __run_timers+0x7ad/0x890\n[ 71.637915] ? __pfx___run_timers+0x10/0x10\n[ 71.637915] ? update_process_times+0xfc/0x190\n[ 71.637915] ? __pfx_update_process_times+0x10/0x10\n[ 71.637915] ? _raw_spin_lock_irq+0x80/0xe0\n[ 71.637915] ? _raw_spin_lock_irq+0x80/0xe0\n[ 71.637915] ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 71.637915] run_timer_softirq+0x141/0x240\n[ 71.637915] ? __pfx_run_timer_softirq+0x10/0x10\n[ 71.637915] ? __pfx___hrtimer_run_queues+0x10/0x10\n[ 71.637915] ? kvm_clock_get_cycles+0x18/0x30\n[ 71.637915] ? ktime_get+0x60/0x140\n[ 71.637915] handle_softirqs+0x1b8/0x5c0\n[ 71.637915] ? __pfx_handle_softirqs+0x10/0x10\n[ 71.637915] irq_exit_rcu+0xaf/0xe0\n[ 71.637915] sysvec_apic_timer_interrupt+0x6c/0x80\n[ 71.637915] \n[ 71.637915]\n[ 71.637915] Allocated by task 39:\n[ 71.637915] kasan_save_stack+0x33/0x60\n[ 71.637915] kasan_save_track+0x14/0x30\n[ 71.637915] __kasan_kmalloc+0x8f/0xa0\n[ 71.637915] __kmalloc_node_track_caller_noprof+0x195/0x420\n[ 71.637915] devm_kmalloc+0x74/0x1e0\n[ 71.637915] appletb_kbd_probe+0x37/0x3c0\n[ 71.637915] hid_device_probe+0x2d1/0x680\n[ 71.637915] really_probe+0x1c3/0x690\n[ 71.637915] __driver_probe_device+0x247/0x300\n[ 71.637915] driver_probe_device+0x49/0x210\n[...]\n[ 71.637915]\n[ 71.637915] Freed by task 39:\n[ 71.637915] kasan_save_stack+0x33/0x60\n[ 71.637915] kasan_save_track+0x14/0x30\n[ 71.637915] kasan_save_free_info+0x3b/0x60\n[ 71.637915] __kasan_slab_free+0x37/0x50\n[ 71.637915] kfree+0xcf/0x360\n[ 71.637915] devres_release_group+0x1f8/0x3c0\n[ 71.637915] hid_device_probe+0x315/0x680\n[ 71.637915] really_probe+0x1c3/0x690\n[ 71.637915] __driver_probe_device+0x247/0x300\n[ 71.637915] driver_probe_device+0x49/0x210\n[...]\n\nThe root cause of the issue is that the timer is not disarmed\non failure paths leading to it remaining active and accessing\nfreed memory. To fix this call timer_delete_sync() to deactivate\nthe timer.\n\nAnother small issue is that timer_delete_sync is called\nunconditionally in appletb_kbd_remove(), fix this by checking\nfor a valid kbd->backlight_dev before calling timer_delete_sync.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix unsafe xarray access in implicit ODP handling\n\n__xa_store() and __xa_erase() were used without holding the proper lock,\nwhich led to a lockdep warning due to unsafe RCU usage. This patch\nreplaces them with xa_store() and xa_erase(), which perform the necessary\nlocking internally.\n\n =============================\n WARNING: suspicious RCPU usage\n 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Not tainted\n -----------------------------\n ./include/linux/xarray.h:1211 suspicious rcu_dereference_protected() usage!\n\n other info that might help us debug this:\n\n rcu_scheduler_active = 2, debug_locks = 1\n 3 locks held by kworker/u136:0/219:\n at: process_one_work+0xbe4/0x15f0\n process_one_work+0x75c/0x15f0\n pagefault_mr+0x9a5/0x1390 [mlx5_ib]\n\n stack backtrace:\n CPU: 14 UID: 0 PID: 219 Comm: kworker/u136:0 Not tainted\n 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\n rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]\n Call Trace:\n dump_stack_lvl+0xa8/0xc0\n lockdep_rcu_suspicious+0x1e6/0x260\n xas_create+0xb8a/0xee0\n xas_store+0x73/0x14c0\n __xa_store+0x13c/0x220\n ? xa_store_range+0x390/0x390\n ? spin_bug+0x1d0/0x1d0\n pagefault_mr+0xcb5/0x1390 [mlx5_ib]\n ? _raw_spin_unlock+0x1f/0x30\n mlx5_ib_eqe_pf_action+0x3be/0x2620 [mlx5_ib]\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? mlx5_ib_invalidate_range+0xcb0/0xcb0 [mlx5_ib]\n process_one_work+0x7db/0x15f0\n ? pwq_dec_nr_in_flight+0xda0/0xda0\n ? assign_work+0x168/0x240\n worker_thread+0x57d/0xcd0\n ? rescuer_thread+0xc40/0xc40\n kthread+0x3b3/0x800\n ? kthread_is_per_cpu+0xb0/0xb0\n ? lock_downgrade+0x680/0x680\n ? do_raw_spin_lock+0x12d/0x270\n ? spin_bug+0x1d0/0x1d0\n ? finish_task_switch.isra.0+0x284/0x9e0\n ? lockdep_hardirqs_on_prepare+0x284/0x400\n ? kthread_is_per_cpu+0xb0/0xb0\n ret_from_fork+0x2d/0x70\n ? kthread_is_per_cpu+0xb0/0xb0\n ret_from_fork_asm+0x11/0x20

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix failure to rebuild free space tree using multiple transactions\n\nIf we are rebuilding a free space tree, while modifying the free space\ntree we may need to allocate a new metadata block group.\nIf we end up using multiple transactions for the rebuild, when we call\nbtrfs_end_transaction() we enter btrfs_create_pending_block_groups()\nwhich calls add_block_group_free_space() to add items to the free space\ntree for the block group.\n\nThen later during the free space tree rebuild, at\nbtrfs_rebuild_free_space_tree(), we may find such new block groups\nand call populate_free_space_tree() for them, which fails with -EEXIST\nbecause there are already items in the free space tree. Then we abort the\ntransaction with -EEXIST at btrfs_rebuild_free_space_tree().\nNotice that we say "may find" the new block groups because a new block\ngroup may be inserted in the block groups rbtree, which is being iterated\nby the rebuild process, before or after the current node where the rebuild\nprocess is currently at.\n\nSyzbot recently reported such case which produces a trace like the\nfollowing:\n\n ------------[ cut here ]------------\n BTRFS: Transaction aborted (error -17)\n WARNING: CPU: 1 PID: 7626 at fs/btrfs/free-space-tree.c:1341 btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341\n Modules linked in:\n CPU: 1 UID: 0 PID: 7626 Comm: syz.2.25 Not tainted 6.15.0-rc7-syzkaller-00085-gd7fa1af5b33e-dirty #0 PREEMPT\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341\n lr : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341\n sp : ffff80009c4f7740\n x29: ffff80009c4f77b0 x28: ffff0000d4c3f400 x27: 0000000000000000\n x26: dfff800000000000 x25: ffff70001389eee8 x24: 0000000000000003\n x23: 1fffe000182b6e7b x22: 0000000000000000 x21: ffff0000c15b73d8\n x20: 00000000ffffffef x19: ffff0000c15b7378 x18: 1fffe0003386f276\n x17: ffff80008f31e000 x16: ffff80008adbe98c x15: 0000000000000001\n x14: 1fffe0001b281550 x13: 0000000000000000 x12: 0000000000000000\n x11: ffff60001b281551 x10: 0000000000000003 x9 : 1c8922000a902c00\n x8 : 1c8922000a902c00 x7 : ffff800080485878 x6 : 0000000000000000\n x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff80008047843c\n x2 : 0000000000000001 x1 : ffff80008b3ebc40 x0 : 0000000000000001\n Call trace:\n btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 (P)\n btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074\n btrfs_remount_rw fs/btrfs/super.c:1319 [inline]\n btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543\n reconfigure_super+0x1d4/0x6f0 fs/super.c:1083\n do_remount fs/namespace.c:3365 [inline]\n path_mount+0xb34/0xde0 fs/namespace.c:4200\n do_mount fs/namespace.c:4221 [inline]\n __do_sys_mount fs/namespace.c:4432 [inline]\n __se_sys_mount fs/namespace.c:4409 [inline]\n __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767\n el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n irq event stamp: 330\n hardirqs last enabled at (329): [] raw_spin_rq_unlock_irq kernel/sched/sched.h:1525 [inline]\n hardirqs last enabled at (329): [] finish_lock_switch+0xb0/0x1c0 kernel/sched/core.c:5130\n hardirqs last disabled at (330): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:511\n softirqs last enabled at (10): [] local_bh_enable+0\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: KVM: Avoid overflow with array index\n\nThe variable index is modified and reused as array index when modify\nregister EIOINTC_ENABLE. There will be array index overflow problem.

In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: KVM: Check validity of "num_cpu" from user space\n\nThe maximum supported cpu number is EIOINTC_ROUTE_MAX_VCPUS about\nirqchip EIOINTC, here add validation about cpu number to avoid array\npointer overflow.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add more checks for DSC / HUBP ONO guarantees\n\n[WHY]\nFor non-zero DSC instances it's possible that the HUBP domain required\nto drive it for sequential ONO ASICs isn't met, potentially causing\nthe logic to the tile to enter an undefined state leading to a system\nhang.\n\n[HOW]\nAdd more checks to ensure that the HUBP domain matching the DSC instance\nis appropriately powered.\n\n(cherry picked from commit da63df07112e5a9857a8d2aaa04255c4206754ec)

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/mm: Fix in_atomic() handling in do_secure_storage_access()\n\nKernel user spaces accesses to not exported pages in atomic context\nincorrectly try to resolve the page fault.\nWith debug options enabled call traces like this can be seen:\n\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39\npreempt_count: 1, expected: 0\nRCU nest depth: 0, expected: 0\nINFO: lockdep is turned off.\nPreemption disabled at:\n[<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0\nCPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39\nTainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT\nTainted: [W]=WARN\nHardware name: IBM 3931 A01 703 (LPAR)\nCall Trace:\n [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8\n [<00000383e99bf152>] __might_resched+0x292/0x2d0\n [<00000383eaa7c374>] down_read+0x34/0x2d0\n [<00000383e99432f8>] do_secure_storage_access+0x108/0x360\n [<00000383eaa724b0>] __do_pgm_check+0x130/0x220\n [<00000383eaa842e4>] pgm_check_handler+0x114/0x160\n [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0\n([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0)\n [<00000383e9c45eae>] generic_perform_write+0x16e/0x310\n [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160\n [<00000383e9da0de4>] vfs_write+0x1c4/0x460\n [<00000383e9da123c>] ksys_write+0x7c/0x100\n [<00000383eaa7284e>] __do_syscall+0x15e/0x280\n [<00000383eaa8417e>] system_call+0x6e/0x90\nINFO: lockdep is turned off.\n\nIt is not allowed to take the mmap_lock while in atomic context. Therefore\nhandle such a secure storage access fault as if the accessed page is not\nmapped: the uaccess function will return -EFAULT, and the caller has to\ndeal with this. Usually this means that the access is retried in process\ncontext, which allows to resolve the page fault (or in this case export the\npage).

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race between async reclaim worker and close_ctree()\n\nSyzbot reported an assertion failure due to an attempt to add a delayed\niput after we have set BTRFS_FS_STATE_NO_DELAYED_IPUT in the fs_info\nstate:\n\n WARNING: CPU: 0 PID: 65 at fs/btrfs/inode.c:3420 btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420\n Modules linked in:\n CPU: 0 UID: 0 PID: 65 Comm: kworker/u8:4 Not tainted 6.15.0-next-20250530-syzkaller #0 PREEMPT(full)\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n Workqueue: btrfs-endio-write btrfs_work_helper\n RIP: 0010:btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420\n Code: 4e ad 5d (...)\n RSP: 0018:ffffc9000213f780 EFLAGS: 00010293\n RAX: ffffffff83c635b7 RBX: ffff888058920000 RCX: ffff88801c769e00\n RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000000\n RBP: 0000000000000001 R08: ffff888058921b67 R09: 1ffff1100b12436c\n R10: dffffc0000000000 R11: ffffed100b12436d R12: 0000000000000001\n R13: dffffc0000000000 R14: ffff88807d748000 R15: 0000000000000100\n FS: 0000000000000000(0000) GS:ffff888125c53000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00002000000bd038 CR3: 000000006a142000 CR4: 00000000003526f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \n btrfs_put_ordered_extent+0x19f/0x470 fs/btrfs/ordered-data.c:635\n btrfs_finish_one_ordered+0x11d8/0x1b10 fs/btrfs/inode.c:3312\n btrfs_work_helper+0x399/0xc20 fs/btrfs/async-thread.c:312\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x70e/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \n\nThis can happen due to a race with the async reclaim worker like this:\n\n1) The async metadata reclaim worker enters shrink_delalloc(), which calls\n btrfs_start_delalloc_roots() with an nr_pages argument that has a value\n less than LONG_MAX, and that in turn enters start_delalloc_inodes(),\n which sets the local variable 'full_flush' to false because\n wbc->nr_to_write is less than LONG_MAX;\n\n2) There it finds inode X in a root's delalloc list, grabs a reference for\n inode X (with igrab()), and triggers writeback for it with\n filemap_fdatawrite_wbc(), which creates an ordered extent for inode X;\n\n3) The unmount sequence starts from another task, we enter close_ctree()\n and we flush the workqueue fs_info->endio_write_workers, which waits\n for the ordered extent for inode X to complete and when dropping the\n last reference of the ordered extent, with btrfs_put_ordered_extent(),\n when we call btrfs_add_delayed_iput() we don't add the inode to the\n list of delayed iputs because it has a refcount of 2, so we decrement\n it to 1 and return;\n\n4) Shortly after at close_ctree() we call btrfs_run_delayed_iputs() which\n runs all delayed iputs, and then we set BTRFS_FS_STATE_NO_DELAYED_IPUT\n in the fs_info state;\n\n5) The async reclaim worker, after calling filemap_fdatawrite_wbc(), now\n calls btrfs_add_delayed_iput() for inode X and there we trigger an\n assertion failure since the fs_info state has the flag\n BTRFS_FS_STATE_NO_DELAYED_IPUT set.\n\nFix this by setting BTRFS_FS_STATE_NO_DELAYED_IPUT only after we wait for\nthe async reclaim workers to finish, after we call cancel_work_sync() for\nthem at close_ctree(), and by running delayed iputs after wait for the\nreclaim workers to finish and before setting the bit.\n\nThis race was recently introduced by commit 19e60b2a95f5 ("btrfs: add\nextra warning if delayed iput is added when it's not allowed"). Without\nthe new validation at btrfs_add_delayed_iput(), \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix runtime warning on truncate_folio_batch_exceptionals()\n\nThe WARN_ON_ONCE is introduced on truncate_folio_batch_exceptionals() to\ncapture whether the filesystem has removed all DAX entries or not.\n\nAnd the fix has been applied on the filesystem xfs and ext4 by the commit\n0e2f80afcfa6 ("fs/dax: ensure all pages are idle prior to filesystem\nunmount").\n\nApply the missed fix on filesystem fuse to fix the runtime warning:\n\n[ 2.011450] ------------[ cut here ]------------\n[ 2.011873] WARNING: CPU: 0 PID: 145 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0x272/0x2b0\n[ 2.012468] Modules linked in:\n[ 2.012718] CPU: 0 UID: 1000 PID: 145 Comm: weston Not tainted 6.16.0-rc2-WSL2-STABLE #2 PREEMPT(undef)\n[ 2.013292] RIP: 0010:truncate_folio_batch_exceptionals+0x272/0x2b0\n[ 2.013704] Code: 48 63 d0 41 29 c5 48 8d 1c d5 00 00 00 00 4e 8d 6c 2a 01 49 c1 e5 03 eb 09 48 83 c3 08 49 39 dd 74 83 41 f6 44 1c 08 01 74 ef <0f> 0b 49 8b 34 1e 48 89 ef e8 10 a2 17 00 eb df 48 8b 7d 00 e8 35\n[ 2.014845] RSP: 0018:ffffa47ec33f3b10 EFLAGS: 00010202\n[ 2.015279] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n[ 2.015884] RDX: 0000000000000000 RSI: ffffa47ec33f3ca0 RDI: ffff98aa44f3fa80\n[ 2.016377] RBP: ffff98aa44f3fbf0 R08: ffffa47ec33f3ba8 R09: 0000000000000000\n[ 2.016942] R10: 0000000000000001 R11: 0000000000000000 R12: ffffa47ec33f3ca0\n[ 2.017437] R13: 0000000000000008 R14: ffffa47ec33f3ba8 R15: 0000000000000000\n[ 2.017972] FS: 000079ce006afa40(0000) GS:ffff98aade441000(0000) knlGS:0000000000000000\n[ 2.018510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 2.018987] CR2: 000079ce03e74000 CR3: 000000010784f006 CR4: 0000000000372eb0\n[ 2.019518] Call Trace:\n[ 2.019729] \n[ 2.019901] truncate_inode_pages_range+0xd8/0x400\n[ 2.020280] ? timerqueue_add+0x66/0xb0\n[ 2.020574] ? get_nohz_timer_target+0x2a/0x140\n[ 2.020904] ? timerqueue_add+0x66/0xb0\n[ 2.021231] ? timerqueue_del+0x2e/0x50\n[ 2.021646] ? __remove_hrtimer+0x39/0x90\n[ 2.022017] ? srso_alias_untrain_ret+0x1/0x10\n[ 2.022497] ? psi_group_change+0x136/0x350\n[ 2.023046] ? _raw_spin_unlock+0xe/0x30\n[ 2.023514] ? finish_task_switch.isra.0+0x8d/0x280\n[ 2.024068] ? __schedule+0x532/0xbd0\n[ 2.024551] fuse_evict_inode+0x29/0x190\n[ 2.025131] evict+0x100/0x270\n[ 2.025641] ? _atomic_dec_and_lock+0x39/0x50\n[ 2.026316] ? __pfx_generic_delete_inode+0x10/0x10\n[ 2.026843] __dentry_kill+0x71/0x180\n[ 2.027335] dput+0xeb/0x1b0\n[ 2.027725] __fput+0x136/0x2b0\n[ 2.028054] __x64_sys_close+0x3d/0x80\n[ 2.028469] do_syscall_64+0x6d/0x1b0\n[ 2.028832] ? clear_bhb_loop+0x30/0x80\n[ 2.029182] ? clear_bhb_loop+0x30/0x80\n[ 2.029533] ? clear_bhb_loop+0x30/0x80\n[ 2.029902] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 2.030423] RIP: 0033:0x79ce03d0d067\n[ 2.030820] Code: b8 ff ff ff ff e9 3e ff ff ff 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 c3 a7 f8 ff\n[ 2.032354] RSP: 002b:00007ffef0498948 EFLAGS: 00000246 ORIG_RAX: 0000000000000003\n[ 2.032939] RAX: ffffffffffffffda RBX: 00007ffef0498960 RCX: 000079ce03d0d067\n[ 2.033612] RDX: 0000000000000003 RSI: 0000000000001000 RDI: 000000000000000d\n[ 2.034289] RBP: 00007ffef0498a30 R08: 000000000000000d R09: 0000000000000000\n[ 2.034944] R10: 00007ffef0498978 R11: 0000000000000246 R12: 0000000000000001\n[ 2.035610] R13: 00007ffef0498960 R14: 000079ce03e09ce0 R15: 0000000000000003\n[ 2.036301] \n[ 2.036532] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/guc: Explicitly exit CT safe mode on unwind\n\nDuring driver probe we might be briefly using CT safe mode, which\nis based on a delayed work, but usually we are able to stop this\nonce we have IRQ fully operational. However, if we abort the probe\nquite early then during unwind we might try to destroy the workqueue\nwhile there is still a pending delayed work that attempts to restart\nitself which triggers a WARN.\n\nThis was recently observed during unsuccessful VF initialization:\n\n [ ] xe 0000:00:02.1: probe with driver xe failed with error -62\n [ ] ------------[ cut here ]------------\n [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq\n [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710\n [ ] RIP: 0010:__queue_work+0x287/0x710\n [ ] Call Trace:\n [ ] delayed_work_timer_fn+0x19/0x30\n [ ] call_timer_fn+0xa1/0x2a0\n\nExit the CT safe mode on unwind to avoid that warning.\n\n(cherry picked from commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Process deferred GGTT node removals on device unwind\n\nWhile we are indirectly draining our dedicated workqueue ggtt->wq\nthat we use to complete asynchronous removal of some GGTT nodes,\nthis happends as part of the managed-drm unwinding (ggtt_fini_early),\nwhich could be later then manage-device unwinding, where we could\nalready unmap our MMIO/GMS mapping (mmio_fini).\n\nThis was recently observed during unsuccessful VF initialization:\n\n [ ] xe 0000:00:02.1: probe with driver xe failed with error -62\n [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes)\n [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes)\n [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes)\n [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes)\n [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes)\n [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes)\n [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes)\n [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin\n [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes)\n [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes)\n [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes)\n [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes)\n\nand this was leading to:\n\n [ ] BUG: unable to handle page fault for address: ffffc900058162a0\n [ ] #PF: supervisor write access in kernel mode\n [ ] #PF: error_code(0x0002) - not-present page\n [ ] Oops: Oops: 0002 [#1] SMP NOPTI\n [ ] Tainted: [W]=WARN\n [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe]\n [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe]\n [ ] Call Trace:\n [ ] \n [ ] xe_ggtt_clear+0xb0/0x270 [xe]\n [ ] ggtt_node_remove+0xbb/0x120 [xe]\n [ ] ggtt_node_remove_work_func+0x30/0x50 [xe]\n [ ] process_one_work+0x22b/0x6f0\n [ ] worker_thread+0x1e8/0x3d\n\nAdd managed-device action that will explicitly drain the workqueue\nwith all pending node removals prior to releasing MMIO/GSM mapping.\n\n(cherry picked from commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix taking invalid lock on wedge\n\nIf device wedges on e.g. GuC upload, the submission is not yet enabled\nand the state is not even initialized. Protect the wedge call so it does\nnothing in this case. It fixes the following splat:\n\n [] xe 0000:bf:00.0: [drm] device wedged, needs recovery\n [] ------------[ cut here ]------------\n [] DEBUG_LOCKS_WARN_ON(lock->magic != lock)\n [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60\n ...\n [] RIP: 0010:__mutex_lock+0x8a1/0xe60\n [] mutex_lock_nested+0x1b/0x30\n [] xe_guc_submit_wedge+0x80/0x2b0 [xe]

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush\n\nIn KVM guests with Hyper-V hypercalls enabled, the hypercalls\nHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX\nallow a guest to request invalidation of portions of a virtual TLB.\nFor this, the hypercall parameter includes a list of GVAs that are supposed\nto be invalidated.\n\nHowever, when non-canonical GVAs are passed, there is currently no\nfiltering in place and they are eventually passed to checked invocations of\nINVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores\nnon-canonical addresses (effectively a no-op), Intel's INVVPID explicitly\nsignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():\n\n invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000\n WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482\n invvpid_error+0x91/0xa0 [kvm_intel]\n Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse\n CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)\n RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]\n Call Trace:\n vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]\n kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]\n\nHyper-V documents that invalid GVAs (those that are beyond a partition's\nGVA space) are to be ignored. While not completely clear whether this\nruling also applies to non-canonical GVAs, it is likely fine to make that\nassumption, and manual testing on Azure confirms "real" Hyper-V interprets\nthe specification in the same way.\n\nSkip non-canonical GVAs when processing the list of address to avoid\ntripping the INVVPID failure. Alternatively, KVM could filter out "bad"\nGVAs before inserting into the FIFO, but practically speaking the only\ndownside of pushing validation to the final processing is that doing so\nis suboptimal for the guest, and no well-behaved guest will request TLB\nflushes for non-canonical addresses.

A `named` caching resolver that is configured to send ECS (EDNS Client Subnet) options may be vulnerable to a cache-poisoning attack.\nThis issue affects BIND 9 versions 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.37-S1, and 9.20.9-S1 through 9.20.10-S1.

NTLMSSP dissector crash in Wireshark 4.2.0 to 4.0.6 and 4.0.0 to 4.0.16 allows denial of service via packet injection or crafted capture file

An out-of-memory condition during object initialization could result in an empty shape list. If the JIT subsequently traced the object it would crash. This vulnerability affects Firefox < 125.

A `<dialog>` element could have been manipulated to paint content outside of a sandboxed iframe. This could allow untrusted content to display under the guise of trusted content. This vulnerability affects Firefox < 121.

In some instances, the user-agent would allow push requests which lacked a valid VAPID even though the push manager subscription defined one. This could allow empty messages to be sent from unauthorized parties.\n*This bug only affects Firefox on Android.* This vulnerability affects Firefox < 121.

If an attacker needed a user to load an insecure http: page and knew that user had enabled HTTPS-only mode, the attacker could have tricked the user into clicking to grant an HTTPS-only exception if they could get the user to participate in a clicking game. This vulnerability affects Firefox < 120.

When an https: web page created a pop-up from a "javascript:" URL, that pop-up was incorrectly allowed to load blockable content such as iframes from insecure http: URLs This vulnerability affects Firefox < 120.

A malicious web site can enter fullscreen mode while simultaneously triggering a WebAuthn prompt. This could have obscured the fullscreen notification and could have been leveraged in a spoofing attack. This vulnerability affects Firefox < 119.

An attacker with temporary script access to a site could have set a cookie containing invalid characters using `document.cookie` that could have led to unknown errors. This vulnerability affects Firefox < 119.

Using iterative requests an attacker was able to learn the size of an opaque response, as well as the contents of a server-supplied Vary header. This vulnerability affects Firefox < 119.

Search queries in the default search engine could appear to have been the currently navigated URL if the search query itself was a well formed URL. This could have led to a site spoofing another if it had been maliciously set as the default search engine. This vulnerability affects Firefox < 117.

Buffer Overflow vulnerability in PSDParser.cpp::ReadImageLine() in FreeImage 3.19.0 [r1859] allows remote attackers to ru narbitrary code via use of crafted psd file.

Buffer Overflow vulnerability in psdThumbnail::Read in PSDParser.cpp in FreeImage 3.19.0 [r1859] allows remote attackers to run arbitrary code via opening of crafted psd file.

Under certain conditions, Firefox did not display a warning when a user attempted to navigate to a new protocol handler. This vulnerability affects Firefox < 121.

Applications which spawn a Toast notification in a background thread may have obscured fullscreen notifications displayed by Firefox. \n*This issue only affects Android versions of Firefox and Firefox Focus.* This vulnerability affects Firefox < 121.

No description is available for this CVE.

OpenCV is an Open Source Computer Vision Library. Versions prior to 4.12.0 have an uninitialized pointer variable on stack that may lead to arbitrary heap buffer write when reading crafted JPEG images. Version 4.12.0 fixes the vulnerability.

Gitk is a Tcl/Tk based Git history browser. Starting with 2.41.0, a Git repository can be crafted in such a way that with some social engineering a user who has cloned the repository can be tricked into running any script (e.g., Bourne shell, Perl, Python, ...) supplied by the attacker by invoking gitk filename, where filename has a particular structure. The script is run with the privileges of the user. This vulnerability is fixed in 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1, and 2.50.

Browser tab titles were being leaked by GNOME to system logs. This could potentially expose the browsing habits of users running in a private tab. This vulnerability affects Firefox < 121.

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:\npowerpc/bpf: fix JIT code size calculation of bpf trampoline\narch_bpf_trampoline_size() provides JIT size of the BPF trampoline\nbefore the buffer for JIT'ing it is allocated. The total number of\ninstructions emitted for BPF trampoline JIT code depends on where\nthe final image is located. So, the size arrived at with the dummy\npass in arch_bpf_trampoline_size() can vary from the actual size\nneeded in arch_prepare_bpf_trampoline(). When the instructions\naccounted in arch_bpf_trampoline_size() is less than the number of\ninstructions emitted during the actual JIT compile of the trampoline,\nthe below warning is produced:\nWARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc\nwhich is:\n/* Make sure the trampoline generation logic doesn't overflow */\nif (image && WARN_ON_ONCE(&image[ctx->idx] >\n(u32 *)rw_image_end - BPF_INSN_SAFETY)) {\nSo, during the dummy pass, instead of providing some arbitrary image\nlocation, account for maximum possible instructions if and when there\nis a dependency with image location for JIT'ing.

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:\n\nnvme-tcp: sanitize request list handling\n\nValidate the request in nvme_tcp_handle_r2t() to ensure it's not part of\nany list, otherwise a malicious R2T PDU might inject a loop in request\nlist processing.

In the Linux kernel, the following vulnerability has been resolved:\nriscv: save the SR_SUM status over switches\nWhen threads/tasks are switched we need to ensure the old execution's\nSR_SUM state is saved and the new thread has the old SR_SUM state\nrestored.\nThe issue was seen under heavy load especially with the syz-stress tool\nrunning, with crashes as follows in schedule_tail:\nUnable to handle kernel access to user memory without uaccess routines\nat virtual address 000000002749f0d0\nOops [#1]\nModules linked in:\nCPU: 1 PID: 4875 Comm: syz-executor.0 Not tainted\n5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0\nHardware name: riscv-virtio,qemu (DT)\nepc : schedule_tail+0x72/0xb2 kernel/sched/core.c:4264\nra : task_pid_vnr include/linux/sched.h:1421 [inline]\nra : schedule_tail+0x70/0xb2 kernel/sched/core.c:4264\nepc : ffffffe00008c8b0 ra : ffffffe00008c8ae sp : ffffffe025d17ec0\ngp : ffffffe005d25378 tp : ffffffe00f0d0000 t0 : 0000000000000000\nt1 : 0000000000000001 t2 : 00000000000f4240 s0 : ffffffe025d17ee0\ns1 : 000000002749f0d0 a0 : 000000000000002a a1 : 0000000000000003\na2 : 1ffffffc0cfac500 a3 : ffffffe0000c80cc a4 : 5ae9db91c19bbe00\na5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba\ns2 : 0000000000040000 s3 : ffffffe00eef96c0 s4 : ffffffe022c77fe0\ns5 : 0000000000004000 s6 : ffffffe067d74e00 s7 : ffffffe067d74850\ns8 : ffffffe067d73e18 s9 : ffffffe067d74e00 s10: ffffffe00eef96e8\ns11: 000000ae6cdf8368 t3 : 5ae9db91c19bbe00 t4 : ffffffc4043cafb2\nt5 : ffffffc4043cafba t6 : 0000000000040000\nstatus: 0000000000000120 badaddr: 000000002749f0d0 cause:\n000000000000000f\nCall Trace:\n[] schedule_tail+0x72/0xb2 kernel/sched/core.c:4264\n[] ret_from_exception+0x0/0x14\nDumping ftrace buffer:\n(ftrace buffer empty)\n---[ end trace b5f8f9231dc87dda ]---\nThe issue comes from the put_user() in schedule_tail\n(kernel/sched/core.c) doing the following:\nasmlinkage __visible void schedule_tail(struct task_struct *prev)\n{\n...\nif (current->set_child_tid)\nput_user(task_pid_vnr(current), current->set_child_tid);\n...\n}\nthe put_user() macro causes the code sequence to come out as follows:\n1:__enable_user_access()\n2:reg = task_pid_vnr(current);\n3:*current->set_child_tid = reg;\n4:__disable_user_access()\nThe problem is that we may have a sleeping function as argument which\ncould clear SR_SUM causing the panic above. This was fixed by\nevaluating the argument of the put_user() macro outside the user-enabled\nsection in commit 285a76bb2cf5 ("riscv: evaluate put_user() arg before\nenabling user access")"\nIn order for riscv to take advantage of unsafe_get/put_XXX() macros and\nto avoid the same issue we had with put_user() and sleeping functions we\nmust ensure code flow can go through switch_to() from within a region of\ncode with SR_SUM enabled and come back with SR_SUM still enabled. This\npatch addresses the problem allowing future work to enable full use of\nunsafe_get/put_XXX() macros without needing to take a CSR bit flip cost\non every access. Make switch_to() save and restore SR_SUM.