In the Linux kernel, the following vulnerability has been resolved:\n\nionic: use dev_consume_skb_any outside of napi\n\nIf we're not in a NAPI softirq context, we need to be careful\nabout how we call napi_consume_skb(), specifically we need to\ncall it with budget==0 to signal to it that we're not in a\nsafe context.\n\nThis was found while running some configuration stress testing\nof traffic and a change queue config loop running, and this\ncurious note popped out:\n\n[ 4371.402645] BUG: using smp_processor_id() in preemptible [00000000] code: ethtool/20545\n[ 4371.402897] caller is napi_skb_cache_put+0x16/0x80\n[ 4371.403120] CPU: 25 PID: 20545 Comm: ethtool Kdump: loaded Tainted: G OE 6.10.0-rc3-netnext+ #8\n[ 4371.403302] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 01/23/2021\n[ 4371.403460] Call Trace:\n[ 4371.403613] \n[ 4371.403758] dump_stack_lvl+0x4f/0x70\n[ 4371.403904] check_preemption_disabled+0xc1/0xe0\n[ 4371.404051] napi_skb_cache_put+0x16/0x80\n[ 4371.404199] ionic_tx_clean+0x18a/0x240 [ionic]\n[ 4371.404354] ionic_tx_cq_service+0xc4/0x200 [ionic]\n[ 4371.404505] ionic_tx_flush+0x15/0x70 [ionic]\n[ 4371.404653] ? ionic_lif_qcq_deinit.isra.23+0x5b/0x70 [ionic]\n[ 4371.404805] ionic_txrx_deinit+0x71/0x190 [ionic]\n[ 4371.404956] ionic_reconfigure_queues+0x5f5/0xff0 [ionic]\n[ 4371.405111] ionic_set_ringparam+0x2e8/0x3e0 [ionic]\n[ 4371.405265] ethnl_set_rings+0x1f1/0x300\n[ 4371.405418] ethnl_default_set_doit+0xbb/0x160\n[ 4371.405571] genl_family_rcv_msg_doit+0xff/0x130\n [...]\n\nI found that ionic_tx_clean() calls napi_consume_skb() which calls\nnapi_skb_cache_put(), but before that last call is the note\n /* Zero budget indicate non-NAPI context called us, like netpoll */\nand\n DEBUG_NET_WARN_ON_ONCE(!in_softirq());\n\nThose are pretty big hints that we're doing it wrong. We can pass a\ncontext hint down through the calls to let ionic_tx_clean() know what\nwe're doing so it can call napi_consume_skb() correctly.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mana: Fix possible double free in error handling path\n\nWhen auxiliary_device_add() returns error and then calls\nauxiliary_device_uninit(), callback function adev_release\ncalls kfree(madev). We shouldn't call kfree(madev) again\nin the error handling path. Set 'madev' to NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-core: Fix null pointer dereference on error\n\nIf the ata_port_alloc() call in ata_host_alloc() fails,\nata_host_release() will get called.\n\nHowever, the code in ata_host_release() tries to free ata_port struct\nmembers unconditionally, which can lead to the following:\n\nBUG: unable to handle page fault for address: 0000000000003990\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]\nCode: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41\nRSP: 0018:ffffc90000ebb968 EFLAGS: 00010246\nRAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0\nRBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68\nR10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004\nR13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006\nFS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2f0\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? ata_host_release.cold+0x2f/0x6e [libata]\n ? ata_host_release.cold+0x2f/0x6e [libata]\n release_nodes+0x35/0xb0\n devres_release_group+0x113/0x140\n ata_host_alloc+0xed/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\n\nDo not access ata_port struct members unconditionally.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/MSI: Fix UAF in msi_capability_init\n\nKFENCE reports the following UAF:\n\n BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488\n\n Use-after-free read at 0x0000000024629571 (in kfence-#12):\n __pci_enable_msi_range+0x2c0/0x488\n pci_alloc_irq_vectors_affinity+0xec/0x14c\n pci_alloc_irq_vectors+0x18/0x28\n\n kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128\n\n allocated by task 81 on cpu 7 at 10.808142s:\n __kmem_cache_alloc_node+0x1f0/0x2bc\n kmalloc_trace+0x44/0x138\n msi_alloc_desc+0x3c/0x9c\n msi_domain_insert_msi_desc+0x30/0x78\n msi_setup_msi_desc+0x13c/0x184\n __pci_enable_msi_range+0x258/0x488\n pci_alloc_irq_vectors_affinity+0xec/0x14c\n pci_alloc_irq_vectors+0x18/0x28\n\n freed by task 81 on cpu 7 at 10.811436s:\n msi_domain_free_descs+0xd4/0x10c\n msi_domain_free_locked.part.0+0xc0/0x1d8\n msi_domain_alloc_irqs_all_locked+0xb4/0xbc\n pci_msi_setup_msi_irqs+0x30/0x4c\n __pci_enable_msi_range+0x2a8/0x488\n pci_alloc_irq_vectors_affinity+0xec/0x14c\n pci_alloc_irq_vectors+0x18/0x28\n\nDescriptor allocation done in:\n__pci_enable_msi_range\n msi_capability_init\n msi_setup_msi_desc\n msi_insert_msi_desc\n msi_domain_insert_msi_desc\n msi_alloc_desc\n ...\n\nFreed in case of failure in __msi_domain_alloc_locked()\n__pci_enable_msi_range\n msi_capability_init\n pci_msi_setup_msi_irqs\n msi_domain_alloc_irqs_all_locked\n msi_domain_alloc_locked\n __msi_domain_alloc_locked => fails\n msi_domain_free_locked\n ...\n\nThat failure propagates back to pci_msi_setup_msi_irqs() in\nmsi_capability_init() which accesses the descriptor for unmasking in the\nerror exit path.\n\nCure it by copying the descriptor and using the copy for the error exit path\nunmask operation.\n\n[ tglx: Massaged change log ]

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/fbdev-dma: Only set smem_start is enable per module option\n\nOnly export struct fb_info.fix.smem_start if that is required by the\nuser and the memory does not come from vmalloc().\n\nSetting struct fb_info.fix.smem_start breaks systems where DMA\nmemory is backed by vmalloc address space. An example error is\nshown below.\n\n[ 3.536043] ------------[ cut here ]------------\n[ 3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000)\n[ 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98\n[ 3.565455] Modules linked in:\n[ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250\n[ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT)\n[ 3.582452] Workqueue: events_unbound deferred_probe_work_func\n[ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 3.595233] pc : __virt_to_phys+0x68/0x98\n[ 3.599246] lr : __virt_to_phys+0x68/0x98\n[ 3.603276] sp : ffff800083603990\n[ 3.677939] Call trace:\n[ 3.680393] __virt_to_phys+0x68/0x98\n[ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238\n[ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0\n[ 3.695385] drm_fb_helper_initial_config+0x4c/0x68\n[ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0\n[ 3.705161] drm_client_register+0x60/0xb0\n[ 3.709269] drm_fbdev_dma_setup+0x94/0x148\n\nAdditionally, DMA memory is assumed to by contiguous in physical\naddress space, which is not guaranteed by vmalloc().\n\nResolve this by checking the module flag drm_leak_fbdev_smem when\nDRM allocated the instance of struct fb_info. Fbdev-dma then only\nsets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also\nguarantee that the framebuffer is not located in vmalloc address\nspace.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/region: Avoid null pointer dereference in region lookup\n\ncxl_dpa_to_region() looks up a region based on a memdev and DPA.\nIt wrongly assumes an endpoint found mapping the DPA is also of\na fully assembled region. When not true it leads to a null pointer\ndereference looking up the region name.\n\nThis appears during testing of region lookup after a failure to\nassemble a BIOS defined region or if the lookup raced with the\nassembly of the BIOS defined region.\n\nFailure to clean up BIOS defined regions that fail assembly is an\nissue in itself and a fix to that problem will alleviate some of\nthe impact. It will not alleviate the race condition so let's harden\nthis path.\n\nThe behavior change is that the kernel oops due to a null pointer\ndereference is replaced with a dev_dbg() message noting that an\nendpoint was mapped.\n\nAdditional comments are added so that future users of this function\ncan more clearly understand what it provides.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix netfs_page_mkwrite() to check folio->mapping is valid\n\nFix netfs_page_mkwrite() to check that folio->mapping is valid once it has\ntaken the folio lock (as filemap_page_mkwrite() does). Without this,\ngeneric/247 occasionally oopses with something like the following:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n\n RIP: 0010:trace_event_raw_event_netfs_folio+0x61/0xc0\n ...\n Call Trace:\n \n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x6e/0xa0\n ? exc_page_fault+0xc2/0xe0\n ? asm_exc_page_fault+0x22/0x30\n ? trace_event_raw_event_netfs_folio+0x61/0xc0\n trace_netfs_folio+0x39/0x40\n netfs_page_mkwrite+0x14c/0x1d0\n do_page_mkwrite+0x50/0x90\n do_pte_missing+0x184/0x200\n __handle_mm_fault+0x42d/0x500\n handle_mm_fault+0x121/0x1f0\n do_user_addr_fault+0x23e/0x3c0\n exc_page_fault+0xc2/0xe0\n asm_exc_page_fault+0x22/0x30\n\nThis is due to the invalidate_inode_pages2_range() issued at the end of the\nDIO write interfering with the mmap'd writes.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix ufshcd_clear_cmd racing issue\n\nWhen ufshcd_clear_cmd is racing with the completion ISR, the completed tag\nof the request's mq_hctx pointer will be set to NULL by the ISR. And\nufshcd_clear_cmd's call to ufshcd_mcq_req_to_hwq will get NULL pointer KE.\nReturn success when the request is completed by ISR because sq does not\nneed cleanup.\n\nThe racing flow is:\n\nThread A\nufshcd_err_handler step 1\n ufshcd_try_to_abort_task\n ufshcd_cmd_inflight(true) step 3\n ufshcd_clear_cmd\n ...\n ufshcd_mcq_req_to_hwq\n blk_mq_unique_tag\n rq->mq_hctx->queue_num step 5\n\nThread B\nufs_mtk_mcq_intr(cq complete ISR) step 2\n scsi_done\n ...\n __blk_mq_free_request\n rq->mq_hctx = NULL; step 4\n\nBelow is KE back trace:\n\n ufshcd_try_to_abort_task: cmd pending in the device. tag = 6\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194\n pc : [0xffffffd589679bf8] blk_mq_unique_tag+0x8/0x14\n lr : [0xffffffd5862f95b4] ufshcd_mcq_sq_cleanup+0x6c/0x1cc [ufs_mediatek_mod_ise]\n Workqueue: ufs_eh_wq_0 ufshcd_err_handler [ufs_mediatek_mod_ise]\n Call trace:\n dump_backtrace+0xf8/0x148\n show_stack+0x18/0x24\n dump_stack_lvl+0x60/0x7c\n dump_stack+0x18/0x3c\n mrdump_common_die+0x24c/0x398 [mrdump]\n ipanic_die+0x20/0x34 [mrdump]\n notify_die+0x80/0xd8\n die+0x94/0x2b8\n __do_kernel_fault+0x264/0x298\n do_page_fault+0xa4/0x4b8\n do_translation_fault+0x38/0x54\n do_mem_abort+0x58/0x118\n el1_abort+0x3c/0x5c\n el1h_64_sync_handler+0x54/0x90\n el1h_64_sync+0x68/0x6c\n blk_mq_unique_tag+0x8/0x14\n ufshcd_clear_cmd+0x34/0x118 [ufs_mediatek_mod_ise]\n ufshcd_try_to_abort_task+0x2c8/0x5b4 [ufs_mediatek_mod_ise]\n ufshcd_err_handler+0xa7c/0xfa8 [ufs_mediatek_mod_ise]\n process_one_work+0x208/0x4fc\n worker_thread+0x228/0x438\n kthread+0x104/0x1d4\n ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix ufshcd_abort_one racing issue\n\nWhen ufshcd_abort_one is racing with the completion ISR, the completed tag\nof the request's mq_hctx pointer will be set to NULL by ISR. Return\nsuccess when request is completed by ISR because ufshcd_abort_one does not\nneed to do anything.\n\nThe racing flow is:\n\nThread A\nufshcd_err_handler step 1\n ...\n ufshcd_abort_one\n ufshcd_try_to_abort_task\n ufshcd_cmd_inflight(true) step 3\n ufshcd_mcq_req_to_hwq\n blk_mq_unique_tag\n rq->mq_hctx->queue_num step 5\n\nThread B\nufs_mtk_mcq_intr(cq complete ISR) step 2\n scsi_done\n ...\n __blk_mq_free_request\n rq->mq_hctx = NULL; step 4\n\nBelow is KE back trace.\n ufshcd_try_to_abort_task: cmd at tag 41 not pending in the device.\n ufshcd_try_to_abort_task: cmd at tag=41 is cleared.\n Aborting tag 41 / CDB 0x28 succeeded\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194\n pc : [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14\n lr : [0xffffffddd6155b84] ufshcd_mcq_req_to_hwq+0x1c/0x40 [ufs_mediatek_mod_ise]\n do_mem_abort+0x58/0x118\n el1_abort+0x3c/0x5c\n el1h_64_sync_handler+0x54/0x90\n el1h_64_sync+0x68/0x6c\n blk_mq_unique_tag+0x8/0x14\n ufshcd_err_handler+0xae4/0xfa8 [ufs_mediatek_mod_ise]\n process_one_work+0x208/0x4fc\n worker_thread+0x228/0x438\n kthread+0x104/0x1d4\n ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: Init the count variable in collecting hot-reset devices\n\nThe count variable is used without initialization, it results in mistakes\nin the device counting and crashes the userspace if the get hot reset info\npath is triggered.

In the Linux kernel, the following vulnerability has been resolved:\n\nfilelock: fix potential use-after-free in posix_lock_inode\n\nLight Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().\nThe request pointer had been changed earlier to point to a lock entry\nthat was added to the inode's list. However, before the tracepoint could\nfire, another task raced in and freed that lock.\n\nFix this by moving the tracepoint inside the spinlock, which should\nensure that this doesn't happen.

In the Linux kernel, the following vulnerability has been resolved:\n\nskmsg: Skip zero length skb in sk_msg_recvmsg\n\nWhen running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch\nplatform, the following kernel panic occurs:\n\n [...]\n Oops[#1]:\n CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18\n Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018\n ... ...\n ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560\n ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0\n CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n PRMD: 0000000c (PPLV0 +PIE +PWE)\n EUEN: 00000007 (+FPE +SXE +ASXE -BTE)\n ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)\n ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)\n BADV: 0000000000000040\n PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)\n Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack\n Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)\n Stack : ...\n Call Trace:\n [<9000000004162774>] copy_page_to_iter+0x74/0x1c0\n [<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560\n [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0\n [<90000000049aae34>] inet_recvmsg+0x54/0x100\n [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0\n [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0\n [<900000000481e27c>] sys_recvfrom+0x1c/0x40\n [<9000000004c076ec>] do_syscall+0x8c/0xc0\n [<9000000003731da4>] handle_syscall+0xc4/0x160\n Code: ...\n ---[ end trace 0000000000000000 ]---\n Kernel panic - not syncing: Fatal exception\n Kernel relocated by 0x3510000\n .text @ 0x9000000003710000\n .data @ 0x9000000004d70000\n .bss @ 0x9000000006469400\n ---[ end Kernel panic - not syncing: Fatal exception ]---\n [...]\n\nThis crash happens every time when running sockmap_skb_verdict_shutdown\nsubtest in sockmap_basic.\n\nThis crash is because a NULL pointer is passed to page_address() in the\nsk_msg_recvmsg(). Due to the different implementations depending on the\narchitecture, page_address(NULL) will trigger a panic on Loongarch\nplatform but not on x86 platform. So this bug was hidden on x86 platform\nfor a while, but now it is exposed on Loongarch platform. The root cause\nis that a zero length skb (skb->len == 0) was put on the queue.\n\nThis zero length skb is a TCP FIN packet, which was sent by shutdown(),\ninvoked in test_sockmap_skb_verdict_shutdown():\n\n shutdown(p1, SHUT_WR);\n\nIn this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no\npage is put to this sge (see sg_set_page in sg_set_page), but this empty\nsge is queued into ingress_msg list.\n\nAnd in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by\nsg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it\nto kmap_local_page() and to page_address(), then kernel panics.\n\nTo solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),\nif copy is zero, that means it's a zero length skb, skip invoking\ncopy_page_to_iter(). We are using the EFAULT return triggered by\ncopy_page_to_iter to check for is_fin in tcp_bpf.c.

In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix XDP program unloading while removing the driver\n\nThe commit 6533e558c650 ("i40e: Fix reset path while removing\nthe driver") introduced a new PF state "__I40E_IN_REMOVE" to block\nmodifying the XDP program while the driver is being removed.\nUnfortunately, such a change is useful only if the ".ndo_bpf()"\ncallback was called out of the rmmod context because unloading the\nexisting XDP program is also a part of driver removing procedure.\nIn other words, from the rmmod context the driver is expected to\nunload the XDP program without reporting any errors. Otherwise,\nthe kernel warning with callstack is printed out to dmesg.\n\nExample failing scenario:\n 1. Load the i40e driver.\n 2. Load the XDP program.\n 3. Unload the i40e driver (using "rmmod" command).\n\nThe example kernel warning log:\n\n[ +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870\n[...]\n[ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870\n[...]\n[ +0.002726] Call Trace:\n[ +0.002457] \n[ +0.002119] ? __warn+0x80/0x120\n[ +0.003245] ? unregister_netdevice_many_notify+0x7a9/0x870\n[ +0.005586] ? report_bug+0x164/0x190\n[ +0.003678] ? handle_bug+0x3c/0x80\n[ +0.003503] ? exc_invalid_op+0x17/0x70\n[ +0.003846] ? asm_exc_invalid_op+0x1a/0x20\n[ +0.004200] ? unregister_netdevice_many_notify+0x7a9/0x870\n[ +0.005579] ? unregister_netdevice_many_notify+0x3cc/0x870\n[ +0.005586] unregister_netdevice_queue+0xf7/0x140\n[ +0.004806] unregister_netdev+0x1c/0x30\n[ +0.003933] i40e_vsi_release+0x87/0x2f0 [i40e]\n[ +0.004604] i40e_remove+0x1a1/0x420 [i40e]\n[ +0.004220] pci_device_remove+0x3f/0xb0\n[ +0.003943] device_release_driver_internal+0x19f/0x200\n[ +0.005243] driver_detach+0x48/0x90\n[ +0.003586] bus_remove_driver+0x6d/0xf0\n[ +0.003939] pci_unregister_driver+0x2e/0xb0\n[ +0.004278] i40e_exit_module+0x10/0x5f0 [i40e]\n[ +0.004570] __do_sys_delete_module.isra.0+0x197/0x310\n[ +0.005153] do_syscall_64+0x85/0x170\n[ +0.003684] ? syscall_exit_to_user_mode+0x69/0x220\n[ +0.004886] ? do_syscall_64+0x95/0x170\n[ +0.003851] ? exc_page_fault+0x7e/0x180\n[ +0.003932] entry_SYSCALL_64_after_hwframe+0x71/0x79\n[ +0.005064] RIP: 0033:0x7f59dc9347cb\n[ +0.003648] Code: 73 01 c3 48 8b 0d 65 16 0c 00 f7 d8 64 89 01 48 83\nc8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f\n05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48\n[ +0.018753] RSP: 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0\n[ +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb\n[ +0.007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748\n[ +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000000\n[ +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000\n[ +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 R15: 0000000000000000\n[ +0.007151] \n[ +0.002204] ---[ end trace 0000000000000000 ]---\n\nFix this by checking if the XDP program is being loaded or unloaded.\nThen, block only loading a new program while "__I40E_IN_REMOVE" is set.\nAlso, move testing "__I40E_IN_REMOVE" flag to the beginning of XDP_SETUP\ncallback to avoid unnecessary operations and checks.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_queue: drop bogus WARN_ON\n\nHappens when rules get flushed/deleted while packet is out, so remove\nthis WARN_ON.\n\nThis WARN exists in one form or another since v4.14, no need to backport\nthis to older releases, hence use a more recent fixes tag.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: Intel: hda: fix null deref on system suspend entry\n\nWhen system enters suspend with an active stream, SOF core\ncalls hw_params_upon_resume(). On Intel platforms with HDA DMA used\nto manage the link DMA, this leads to call chain of\n\n hda_dsp_set_hw_params_upon_resume()\n -> hda_dsp_dais_suspend()\n -> hda_dai_suspend()\n -> hda_ipc4_post_trigger()\n\nA bug is hit in hda_dai_suspend() as hda_link_dma_cleanup() is run first,\nwhich clears hext_stream->link_substream, and then hda_ipc4_post_trigger()\nis called with a NULL snd_pcm_substream pointer.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ks8851: Fix deadlock with the SPI chip variant\n\nWhen SMP is enabled and spinlocks are actually functional then there is\na deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi\nand ks8851_irq:\n\n watchdog: BUG: soft lockup - CPU#0 stuck for 27s!\n call trace:\n queued_spin_lock_slowpath+0x100/0x284\n do_raw_spin_lock+0x34/0x44\n ks8851_start_xmit_spi+0x30/0xb8\n ks8851_start_xmit+0x14/0x20\n netdev_start_xmit+0x40/0x6c\n dev_hard_start_xmit+0x6c/0xbc\n sch_direct_xmit+0xa4/0x22c\n __qdisc_run+0x138/0x3fc\n qdisc_run+0x24/0x3c\n net_tx_action+0xf8/0x130\n handle_softirqs+0x1ac/0x1f0\n __do_softirq+0x14/0x20\n ____do_softirq+0x10/0x1c\n call_on_irq_stack+0x3c/0x58\n do_softirq_own_stack+0x1c/0x28\n __irq_exit_rcu+0x54/0x9c\n irq_exit_rcu+0x10/0x1c\n el1_interrupt+0x38/0x50\n el1h_64_irq_handler+0x18/0x24\n el1h_64_irq+0x64/0x68\n __netif_schedule+0x6c/0x80\n netif_tx_wake_queue+0x38/0x48\n ks8851_irq+0xb8/0x2c8\n irq_thread_fn+0x2c/0x74\n irq_thread+0x10c/0x1b0\n kthread+0xc8/0xd8\n ret_from_fork+0x10/0x20\n\nThis issue has not been identified earlier because tests were done on\na device with SMP disabled and so spinlocks were actually NOPs.\n\nNow use spin_(un)lock_bh for TX queue related locking to avoid execution\nof softirq work synchronously that would lead to a deadlock.

In the Linux kernel, the following vulnerability has been resolved:\n\ncachestat: do not flush stats in recency check\n\nsyzbot detects that cachestat() is flushing stats, which can sleep, in its\nRCU read section (see [1]). This is done in the workingset_test_recent()\nstep (which checks if the folio's eviction is recent).\n\nMove the stat flushing step to before the RCU read section of cachestat,\nand skip stat flushing during the recency check.\n\n[1]: https://lore.kernel.org/cgroups/000000000000f71227061bdf97e0@google.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmalloc: check if a hash-index is in cpu_possible_mask\n\nThe problem is that there are systems where cpu_possible_mask has gaps\nbetween set CPUs, for example SPARC. In this scenario addr_to_vb_xa()\nhash function can return an index which accesses to not-possible and not\nsetup CPU area using per_cpu() macro. This results in an oops on SPARC.\n\nA per-cpu vmap_block_queue is also used as hash table, incorrectly\nassuming the cpu_possible_mask has no gaps. Fix it by adjusting an index\nto a next possible CPU.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/filemap: skip to create PMD-sized page cache if needed\n\nOn ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB. The\nPMD-sized page cache can't be supported by xarray as the following error\nmessages indicate.\n\n------------[ cut here ]------------\nWARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128\nModules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \\\nnft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \\\nnft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \\\nip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm \\\nfuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \\\nsha1_ce virtio_net net_failover virtio_console virtio_blk failover \\\ndimlib virtio_mmio\nCPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9\nHardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024\npstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\npc : xas_split_alloc+0xf8/0x128\nlr : split_huge_page_to_list_to_order+0x1c4/0x720\nsp : ffff800087a4f6c0\nx29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff\nx26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858\nx23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000\nx20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000\nx17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000\nx14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020\nx11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28\nx8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8\nx5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40\nx2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000\nCall trace:\n xas_split_alloc+0xf8/0x128\n split_huge_page_to_list_to_order+0x1c4/0x720\n truncate_inode_partial_folio+0xdc/0x160\n truncate_inode_pages_range+0x1b4/0x4a8\n truncate_pagecache_range+0x84/0xa0\n xfs_flush_unmap_range+0x70/0x90 [xfs]\n xfs_file_fallocate+0xfc/0x4d8 [xfs]\n vfs_fallocate+0x124/0x2e8\n ksys_fallocate+0x4c/0xa0\n __arm64_sys_fallocate+0x24/0x38\n invoke_syscall.constprop.0+0x7c/0xd8\n do_el0_svc+0xb4/0xd0\n el0_svc+0x44/0x1d8\n el0t_64_sync_handler+0x134/0x150\n el0t_64_sync+0x17c/0x180\n\nFix it by skipping to allocate PMD-sized page cache when its size is\nlarger than MAX_PAGECACHE_ORDER. For this specific case, we will fall to\nregular path where the readahead window is determined by BDI's sysfs file\n(read_ahead_kb).

In the Linux kernel, the following vulnerability has been resolved:\n\nnvmem: core: limit cell sysfs permissions to main attribute ones\n\nThe cell sysfs attribute should not provide more access to the nvmem\ndata than the main attribute itself.\nFor example if nvme_config::root_only was set, the cell attribute\nwould still provide read access to everybody.\n\nMask out permissions not available on the main attribute.

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: toshiba_acpi: Fix array out-of-bounds access\n\nIn order to use toshiba_dmi_quirks[] together with the standard DMI\nmatching functions, it must be terminated by a empty entry.\n\nSince this entry is missing, an array out-of-bounds access occurs\nevery time the quirk list is processed.\n\nFix this by adding the terminating empty entry.

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: davinci_mmc: Prevent transmitted data size from exceeding sgm's length\n\nNo check is done on the size of the data to be transmiited. This causes\na kernel panic when this size exceeds the sg_miter's length.\n\nLimit the number of transmitted bytes to sgm->length.

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: Fix memory leak in audio daemon attach operation\n\nAudio PD daemon send the name as part of the init IOCTL call. This\nname needs to be copied to kernel for which memory is allocated.\nThis memory is never freed which might result in memory leak. Free\nthe memory when it is not needed.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()\n\nThe "instance" variable needs to be signed for the error handling to work.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/mm: Fix VM_FAULT_HWPOISON handling in do_exception()\n\nThere is no support for HWPOISON, MEMORY_FAILURE, or ARCH_HAS_COPY_MC on\ns390. Therefore we do not expect to see VM_FAULT_HWPOISON in\ndo_exception().\n\nHowever, since commit af19487f00f3 ("mm: make PTE_MARKER_SWAPIN_ERROR more\ngeneral"), it is possible to see VM_FAULT_HWPOISON in combination with\nPTE_MARKER_POISONED, even on architectures that do not support HWPOISON\notherwise. In this case, we will end up on the BUG() in do_exception().\n\nFix this by treating VM_FAULT_HWPOISON the same as VM_FAULT_SIGBUS, similar\nto x86 when MEMORY_FAILURE is not configured. Also print unexpected fault\nflags, for easier debugging.\n\nNote that VM_FAULT_HWPOISON_LARGE is not expected, because s390 cannot\nsupport swap entries on other levels than PTE level.

In the Linux kernel, the following vulnerability has been resolved:\n\nfilelock: Fix fcntl/close race recovery compat path\n\nWhen I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when\nfcntl/close race is detected"), I missed that there are two copies of the\ncode I was patching: The normal version, and the version for 64-bit offsets\non 32-bit kernels.\nThanks to Greg KH for stumbling over this while doing the stable\nbackport...\n\nApply exactly the same fix to the compat path for 32-bit kernels.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Add a check for attr_names and oatbl\n\nAdded out-of-bound checking for *ane (ATTR_NAME_ENTRY).

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix overrunning reservations in ringbuf\n\nThe BPF ring buffer internally is implemented as a power-of-2 sized circular\nbuffer, with two logical and ever-increasing counters: consumer_pos is the\nconsumer counter to show which logical position the consumer consumed the\ndata, and producer_pos which is the producer counter denoting the amount of\ndata reserved by all producers.\n\nEach time a record is reserved, the producer that "owns" the record will\nsuccessfully advance producer counter. In user space each time a record is\nread, the consumer of the data advanced the consumer counter once it finished\nprocessing. Both counters are stored in separate pages so that from user\nspace, the producer counter is read-only and the consumer counter is read-write.\n\nOne aspect that simplifies and thus speeds up the implementation of both\nproducers and consumers is how the data area is mapped twice contiguously\nback-to-back in the virtual memory, allowing to not take any special measures\nfor samples that have to wrap around at the end of the circular buffer data\narea, because the next page after the last data page would be first data page\nagain, and thus the sample will still appear completely contiguous in virtual\nmemory.\n\nEach record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for\nbook-keeping the length and offset, and is inaccessible to the BPF program.\nHelpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`\nfor the BPF program to use. Bing-Jhong and Muhammad reported that it is however\npossible to make a second allocated memory chunk overlapping with the first\nchunk and as a result, the BPF program is now able to edit first chunk's\nheader.\n\nFor example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size\nof 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to\nbpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in\n[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets\nallocate a chunk B with size 0x3000. This will succeed because consumer_pos\nwas edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`\ncheck. Chunk B will be in range [0x3008,0x6010], and the BPF program is able\nto edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned\nearlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data\npages. This means that chunk B at [0x4000,0x4008] is chunk A's header.\nbpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then\nlocate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk\nB modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong\npage and could cause a crash.\n\nFix it by calculating the oldest pending_pos and check whether the range\nfrom the oldest outstanding record to the newest would span beyond the ring\nbuffer size. If that is the case, then reject the request. We've tested with\nthe ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)\nbefore/after the fix and while it seems a bit slower on some benchmarks, it\nis still not significantly enough to matter.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Avoid splat in pskb_pull_reason\n\nsyzkaller builds (CONFIG_DEBUG_NET=y) frequently trigger a debug\nhint in pskb_may_pull.\n\nWe'd like to retain this debug check because it might hint at integer\noverflows and other issues (kernel code should pull headers, not huge\nvalue).\n\nIn bpf case, this splat isn't interesting at all: such (nonsensical)\nbpf programs are typically generated by a fuzzer anyway.\n\nDo what Eric suggested and suppress such warning.\n\nFor CONFIG_DEBUG_NET=n we don't need the extra check because\npskb_may_pull will do the right thing: return an error without the\nWARN() backtrace.

In the Linux kernel, the following vulnerability has been resolved:\n\nptp: fix integer overflow in max_vclocks_store\n\nOn 32bit systems, the "4 * max" multiply can overflow. Use kcalloc()\nto do the allocation to prevent this.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Fix suspicious rcu_dereference_protected()\n\nWhen destroying all sets, we are either in pernet exit phase or\nare executing a "destroy all sets command" from userspace. The latter\nwas taken into account in ip_set_dereference() (nfnetlink mutex is held),\nbut the former was not. The patch adds the required check to\nrcu_dereference_protected() in ip_set_dereference().

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix responder length checking for UD request packets\n\nAccording to the IBA specification:\nIf a UD request packet is detected with an invalid length, the request\nshall be an invalid request and it shall be silently dropped by\nthe responder. The responder then waits for a new request packet.\n\ncommit 689c5421bfe0 ("RDMA/rxe: Fix incorrect responder length checking")\ndefers responder length check for UD QPs in function `copy_data`.\nBut it introduces a regression issue for UD QPs.\n\nWhen the packet size is too large to fit in the receive buffer.\n`copy_data` will return error code -EINVAL. Then `send_data_in`\nwill return RESPST_ERR_MALFORMED_WQE. UD QP will transfer into\nERROR state.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma-glue: Fix of_k3_udma_glue_parse_chn_by_id()\n\nThe of_k3_udma_glue_parse_chn_by_id() helper function erroneously\ninvokes "of_node_put()" on the "udmax_np" device-node passed to it,\nwithout having incremented its reference count at any point. Fix it.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: xilinx: xdma: Fix data synchronisation in xdma_channel_isr()\n\nRequests the vchan lock before using xdma->stop_request.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tcp_ao: Don't leak ao_info on error-path\n\nIt seems I introduced it together with TCP_AO_CMDF_AO_REQUIRED, on\nversion 5 [1] of TCP-AO patches. Quite frustrative that having all these\nselftests that I've written, running kmemtest & kcov was always in todo.\n\n[1]: https://lore.kernel.org/netdev/20230215183335.800122-5-dima@arista.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()\n\nThe cs35l41_hda_unbind() function clears the hda_component entry\nmatching it's index and then dereferences the codec pointer held in the\nfirst element of the hda_component array, this is an issue when the\ndevice index was 0.\n\nInstead use the codec pointer stashed in the cs35l41_hda structure as it\nwill still be valid.

In the Linux kernel, the following vulnerability has been resolved:\n\nmips: bmips: BCM6358: make sure CBR is correctly set\n\nIt was discovered that some device have CBR address set to 0 causing\nkernel panic when arch_sync_dma_for_cpu_all is called.\n\nThis was notice in situation where the system is booted from TP1 and\nBMIPS_GET_CBR() returns 0 instead of a valid address and\n!!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.\n\nThe current check whether RAC flush should be disabled or not are not\nenough hence lets check if CBR is a valid address or not.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: allocate dummy checksums for zoned NODATASUM writes\n\nShin'ichiro reported that when he's running fstests' test-case\nbtrfs/167 on emulated zoned devices, he's seeing the following NULL\npointer dereference in 'btrfs_zone_finish_endio()':\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]\n CPU: 4 PID: 2332440 Comm: kworker/u80:15 Tainted: G W 6.10.0-rc2-kts+ #4\n Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020\n Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]\n RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]\n\n RSP: 0018:ffff88867f107a90 EFLAGS: 00010206\n RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff893e5534\n RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088\n RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed1081696028\n R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000\n R13: 0000000000020000 R14: 0000000000000000 R15: ffff888530ad5210\n FS: 0000000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f87223fff38 CR3: 00000007a7c6a002 CR4: 00000000007706f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \n ? __die_body.cold+0x19/0x27\n ? die_addr+0x46/0x70\n ? exc_general_protection+0x14f/0x250\n ? asm_exc_general_protection+0x26/0x30\n ? do_raw_read_unlock+0x44/0x70\n ? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]\n btrfs_finish_one_ordered+0x5d9/0x19a0 [btrfs]\n ? __pfx_lock_release+0x10/0x10\n ? do_raw_write_lock+0x90/0x260\n ? __pfx_do_raw_write_lock+0x10/0x10\n ? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]\n ? _raw_write_unlock+0x23/0x40\n ? btrfs_finish_ordered_zoned+0x5a9/0x850 [btrfs]\n ? lock_acquire+0x435/0x500\n btrfs_work_helper+0x1b1/0xa70 [btrfs]\n ? __schedule+0x10a8/0x60b0\n ? __pfx___might_resched+0x10/0x10\n process_one_work+0x862/0x1410\n ? __pfx_lock_acquire+0x10/0x10\n ? __pfx_process_one_work+0x10/0x10\n ? assign_work+0x16c/0x240\n worker_thread+0x5e6/0x1010\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x2c3/0x3a0\n ? trace_irq_enable.constprop.0+0xce/0x110\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x70\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \n\nEnabling CONFIG_BTRFS_ASSERT revealed the following assertion to\ntrigger:\n\n assertion failed: !list_empty(&ordered->list), in fs/btrfs/zoned.c:1815\n\nThis indicates, that we're missing the checksums list on the\nordered_extent. As btrfs/167 is doing a NOCOW write this is to be\nexpected.\n\nFurther analysis with drgn confirmed the assumption:\n\n >>> inode = prog.crashed_thread().stack_trace()[11]['ordered'].inode\n >>> btrfs_inode = drgn.container_of(inode, "struct btrfs_inode", \\\n "vfs_inode")\n >>> print(btrfs_inode.flags)\n (u32)1\n\nAs zoned emulation mode simulates conventional zones on regular devices,\nwe cannot use zone-append for writing. But we're only attaching dummy\nchecksums if we're doing a zone-append write.\n\nSo for NOCOW zoned data writes on conventional zones, also attach a\ndummy checksum.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()\n\nWe can trigger a slab-out-of-bounds with the following commands:\n\n mkfs.ext4 -F /dev/$disk 10G\n mount /dev/$disk /tmp/test\n echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc\n echo test > /tmp/test/file && sync\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4]\nRead of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11\nCPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521\nCall Trace:\n dump_stack_lvl+0x2c/0x50\n kasan_report+0xb6/0xf0\n ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4]\n ext4_mb_regular_allocator+0x19e9/0x2370 [ext4]\n ext4_mb_new_blocks+0x88a/0x1370 [ext4]\n ext4_ext_map_blocks+0x14f7/0x2390 [ext4]\n ext4_map_blocks+0x569/0xea0 [ext4]\n ext4_do_writepages+0x10f6/0x1bc0 [ext4]\n[...]\n==================================================================\n\nThe flow of issue triggering is as follows:\n\n// Set s_mb_group_prealloc to 2147483647 via sysfs\next4_mb_new_blocks\n ext4_mb_normalize_request\n ext4_mb_normalize_group_request\n ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc\n ext4_mb_regular_allocator\n ext4_mb_choose_next_group\n ext4_mb_choose_next_group_best_avail\n mb_avg_fragment_size_order\n order = fls(len) - 2 = 29\n ext4_mb_find_good_group_avg_frag_lists\n frag_list = &sbi->s_mb_avg_fragment_size[order]\n if (list_empty(frag_list)) // Trigger SOOB!\n\nAt 4k block size, the length of the s_mb_avg_fragment_size list is 14,\nbut an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds\nto be triggered by an attempt to access an element at index 29.\n\nAdd a new attr_id attr_clusters_in_group with values in the range\n[0, sbi->s_clusters_per_group] and declare mb_group_prealloc as\nthat type to fix the issue. In addition avoid returning an order\nfrom mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb)\nand reduce some useless loops.

In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()\n\nbdev->bd_super has been removed and commit 8887b94d9322 change the usage\nfrom bdev->bd_super to b_assoc_map->host->i_sb. This introduces the\nfollowing NULL pointer dereference in ocfs2_journal_dirty() since\nb_assoc_map is still not initialized. This can be easily reproduced by\nrunning xfstests generic/186, which simulate no more credits.\n\n[ 134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000\n...\n[ 134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2]\n...\n[ 134.365071] Call Trace:\n[ 134.365312] \n[ 134.365524] ? __die_body+0x1e/0x60\n[ 134.365868] ? page_fault_oops+0x13d/0x4f0\n[ 134.366265] ? __pfx_bit_wait_io+0x10/0x10\n[ 134.366659] ? schedule+0x27/0xb0\n[ 134.366981] ? exc_page_fault+0x6a/0x140\n[ 134.367356] ? asm_exc_page_fault+0x26/0x30\n[ 134.367762] ? ocfs2_journal_dirty+0x14f/0x160 [ocfs2]\n[ 134.368305] ? ocfs2_journal_dirty+0x13d/0x160 [ocfs2]\n[ 134.368837] ocfs2_create_new_meta_bhs.isra.51+0x139/0x2e0 [ocfs2]\n[ 134.369454] ocfs2_grow_tree+0x688/0x8a0 [ocfs2]\n[ 134.369927] ocfs2_split_and_insert.isra.67+0x35c/0x4a0 [ocfs2]\n[ 134.370521] ocfs2_split_extent+0x314/0x4d0 [ocfs2]\n[ 134.371019] ocfs2_change_extent_flag+0x174/0x410 [ocfs2]\n[ 134.371566] ocfs2_add_refcount_flag+0x3fa/0x630 [ocfs2]\n[ 134.372117] ocfs2_reflink_remap_extent+0x21b/0x4c0 [ocfs2]\n[ 134.372994] ? inode_update_timestamps+0x4a/0x120\n[ 134.373692] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2]\n[ 134.374545] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2]\n[ 134.375393] ocfs2_reflink_remap_blocks+0xe4/0x4e0 [ocfs2]\n[ 134.376197] ocfs2_remap_file_range+0x1de/0x390 [ocfs2]\n[ 134.376971] ? security_file_permission+0x29/0x50\n[ 134.377644] vfs_clone_file_range+0xfe/0x320\n[ 134.378268] ioctl_file_clone+0x45/0xa0\n[ 134.378853] do_vfs_ioctl+0x457/0x990\n[ 134.379422] __x64_sys_ioctl+0x6e/0xd0\n[ 134.379987] do_syscall_64+0x5d/0x170\n[ 134.380550] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 134.381231] RIP: 0033:0x7fa4926397cb\n[ 134.381786] Code: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48\n[ 134.383930] RSP: 002b:00007ffc2b39f7b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n[ 134.384854] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb\n[ 134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003\n[ 134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000\n[ 134.387476] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n[ 134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000\n[ 134.389207] \n\nFix it by only aborting transaction and journal in ocfs2_journal_dirty()\nnow, and leave ocfs2_abort() later when detecting an aborted handle,\ne.g. start next transaction. Also log the handle details in this case.

In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix NULL pointer dereference in ocfs2_abort_trigger()\n\nbdev->bd_super has been removed and commit 8887b94d9322 change the usage\nfrom bdev->bd_super to b_assoc_map->host->i_sb. Since ocfs2 hasn't set\nbh->b_assoc_map, it will trigger NULL pointer dereference when calling\ninto ocfs2_abort_trigger().\n\nActually this was pointed out in history, see commit 74e364ad1b13. But\nI've made a mistake when reviewing commit 8887b94d9322 and then\nre-introduce this regression.\n\nSince we cannot revive bdev in buffer head, so fix this issue by\ninitializing all types of ocfs2 triggers when fill super, and then get the\nspecific ocfs2 trigger from ocfs2_caching_info when access journal.\n\n[joseph.qi@linux.alibaba.com: v2]\n Link: https://lkml.kernel.org/r/20240602112045.1112708-1-joseph.qi@linux.alibaba.com

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: huge_memory: fix misused mapping_large_folio_support() for anon folios\n\nWhen I did a large folios split test, a WARNING "[ 5059.122759][ T166]\nCannot split file folio to non-0 order" was triggered. But the test cases\nare only for anonmous folios. while mapping_large_folio_support() is only\nreasonable for page cache folios.\n\nIn split_huge_page_to_list_to_order(), the folio passed to\nmapping_large_folio_support() maybe anonmous folio. The folio_test_anon()\ncheck is missing. So the split of the anonmous THP is failed. This is\nalso the same for shmem_mapping(). We'd better add a check for both. But\nthe shmem_mapping() in __split_huge_page() is not involved, as for\nanonmous folios, the end parameter is set to -1, so (head[i].index >= end)\nis always false. shmem_mapping() is not called.\n\nAlso add a VM_WARN_ON_ONCE() in mapping_large_folio_support() for anon\nmapping, So we can detect the wrong use more easily.\n\nTHP folios maybe exist in the pagecache even the file system doesn't\nsupport large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE is\nenabled, khugepaged will try to collapse read-only file-backed pages to\nTHP. But the mapping does not actually support multi order large folios\nproperly.\n\nUsing /sys/kernel/debug/split_huge_pages to verify this, with this patch,\nlarge anon THP is successfully split and the warning is ceased.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_table_check: fix crash on ZONE_DEVICE\n\nNot all pages may apply to pgtable check. One example is ZONE_DEVICE\npages: they map PFNs directly, and they don't allocate page_ext at all\neven if there's struct page around. One may reference\ndevm_memremap_pages().\n\nWhen both ZONE_DEVICE and page-table-check enabled, then try to map some\ndax memories, one can trigger kernel bug constantly now when the kernel\nwas trying to inject some pfn maps on the dax device:\n\n kernel BUG at mm/page_table_check.c:55!\n\nWhile it's pretty legal to use set_pxx_at() for ZONE_DEVICE pages for page\nfault resolutions, skip all the checks if page_ext doesn't even exist in\npgtable checker, which applies to ZONE_DEVICE but maybe more.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/poll: add hash if ready poll request can't complete inline\n\nIf we don't, then we may lose access to it completely, leading to a\nrequest leak. This will eventually stall the ring exit process as\nwell.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: another fix for the headless Adreno GPU\n\nFix another oops reproducible when rebooting the board with the Adreno\nGPU working in the headless mode (e.g. iMX platforms).\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000 when read\n[00000000] *pgd=74936831, *pte=00000000, *ppte=00000000\nInternal error: Oops: 17 [#1] ARM\nCPU: 0 PID: 51 Comm: reboot Not tainted 6.2.0-rc1-dirty #11\nHardware name: Freescale i.MX53 (Device Tree Support)\nPC is at msm_atomic_commit_tail+0x50/0x970\nLR is at commit_tail+0x9c/0x188\npc : [] lr : [] psr: 600e0013\nsp : e0851d30 ip : ee4eb7eb fp : 00090acc\nr10: 00000058 r9 : c2193014 r8 : c4310000\nr7 : c4759380 r6 : 07bef61d r5 : 00000000 r4 : 00000000\nr3 : c44cc440 r2 : 00000000 r1 : 00000000 r0 : 00000000\nFlags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none\nControl: 10c5387d Table: 74910019 DAC: 00000051\nRegister r0 information: NULL pointer\nRegister r1 information: NULL pointer\nRegister r2 information: NULL pointer\nRegister r3 information: slab kmalloc-1k start c44cc400 pointer offset 64 size 1024\nRegister r4 information: NULL pointer\nRegister r5 information: NULL pointer\nRegister r6 information: non-paged memory\nRegister r7 information: slab kmalloc-128 start c4759380 pointer offset 0 size 128\nRegister r8 information: slab kmalloc-2k start c4310000 pointer offset 0 size 2048\nRegister r9 information: non-slab/vmalloc memory\nRegister r10 information: non-paged memory\nRegister r11 information: non-paged memory\nRegister r12 information: non-paged memory\nProcess reboot (pid: 51, stack limit = 0xc80046d9)\nStack: (0xe0851d30 to 0xe0852000)\n1d20: c4759380 fbd77200 000005ff 002b9c70\n1d40: c4759380 c4759380 00000000 07bef61d 00000600 c0d6fe7c c2193014 00000058\n1d60: 00090acc c067a214 00000000 c4759380 c4310000 00000000 c44cc854 c067a89c\n1d80: 00000000 00000000 00000000 c4310468 00000000 c4759380 c4310000 c4310468\n1da0: c4310470 c0643258 c4759380 00000000 00000000 c0c4ee24 00000000 c44cc810\n1dc0: 00000000 c0c4ee24 00000000 c44cc810 00000000 0347d2a8 e0851e00 e0851e00\n1de0: c4759380 c067ad20 c4310000 00000000 c44cc810 c27f8718 c44cc854 c067adb8\n1e00: c4933000 00000002 00000001 00000000 00000000 c2130850 00000000 c2130854\n1e20: c25fc488 00000000 c0ff162c 00000000 00000001 00000002 00000000 00000000\n1e40: c43102c0 c43102c0 00000000 0347d2a8 c44cc810 c44cc814 c2133da8 c06d1a60\n1e60: 00000000 00000000 00079028 c2012f24 fee1dead c4933000 00000058 c01431e4\n1e80: 01234567 c0143a20 00000000 00000000 00000000 00000000 00000000 00000000\n1ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n1ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n1ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n1f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n1f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n1f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n1f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n1f80: 00000000 00000000 00000000 0347d2a8 00000002 00000004 00000078 00000058\n1fa0: c010028c c0100060 00000002 00000004 fee1dead 28121969 01234567 00079028\n1fc0: 00000002 00000004 00000078 00000058 0002fdc5 00000000 00000000 00090acc\n1fe0: 00000058 becc9c64 b6e97e05 b6e0e5f6 600e0030 fee1dead 00000000 00000000\n msm_atomic_commit_tail from commit_tail+0x9c/0x188\n commit_tail from drm_atomic_helper_commit+0x160/0x188\n drm_atomic_helper_commit from drm_atomic_commit+0xac/0xe0\n drm_atomic_commit from drm_atomic_helper_disable_all+0x1b0/0x1c0\n drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x88/0x140\n drm_atomic_helper_shutdown from device_shutdown+0x16c/0x240\n device_shutdown from kernel_restart+0x38/0x90\n kernel_restart from __do_sys_reboot+0x\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix handling of cached open files in nfsd4_open codepath\n\nCommit fb70bf124b05 ("NFSD: Instantiate a struct file when creating a\nregular NFSv4 file") added the ability to cache an open fd over a\ncompound. There are a couple of problems with the way this currently\nworks:\n\nIt's racy, as a newly-created nfsd_file can end up with its PENDING bit\ncleared while the nf is hashed, and the nf_file pointer is still zeroed\nout. Other tasks can find it in this state and they expect to see a\nvalid nf_file, and can oops if nf_file is NULL.\n\nAlso, there is no guarantee that we'll end up creating a new nfsd_file\nif one is already in the hash. If an extant entry is in the hash with a\nvalid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with\nthe value of op_file and the old nf_file will leak.\n\nFix both issues by making a new nfsd_file_acquirei_opened variant that\ntakes an optional file pointer. If one is present when this is called,\nwe'll take a new reference to it instead of trying to open the file. If\nthe nfsd_file already has a valid nf_file, we'll just ignore the\noptional file and pass the nfsd_file back as-is.\n\nAlso rework the tracepoints a bit to allow for an "opened" variant and\ndon't try to avoid counting acquisitions in the case where we already\nhave a cached open file.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix potential NULL dereference\n\nFix potential NULL dereference, in the case when "man", the resource manager\nmight be NULL, when/if we print debug information.

In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Fix resource leakage in VF driver unbind\n\nresources allocated like mcam entries to support the Ntuple feature\nand hash tables for the tc feature are not getting freed in driver\nunbind. This patch fixes the issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nnommu: fix memory leak in do_mmap() error path\n\nThe preallocation of the maple tree nodes may leak if the error path to\n"error_just_free" is taken. Fix this by moving the freeing of the maple\ntree nodes to a shared location for all error paths.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Check endpoint is valid before dereferencing it\n\nWhen the host controller is not responding, all URBs queued to all\nendpoints need to be killed. This can cause a kernel panic if we\ndereference an invalid endpoint.\n\nFix this by using xhci_get_virt_ep() helper to find the endpoint and\nchecking if the endpoint is valid before dereferencing it.\n\n[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead\n[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8\n\n[233311.853964] pc : xhci_hc_died+0x10c/0x270\n[233311.853971] lr : xhci_hc_died+0x1ac/0x270\n\n[233311.854077] Call trace:\n[233311.854085] xhci_hc_died+0x10c/0x270\n[233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4\n[233311.854105] call_timer_fn+0x50/0x2d4\n[233311.854112] expire_timers+0xac/0x2e4\n[233311.854118] run_timer_softirq+0x300/0xabc\n[233311.854127] __do_softirq+0x148/0x528\n[233311.854135] irq_exit+0x194/0x1a8\n[233311.854143] __handle_domain_irq+0x164/0x1d0\n[233311.854149] gic_handle_irq.22273+0x10c/0x188\n[233311.854156] el1_irq+0xfc/0x1a8\n[233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm]\n[233311.854185] cpuidle_enter_state+0x1f0/0x764\n[233311.854194] do_idle+0x594/0x6ac\n[233311.854201] cpu_startup_entry+0x7c/0x80\n[233311.854209] secondary_start_kernel+0x170/0x198

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: qgroup: do not warn on record without old_roots populated\n\n[BUG]\nThere are some reports from the mailing list that since v6.1 kernel, the\nWARN_ON() inside btrfs_qgroup_account_extent() gets triggered during\nrescan:\n\n WARNING: CPU: 3 PID: 6424 at fs/btrfs/qgroup.c:2756 btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]\n CPU: 3 PID: 6424 Comm: snapperd Tainted: P OE 6.1.2-1-default #1 openSUSE Tumbleweed 05c7a1b1b61d5627475528f71f50444637b5aad7\n RIP: 0010:btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]\n Call Trace:\n \n btrfs_commit_transaction+0x30c/0xb40 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]\n ? start_transaction+0xc3/0x5b0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]\n btrfs_qgroup_rescan+0x42/0xc0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]\n btrfs_ioctl+0x1ab9/0x25c0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]\n ? __rseq_handle_notify_resume+0xa9/0x4a0\n ? mntput_no_expire+0x4a/0x240\n ? __seccomp_filter+0x319/0x4d0\n __x64_sys_ioctl+0x90/0xd0\n do_syscall_64+0x5b/0x80\n ? syscall_exit_to_user_mode+0x17/0x40\n ? do_syscall_64+0x67/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x7fd9b790d9bf\n \n\n[CAUSE]\nSince commit e15e9f43c7ca ("btrfs: introduce\nBTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting"), if\nour qgroup is already in inconsistent state, we will no longer do the\ntime-consuming backref walk.\n\nThis can leave some qgroup records without a valid old_roots ulist.\nNormally this is fine, as btrfs_qgroup_account_extents() would also skip\nthose records if we have NO_ACCOUNTING flag set.\n\nBut there is a small window, if we have NO_ACCOUNTING flag set, and\ninserted some qgroup_record without a old_roots ulist, but then the user\ntriggered a qgroup rescan.\n\nDuring btrfs_qgroup_rescan(), we firstly clear NO_ACCOUNTING flag, then\ncommit current transaction.\n\nAnd since we have a qgroup_record with old_roots = NULL, we trigger the\nWARN_ON() during btrfs_qgroup_account_extents().\n\n[FIX]\nUnfortunately due to the introduction of NO_ACCOUNTING flag, the\nassumption that every qgroup_record would have its old_roots populated\nis no longer correct.\n\nFix the false alerts and drop the WARN_ON().

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/poll: don't reissue in case of poll race on multishot request\n\nA previous commit fixed a poll race that can occur, but it's only\napplicable for multishot requests. For a multishot request, we can safely\nignore a spurious wakeup, as we never leave the waitqueue to begin with.\n\nA blunt reissue of a multishot armed request can cause us to leak a\nbuffer, if they are ring provided. While this seems like a bug in itself,\nit's not really defined behavior to reissue a multishot request directly.\nIt's less efficient to do so as well, and not required to rearm anything\nlike it is for singleshot poll requests.

In the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix yet more sched_fork() races\n\nWhere commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an\ninvalid sched_task_group") fixed a fork race vs cgroup, it opened up a\nrace vs syscalls by not placing the task on the runqueue before it\ngets exposed through the pidhash.\n\nCommit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is\ntrying to fix a single instance of this, instead fix the whole class\nof issues, effectively reverting this commit.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix concurrent reset and removal of VFs\n\nCommit c503e63200c6 ("ice: Stop processing VF messages during teardown")\nintroduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is\nintended to prevent some issues with concurrently handling messages from\nVFs while tearing down the VFs.\n\nThis change was motivated by crashes caused while tearing down and\nbringing up VFs in rapid succession.\n\nIt turns out that the fix actually introduces issues with the VF driver\ncaused because the PF no longer responds to any messages sent by the VF\nduring its .remove routine. This results in the VF potentially removing\nits DMA memory before the PF has shut down the device queues.\n\nAdditionally, the fix doesn't actually resolve concurrency issues within\nthe ice driver. It is possible for a VF to initiate a reset just prior\nto the ice driver removing VFs. This can result in the remove task\nconcurrently operating while the VF is being reset. This results in\nsimilar memory corruption and panics purportedly fixed by that commit.\n\nFix this concurrency at its root by protecting both the reset and\nremoval flows using the existing VF cfg_lock. This ensures that we\ncannot remove the VF while any outstanding critical tasks such as a\nvirtchnl message or a reset are occurring.\n\nThis locking change also fixes the root cause originally fixed by commit\nc503e63200c6 ("ice: Stop processing VF messages during teardown"), so we\ncan simply revert it.\n\nNote that I kept these two changes together because simply reverting the\noriginal commit alone would leave the driver vulnerable to worse race\nconditions.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fte\n\nWhen adding a rule with 32 destinations, we hit the following out-of-band\naccess issue:\n\n BUG: KASAN: slab-out-of-bounds in mlx5_cmd_dr_create_fte+0x18ee/0x1e70\n\nThis patch fixes the issue by both increasing the allocated buffers to\naccommodate for the needed actions and by checking the number of actions\nto prevent this issue when a rule with too many actions is provided.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ib_srp: Fix a deadlock\n\nRemove the flush_workqueue(system_long_wq) call since flushing\nsystem_long_wq is deadlock-prone and since that call is redundant with a\npreceding cancel_work_sync()

In the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: men_z188_adc: Fix a resource leak in an error handling path\n\nIf iio_device_register() fails, a previous ioremap() is left unbalanced.\n\nUpdate the error handling path and add the missing iounmap() call, as\nalready done in the remove function.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: tsc2046: fix memory corruption by preventing array overflow\n\nOn one side we have indio_dev->num_channels includes all physical channels +\ntimestamp channel. On other side we have an array allocated only for\nphysical channels. So, fix memory corruption by ARRAY_SIZE() instead of\nnum_channels variable.\n\nNote the first case is a cleanup rather than a fix as the software\ntimestamp channel bit in active_scanmask is never set by the IIO core.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Do not change route.addr.src_addr outside state checks\n\nIf the state is not idle then resolve_prepare_src() should immediately\nfail and no change to global state should happen. However, it\nunconditionally overwrites the src_addr trying to build a temporary any\naddress.\n\nFor instance if the state is already RDMA_CM_LISTEN then this will corrupt\nthe src_addr and would cause the test in cma_cancel_operation():\n\n if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev)\n\nWhich would manifest as this trace from syzkaller:\n\n BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26\n Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204\n\n CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n Call Trace:\n __dump_stack lib/dump_stack.c:79 [inline]\n dump_stack+0x141/0x1d7 lib/dump_stack.c:120\n print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232\n __kasan_report mm/kasan/report.c:399 [inline]\n kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416\n __list_add_valid+0x93/0xa0 lib/list_debug.c:26\n __list_add include/linux/list.h:67 [inline]\n list_add_tail include/linux/list.h:100 [inline]\n cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline]\n rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751\n ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102\n ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732\n vfs_write+0x28e/0xa30 fs/read_write.c:603\n ksys_write+0x1ee/0x250 fs/read_write.c:658\n do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThis is indicating that an rdma_id_private was destroyed without doing\ncma_cancel_listens().\n\nInstead of trying to re-use the src_addr memory to indirectly create an\nany address derived from the dst build one explicitly on the stack and\nbind to that as any other normal flow would do. rdma_bind_addr() will copy\nit over the src_addr once it knows the state is valid.\n\nThis is similar to commit bc0bdc5afaa7 ("RDMA/cma: Do not change\nroute.addr.src_addr.ss_family")

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_queue: fix possible use-after-free\n\nEric Dumazet says:\n The sock_hold() side seems suspect, because there is no guarantee\n that sk_refcnt is not already 0.\n\nOn failure, we cannot queue the packet and need to indicate an\nerror. The packet will be dropped by the caller.\n\nv2: split skb prefetch hunk into separate change

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: ensure we call ipv6_mc_down() at most once\n\nThere are two reasons for addrconf_notify() to be called with NETDEV_DOWN:\neither the network device is actually going down, or IPv6 was disabled\non the interface.\n\nIf either of them stays down while the other is toggled, we repeatedly\ncall the code for NETDEV_DOWN, including ipv6_mc_down(), while never\ncalling the corresponding ipv6_mc_up() in between. This will cause a\nnew entry in idev->mc_tomb to be allocated for each multicast group\nthe interface is subscribed to, which in turn leaks one struct ifmcaddr6\nper nontrivial multicast group the interface is subscribed to.\n\nThe following reproducer will leak at least $n objects:\n\nip addr add ff2e::4242/32 dev eth0 autojoin\nsysctl -w net.ipv6.conf.eth0.disable_ipv6=1\nfor i in $(seq 1 $n); do\n ip link set up eth0; ip link set down eth0\ndone\n\nJoining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the\nsysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2)\ncan also be used to create a nontrivial idev->mc_list, which will the\nleak objects with the right up-down-sequence.\n\nBased on both sources for NETDEV_DOWN events the interface IPv6 state\nshould be considered:\n\n - not ready if the network interface is not ready OR IPv6 is disabled\n for it\n - ready if the network interface is ready AND IPv6 is enabled for it\n\nThe functions ipv6_mc_up() and ipv6_down() should only be run when this\nstate changes.\n\nImplement this by remembering when the IPv6 state is ready, and only\nrun ipv6_mc_down() if it actually changed from ready to not ready.\n\nThe other direction (not ready -> ready) already works correctly, as:\n\n - the interface notification triggered codepath for NETDEV_UP /\n NETDEV_CHANGE returns early if ipv6 is disabled, and\n - the disable_ipv6=0 triggered codepath skips fully initializing the\n interface as long as addrconf_link_ready(dev) returns false\n - calling ipv6_mc_up() repeatedly does not leak anything

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()\n\nDuring driver initialization, the pointer of card info, i.e. the\nvariable 'ci' is required. However, the definition of\n'com20020pci_id_table' reveals that this field is empty for some\ndevices, which will cause null pointer dereference when initializing\nthese devices.\n\nThe following log reveals it:\n\n[ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n[ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci]\n[ 3.975181] Call Trace:\n[ 3.976208] local_pci_probe+0x13f/0x210\n[ 3.977248] pci_device_probe+0x34c/0x6d0\n[ 3.977255] ? pci_uevent+0x470/0x470\n[ 3.978265] really_probe+0x24c/0x8d0\n[ 3.978273] __driver_probe_device+0x1b3/0x280\n[ 3.979288] driver_probe_device+0x50/0x370\n\nFix this by checking whether the 'ci' is a null pointer first.

In the Linux kernel, the following vulnerability has been resolved:\n\nauxdisplay: lcd2s: Fix memory leak in ->remove()\n\nOnce allocated the struct lcd2s_data is never freed.\nFix the memory leak by switching to devm_kzalloc().

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: Correctly set DATA_FIN timeout when number of retransmits is large\n\nSyzkaller with UBSAN uncovered a scenario where a large number of\nDATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FIN\ntimeout calculation:\n\n================================================================================\nUBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29\nshift exponent 32 is too large for 32-bit type 'unsigned int'\nCPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nWorkqueue: events mptcp_worker\nCall Trace:\n \n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n ubsan_epilogue+0xb/0x5a lib/ubsan.c:151\n __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330\n mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline]\n __mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445\n mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528\n process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307\n worker_thread+0x95/0xe10 kernel/workqueue.c:2454\n kthread+0x2f4/0x3b0 kernel/kthread.c:377\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295\n \n================================================================================\n\nThis change limits the maximum timeout by limiting the size of the\nshift, which keeps all intermediate values in-bounds.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix relocation crash due to premature return from btrfs_commit_transaction()\n\nWe are seeing crashes similar to the following trace:\n\n[38.969182] WARNING: CPU: 20 PID: 2105 at fs/btrfs/relocation.c:4070 btrfs_relocate_block_group+0x2dc/0x340 [btrfs]\n[38.973556] CPU: 20 PID: 2105 Comm: btrfs Not tainted 5.17.0-rc4 #54\n[38.974580] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[38.976539] RIP: 0010:btrfs_relocate_block_group+0x2dc/0x340 [btrfs]\n[38.980336] RSP: 0000:ffffb0dd42e03c20 EFLAGS: 00010206\n[38.981218] RAX: ffff96cfc4ede800 RBX: ffff96cfc3ce0000 RCX: 000000000002ca14\n[38.982560] RDX: 0000000000000000 RSI: 4cfd109a0bcb5d7f RDI: ffff96cfc3ce0360\n[38.983619] RBP: ffff96cfc309c000 R08: 0000000000000000 R09: 0000000000000000\n[38.984678] R10: ffff96cec0000001 R11: ffffe84c80000000 R12: ffff96cfc4ede800\n[38.985735] R13: 0000000000000000 R14: 0000000000000000 R15: ffff96cfc3ce0360\n[38.987146] FS: 00007f11c15218c0(0000) GS:ffff96d6dfb00000(0000) knlGS:0000000000000000\n[38.988662] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[38.989398] CR2: 00007ffc922c8e60 CR3: 00000001147a6001 CR4: 0000000000370ee0\n[38.990279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[38.991219] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[38.992528] Call Trace:\n[38.992854] \n[38.993148] btrfs_relocate_chunk+0x27/0xe0 [btrfs]\n[38.993941] btrfs_balance+0x78e/0xea0 [btrfs]\n[38.994801] ? vsnprintf+0x33c/0x520\n[38.995368] ? __kmalloc_track_caller+0x351/0x440\n[38.996198] btrfs_ioctl_balance+0x2b9/0x3a0 [btrfs]\n[38.997084] btrfs_ioctl+0x11b0/0x2da0 [btrfs]\n[38.997867] ? mod_objcg_state+0xee/0x340\n[38.998552] ? seq_release+0x24/0x30\n[38.999184] ? proc_nr_files+0x30/0x30\n[38.999654] ? call_rcu+0xc8/0x2f0\n[39.000228] ? __x64_sys_ioctl+0x84/0xc0\n[39.000872] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]\n[39.001973] __x64_sys_ioctl+0x84/0xc0\n[39.002566] do_syscall_64+0x3a/0x80\n[39.003011] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[39.003735] RIP: 0033:0x7f11c166959b\n[39.007324] RSP: 002b:00007fff2543e998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n[39.008521] RAX: ffffffffffffffda RBX: 00007f11c1521698 RCX: 00007f11c166959b\n[39.009833] RDX: 00007fff2543ea40 RSI: 00000000c4009420 RDI: 0000000000000003\n[39.011270] RBP: 0000000000000003 R08: 0000000000000013 R09: 00007f11c16f94e0\n[39.012581] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff25440df3\n[39.014046] R13: 0000000000000000 R14: 00007fff2543ea40 R15: 0000000000000001\n[39.015040] \n[39.015418] ---[ end trace 0000000000000000 ]---\n[43.131559] ------------[ cut here ]------------\n[43.132234] kernel BUG at fs/btrfs/extent-tree.c:2717!\n[43.133031] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[43.133702] CPU: 1 PID: 1839 Comm: btrfs Tainted: G W 5.17.0-rc4 #54\n[43.134863] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[43.136426] RIP: 0010:unpin_extent_range+0x37a/0x4f0 [btrfs]\n[43.139913] RSP: 0000:ffffb0dd4216bc70 EFLAGS: 00010246\n[43.140629] RAX: 0000000000000000 RBX: ffff96cfc34490f8 RCX: 0000000000000001\n[43.141604] RDX: 0000000080000001 RSI: 0000000051d00000 RDI: 00000000ffffffff\n[43.142645] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff96cfd07dca50\n[43.143669] R10: ffff96cfc46e8a00 R11: fffffffffffec000 R12: 0000000041d00000\n[43.144657] R13: ffff96cfc3ce0000 R14: ffffb0dd4216bd08 R15: 0000000000000000\n[43.145686] FS: 00007f7657dd68c0(0000) GS:ffff96d6df640000(0000) knlGS:0000000000000000\n[43.146808] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[43.147584] CR2: 00007f7fe81bf5b0 CR3: 00000001093ee004 CR4: 0000000000370ee0\n[43.148589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[43.149581] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\narm64/mm: fix incorrect file_map_count for invalid pmd\n\nThe page table check trigger BUG_ON() unexpectedly when split hugepage:\n\n ------------[ cut here ]------------\n kernel BUG at mm/page_table_check.c:119!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n Dumping ftrace buffer:\n (ftrace buffer empty)\n Modules linked in:\n CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748\n Hardware name: linux,dummy-virt (DT)\n pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : page_table_check_set.isra.0+0x398/0x468\n lr : page_table_check_set.isra.0+0x1c0/0x468\n[...]\n Call trace:\n page_table_check_set.isra.0+0x398/0x468\n __page_table_check_pte_set+0x160/0x1c0\n __split_huge_pmd_locked+0x900/0x1648\n __split_huge_pmd+0x28c/0x3b8\n unmap_page_range+0x428/0x858\n unmap_single_vma+0xf4/0x1c8\n zap_page_range+0x2b0/0x410\n madvise_vma_behavior+0xc44/0xe78\n do_madvise+0x280/0x698\n __arm64_sys_madvise+0x90/0xe8\n invoke_syscall.constprop.0+0xdc/0x1d8\n do_el0_svc+0xf4/0x3f8\n el0_svc+0x58/0x120\n el0t_64_sync_handler+0xb8/0xc0\n el0t_64_sync+0x19c/0x1a0\n[...]\n\nOn arm64, pmd_leaf() will return true even if the pmd is invalid due to\npmd_present_invalid() check. So in pmdp_invalidate() the file_map_count\nwill not only decrease once but also increase once. Then in set_pte_at(),\nthe file_map_count increase again, and so trigger BUG_ON() unexpectedly.\n\nAdd !pmd_present_invalid() check in pmd_user_accessible_page() to fix the\nproblem.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu: Don't unregister on shutdown\n\nMichael Walle says he noticed the following stack trace while performing\na shutdown with "reboot -f". He suggests he got "lucky" and just hit the\ncorrect spot for the reboot while there was a packet transmission in\nflight.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000098\nCPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 6.1.0-rc5-00088-gf3600ff8e322 #1930\nHardware name: Kontron KBox A-230-LS (DT)\npc : iommu_get_dma_domain+0x14/0x20\nlr : iommu_dma_map_page+0x9c/0x254\nCall trace:\n iommu_get_dma_domain+0x14/0x20\n dma_map_page_attrs+0x1ec/0x250\n enetc_start_xmit+0x14c/0x10b0\n enetc_xmit+0x60/0xdc\n dev_hard_start_xmit+0xb8/0x210\n sch_direct_xmit+0x11c/0x420\n __dev_queue_xmit+0x354/0xb20\n ip6_finish_output2+0x280/0x5b0\n __ip6_finish_output+0x15c/0x270\n ip6_output+0x78/0x15c\n NF_HOOK.constprop.0+0x50/0xd0\n mld_sendpack+0x1bc/0x320\n mld_ifc_work+0x1d8/0x4dc\n process_one_work+0x1e8/0x460\n worker_thread+0x178/0x534\n kthread+0xe0/0xe4\n ret_from_fork+0x10/0x20\nCode: d503201f f9416800 d503233f d50323bf (f9404c00)\n---[ end trace 0000000000000000 ]---\nKernel panic - not syncing: Oops: Fatal exception in interrupt\n\nThis appears to be reproducible when the board has a fixed IP address,\nis ping flooded from another host, and "reboot -f" is used.\n\nThe following is one more manifestation of the issue:\n\n$ reboot -f\nkvm: exiting hardware virtualization\ncfg80211: failed to load regulatory.db\narm-smmu 5000000.iommu: disabling translation\nsdhci-esdhc 2140000.mmc: Removing from iommu group 11\nsdhci-esdhc 2150000.mmc: Removing from iommu group 12\nfsl-edma 22c0000.dma-controller: Removing from iommu group 17\ndwc3 3100000.usb: Removing from iommu group 9\ndwc3 3110000.usb: Removing from iommu group 10\nahci-qoriq 3200000.sata: Removing from iommu group 2\nfsl-qdma 8380000.dma-controller: Removing from iommu group 20\nplatform f080000.display: Removing from iommu group 0\netnaviv-gpu f0c0000.gpu: Removing from iommu group 1\netnaviv etnaviv: Removing from iommu group 1\ncaam_jr 8010000.jr: Removing from iommu group 13\ncaam_jr 8020000.jr: Removing from iommu group 14\ncaam_jr 8030000.jr: Removing from iommu group 15\ncaam_jr 8040000.jr: Removing from iommu group 16\nfsl_enetc 00.0: Removing from iommu group 4\narm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications\narm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000\nfsl_enetc 00.1: Removing from iommu group 5\narm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications\narm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000\narm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications\narm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000\nfsl_enetc 00.2: Removing from iommu group 6\nfsl_enetc_mdio 00.3: Removing from iommu group 8\nmscc_felix 00.5: Removing from iommu group 3\nfsl_enetc 00.6: Removing from iommu group 7\npcieport 0001:00:00.0: Removing from iommu group 18\narm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications\narm-smmu 5000000.iommu: GFSR 0x00000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000\npcieport 0002:00:00.0: Removing from iommu group 19\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000a8\npc : iommu_get_dma_domain+0x14/0x20\nlr : iommu_dma_unmap_page+0x38/0xe0\nCall trace:\n iommu_get_dma_domain+0x14/0x20\n dma_unmap_page_attrs+0x38/0x1d0\n en\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-v3: Don't unregister on shutdown\n\nSimilar to SMMUv2, this driver calls iommu_device_unregister() from the\nshutdown path, which removes the IOMMU groups with no coordination\nwhatsoever with their users - shutdown methods are optional in device\ndrivers. This can lead to NULL pointer dereferences in those drivers'\nDMA API calls, or worse.\n\nInstead of calling the full arm_smmu_device_remove() from\narm_smmu_device_shutdown(), let's pick only the relevant function call -\narm_smmu_device_disable() - more or less the reverse of\narm_smmu_device_reset() - and call just that from the shutdown path.

In the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Fix use-after-free bug in dup_user_cpus_ptr()\n\nSince commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be\nrestricted on asymmetric systems"), the setting and clearing of\nuser_cpus_ptr are done under pi_lock for arm64 architecture. However,\ndup_user_cpus_ptr() accesses user_cpus_ptr without any lock\nprotection. Since sched_setaffinity() can be invoked from another\nprocess, the process being modified may be undergoing fork() at\nthe same time. When racing with the clearing of user_cpus_ptr in\n__set_cpus_allowed_ptr_locked(), it can lead to user-after-free and\npossibly double-free in arm64 kernel.\n\nCommit 8f9ea86fdf99 ("sched: Always preserve the user requested\ncpumask") fixes this problem as user_cpus_ptr, once set, will never\nbe cleared in a task's lifetime. However, this bug was re-introduced\nin commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in\ndo_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in\ndo_set_cpus_allowed(). This time, it will affect all arches.\n\nFix this bug by always clearing the user_cpus_ptr of the newly\ncloned/forked task before the copying process starts and check the\nuser_cpus_ptr state of the source task under pi_lock.\n\nNote to stable, this patch won't be applicable to stable releases.\nJust copy the new dup_user_cpus_ptr() function over.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM\n\nstorvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(),\nwhich in a confidential VM allocates swiotlb bounce buffers. If the I/O\nsubmission fails in storvsc_do_io(), the I/O is typically retried by higher\nlevel code, but the bounce buffer memory is never freed. The mostly like\ncause of I/O submission failure is a full VMBus channel ring buffer, which\nis not uncommon under high I/O loads. Eventually enough bounce buffer\nmemory leaks that the confidential VM can't do any I/O. The same problem\ncan arise in a non-confidential VM with kernel boot parameter\nswiotlb=force.\n\nFix this by doing scsi_dma_unmap() in the case of an I/O submission\nerror, which frees the bounce buffer memory.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: sof-nau8825: fix module alias overflow\n\nThe maximum name length for a platform_device_id entry is 20 characters\nincluding the trailing NUL byte. The sof_nau8825.c file exceeds that,\nwhich causes an obscure error message:\n\nsound/soc/intel/boards/snd-soc-sof_nau8825.mod.c:35:45: error: illegal character encoding in string literal [-Werror,-Winvalid-source-encoding]\nMODULE_ALIAS("platform:adl_max98373_nau8825");\n ^~~~\ninclude/linux/module.h:168:49: note: expanded from macro 'MODULE_ALIAS'\n ^~~~~~\ninclude/linux/module.h:165:56: note: expanded from macro 'MODULE_INFO'\n ^~~~\ninclude/linux/moduleparam.h:26:47: note: expanded from macro '__MODULE_INFO'\n = __MODULE_INFO_PREFIX __stringify(tag) "=" info\n\nI could not figure out how to make the module handling robust enough\nto handle this better, but as a quick fix, using slightly shorter\nnames that are still unique avoids the build issue.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dpu: Fix memory leak in msm_mdss_parse_data_bus_icc_path\n\nof_icc_get() alloc resources for path1, we should release it when not\nneed anymore. Early return when IS_ERR_OR_NULL(path0) may leak path1.\nDefer getting path1 to fix this.\n\nPatchwork: https://patchwork.freedesktop.org/patch/514264/

In the Linux kernel, the following vulnerability has been resolved:\n\nice: Add check for kzalloc\n\nAdd the check for the return value of kzalloc in order to avoid\nNULL pointer dereference.\nMoreover, use the goto-label to share the clean code.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix potential memory leak in ice_gnss_tty_write()\n\nThe ice_gnss_tty_write() return directly if the write_buf alloc failed,\nleaking the cmd_buf.\n\nFix by free cmd_buf if write_buf alloc failed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix command stats access after free\n\nCommand may fail while driver is reloading and can't accept FW commands\ntill command interface is reinitialized. Such command failure is being\nlogged to command stats. This results in NULL pointer access as command\nstats structure is being freed and reallocated during mlx5 devlink\nreload (see kernel log below).\n\nFix it by making command stats statically allocated on driver probe.\n\nKernel log:\n[ 2394.808802] BUG: unable to handle kernel paging request at 000000000002a9c0\n[ 2394.810610] PGD 0 P4D 0\n[ 2394.811811] Oops: 0002 [#1] SMP NOPTI\n...\n[ 2394.815482] RIP: 0010:native_queued_spin_lock_slowpath+0x183/0x1d0\n...\n[ 2394.829505] Call Trace:\n[ 2394.830667] _raw_spin_lock_irq+0x23/0x26\n[ 2394.831858] cmd_status_err+0x55/0x110 [mlx5_core]\n[ 2394.833020] mlx5_access_reg+0xe7/0x150 [mlx5_core]\n[ 2394.834175] mlx5_query_port_ptys+0x78/0xa0 [mlx5_core]\n[ 2394.835337] mlx5e_ethtool_get_link_ksettings+0x74/0x590 [mlx5_core]\n[ 2394.836454] ? kmem_cache_alloc_trace+0x140/0x1c0\n[ 2394.837562] __rh_call_get_link_ksettings+0x33/0x100\n[ 2394.838663] ? __rtnl_unlock+0x25/0x50\n[ 2394.839755] __ethtool_get_link_ksettings+0x72/0x150\n[ 2394.840862] duplex_show+0x6e/0xc0\n[ 2394.841963] dev_attr_show+0x1c/0x40\n[ 2394.843048] sysfs_kf_seq_show+0x9b/0x100\n[ 2394.844123] seq_read+0x153/0x410\n[ 2394.845187] vfs_read+0x91/0x140\n[ 2394.846226] ksys_read+0x4f/0xb0\n[ 2394.847234] do_syscall_64+0x5b/0x1a0\n[ 2394.848228] entry_SYSCALL_64_after_hwframe+0x65/0xca

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent\n\nA user is able to configure an arbitrary number of rx queues when\ncreating an interface via netlink. This doesn't work for child PKEY\ninterfaces because the child interface uses the parent receive channels.\n\nAlthough the child shares the parent's receive channels, the number of\nrx queues is important for the channel_stats array: the parent's rx\nchannel index is used to access the child's channel_stats. So the array\nhas to be at least as large as the parent's rx queue size for the\ncounting to work correctly and to prevent out of bound accesses.\n\nThis patch checks for the mentioned scenario and returns an error when\ntrying to create the interface. The error is propagated to the user.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix macsec possible null dereference when updating MAC security entity (SecY)\n\nUpon updating MAC security entity (SecY) in hw offload path, the macsec\nsecurity association (SA) initialization routine is called. In case of\nextended packet number (epn) is enabled the salt and ssci attributes are\nretrieved using the MACsec driver rx_sa context which is unavailable when\nupdating a SecY property such as encoding-sa hence the null dereference.\nFix by using the provided SA to set those attributes.

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd: Fix refcount leak in amd_pmc_probe\n\npci_get_domain_bus_and_slot() takes reference, the caller should release\nthe reference by calling pci_dev_put() after use. Call pci_dev_put() in\nthe error path to fix this.

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/surface: aggregator: Add missing call to ssam_request_sync_free()\n\nAlthough rare, ssam_request_sync_init() can fail. In that case, the\nrequest should be freed via ssam_request_sync_free(). Currently it is\nleaked instead. Fix this.

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: Fix use-after-free and race in fastrpc_map_find\n\nCurrently, there is a race window between the point when the mutex is\nunlocked in fastrpc_map_lookup and the reference count increasing\n(fastrpc_map_get) in fastrpc_map_find, which can also lead to\nuse-after-free.\n\nSo lets merge fastrpc_map_find into fastrpc_map_lookup which allows us\nto both protect the maps list by also taking the &fl->lock spinlock and\nthe reference count, since the spinlock will be released only after.\nAdd take_ref argument to make this suitable for all callers.

In the Linux kernel, the following vulnerability has been resolved:\n\ntty: fix possible null-ptr-defer in spk_ttyio_release\n\nRun the following tests on the qemu platform:\n\nsyzkaller:~# modprobe speakup_audptr\n input: Speakup as /devices/virtual/input/input4\n initialized device: /dev/synth, node (MAJOR 10, MINOR 125)\n speakup 3.1.6: initialized\n synth name on entry is: (null)\n synth probe\n\nspk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned\nfailed (errno -16), then remove the module, we will get a null-ptr-defer\nproblem, as follow:\n\nsyzkaller:~# modprobe -r speakup_audptr\n releasing synth audptr\n BUG: kernel NULL pointer dereference, address: 0000000000000080\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0\n Oops: 0002 [#1] PREEMPT SMP PTI\n CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1\n RIP: 0010:mutex_lock+0x14/0x30\n Call Trace:\n \n spk_ttyio_release+0x19/0x70 [speakup]\n synth_release.part.6+0xac/0xc0 [speakup]\n synth_remove+0x56/0x60 [speakup]\n __x64_sys_delete_module+0x156/0x250\n ? fpregs_assert_state_consistent+0x1d/0x50\n do_syscall_64+0x37/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n \n Modules linked in: speakup_audptr(-) speakup\n Dumping ftrace buffer:\n\nin_synth->dev was not initialized during modprobe, so we add check\nfor in_synth->dev to fix this bug.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Prevent use after free on completion memory\n\nOn driver unload any pending descriptors are flushed at the\ntime the interrupt is freed:\nidxd_dmaengine_drv_remove() ->\n drv_disable_wq() ->\n idxd_wq_free_irq() ->\n idxd_flush_pending_descs().\n\nIf there are any descriptors present that need to be flushed this\nflow triggers a "not present" page fault as below:\n\n BUG: unable to handle page fault for address: ff391c97c70c9040\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n\nThe address that triggers the fault is the address of the\ndescriptor that was freed moments earlier via:\ndrv_disable_wq()->idxd_wq_free_resources()\n\nFix the use after free by freeing the descriptors after any possible\nusage. This is done after idxd_wq_reset() to ensure that the memory\nremains accessible during possible completion writes by the device.

Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an\nempty supported client protocols buffer may cause a crash or memory contents to\nbe sent to the peer.\n\nImpact summary: A buffer overread can have a range of potential consequences\nsuch as unexpected application beahviour or a crash. In particular this issue\ncould result in up to 255 bytes of arbitrary private data from memory being sent\nto the peer leading to a loss of confidentiality. However, only applications\nthat directly call the SSL_select_next_proto function with a 0 length list of\nsupported client protocols are affected by this issue. This would normally never\nbe a valid scenario and is typically not under attacker control but may occur by\naccident in the case of a configuration or programming error in the calling\napplication.\n\nThe OpenSSL API function SSL_select_next_proto is typically used by TLS\napplications that support ALPN (Application Layer Protocol Negotiation) or NPN\n(Next Protocol Negotiation). NPN is older, was never standardised and\nis deprecated in favour of ALPN. We believe that ALPN is significantly more\nwidely deployed than NPN. The SSL_select_next_proto function accepts a list of\nprotocols from the server and a list of protocols from the client and returns\nthe first protocol that appears in the server list that also appears in the\nclient list. In the case of no overlap between the two lists it returns the\nfirst item in the client list. In either case it will signal whether an overlap\nbetween the two lists was found. In the case where SSL_select_next_proto is\ncalled with a zero length client list it fails to notice this condition and\nreturns the memory immediately following the client list pointer (and reports\nthat there was no overlap in the lists).\n\nThis function is typically called from a server side application callback for\nALPN or a client side application callback for NPN. In the case of ALPN the list\nof protocols supplied by the client is guaranteed by libssl to never be zero in\nlength. The list of server protocols comes from the application and should never\nnormally be expected to be of zero length. In this case if the\nSSL_select_next_proto function has been called as expected (with the list\nsupplied by the client passed in the client/client_len parameters), then the\napplication will not be vulnerable to this issue. If the application has\naccidentally been configured with a zero length server list, and has\naccidentally passed that zero length server list in the client/client_len\nparameters, and has additionally failed to correctly handle a "no overlap"\nresponse (which would normally result in a handshake failure in ALPN) then it\nwill be vulnerable to this problem.\n\nIn the case of NPN, the protocol permits the client to opportunistically select\na protocol when there is no overlap. OpenSSL returns the first client protocol\nin the no overlap case in support of this. The list of client protocols comes\nfrom the application and should never normally be expected to be of zero length.\nHowever if the SSL_select_next_proto function is accidentally called with a\nclient_len of 0 then an invalid memory pointer will be returned instead. If the\napplication uses this output as the opportunistic protocol then the loss of\nconfidentiality will occur.\n\nThis issue has been assessed as Low severity because applications are most\nlikely to be vulnerable if they are using NPN instead of ALPN - but NPN is not\nwidely used. It also requires an application configuration or programming error.\nFinally, this issue would not typically be under attacker control making active\nexploitation unlikely.\n\nThe FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.\n\nDue to the low severity of this issue we are not issuing new releases of\nOpenSSL at this time. The fix will be included in the next releases when they\nbecome available.

.NET and Visual Studio Denial of Service Vulnerability

.NET, .NET Framework, and Visual Studio Denial of Service Vulnerability

.NET, .NET Framework, and Visual Studio Denial of Service Vulnerability

In the Linux kernel, the following vulnerability has been resolved:\n\nlandlock: Fix d_parent walk\n\nThe WARN_ON_ONCE() in collect_domain_accesses() can be triggered when\ntrying to link a root mount point. This cannot work in practice because\nthis directory is mounted, but the VFS check is done after the call to\nsecurity_path_link().\n\nDo not use source directory's d_parent when the source directory is the\nmount point.\n\n[mic: Fix commit message]

In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: defer exposing anon_fd until after copy_to_user() succeeds\n\nAfter installing the anonymous fd, we can now see it in userland and close\nit. However, at this point we may not have gotten the reference count of\nthe cache, but we will put it during colse fd, so this may cause a cache\nUAF.\n\nSo grab the cache reference count before fd_install(). In addition, by\nkernel convention, fd is taken over by the user land after fd_install(),\nand the kernel should not call close_fd() after that, i.e., it should call\nfd_install() after everything is ready, thus fd_install() is called after\ncopy_to_user() succeeds.

In the Linux kernel, the following vulnerability has been resolved:\n\nkunit/fortify: Fix mismatched kvalloc()/vfree() usage\n\nThe kv*() family of tests were accidentally freeing with vfree() instead\nof kvfree(). Use kvfree() instead.

In the Linux kernel, the following vulnerability has been resolved:\n\nopenrisc: traps: Don't send signals to kernel mode threads\n\nOpenRISC exception handling sends signals to user processes on floating\npoint exceptions and trap instructions (for debugging) among others.\nThere is a bug where the trap handling logic may send signals to kernel\nthreads, we should not send these signals to kernel threads, if that\nhappens we treat it as an error.\n\nThis patch adds conditions to die if the kernel receives these\nexceptions in kernel mode code.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()\n\nPatch series "mm: follow_pte() improvements and acrn follow_pte() fixes".\n\nPatch #1 fixes a bunch of issues I spotted in the acrn driver. It\ncompiles, that's all I know. I'll appreciate some review and testing from\nacrn folks.\n\nPatch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding\nmore sanity checks, and improving the documentation. Gave it a quick test\non x86-64 using VM_PAT that ends up using follow_pte().\n\n\nThis patch (of 3):\n\nWe currently miss handling various cases, resulting in a dangerous\nfollow_pte() (previously follow_pfn()) usage.\n\n(1) We're not checking PTE write permissions.\n\nMaybe we should simply always require pte_write() like we do for\npin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for\nACRN_MEM_ACCESS_WRITE for now.\n\n(2) We're not rejecting refcounted pages.\n\nAs we are not using MMU notifiers, messing with refcounted pages is\ndangerous and can result in use-after-free. Let's make sure to reject them.\n\n(3) We are only looking at the first PTE of a bigger range.\n\nWe only lookup a single PTE, but memmap->len may span a larger area.\nLet's loop over all involved PTEs and make sure the PFN range is\nactually contiguous. Reject everything else: it couldn't have worked\neither way, and rather made use access PFNs we shouldn't be accessing.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: connac: check for null before dereferencing\n\nThe wcid can be NULL. It should be checked for validity before\ndereferencing it to avoid crash.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - validate slices count returned by FW\n\nThe function adf_send_admin_tl_start() enables the telemetry (TL)\nfeature on a QAT device by sending the ICP_QAT_FW_TL_START message to\nthe firmware. This triggers the FW to start writing TL data to a DMA\nbuffer in memory and returns an array containing the number of\naccelerators of each type (slices) supported by this HW.\nThe pointer to this array is stored in the adf_tl_hw_data data\nstructure called slice_cnt.\n\nThe array slice_cnt is then used in the function tl_print_dev_data()\nto report in debugfs only statistics about the supported accelerators.\nAn incorrect value of the elements in slice_cnt might lead to an out\nof bounds memory read.\nAt the moment, there isn't an implementation of FW that returns a wrong\nvalue, but for robustness validate the slice count array returned by FW.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: core: Fix NULL module pointer assignment at card init\n\nThe commit 81033c6b584b ("ALSA: core: Warn on empty module")\nintroduced a WARN_ON() for a NULL module pointer passed at snd_card\nobject creation, and it also wraps the code around it with '#ifdef\nMODULE'. This works in most cases, but the devils are always in\ndetails. "MODULE" is defined when the target code (i.e. the sound\ncore) is built as a module; but this doesn't mean that the caller is\nalso built-in or not. Namely, when only the sound core is built-in\n(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),\nthe passed module pointer is ignored even if it's non-NULL, and\ncard->module remains as NULL. This would result in the missing module\nreference up/down at the device open/close, leading to a race with the\ncode execution after the module removal.\n\nFor addressing the bug, move the assignment of card->module again out\nof ifdef. The WARN_ON() is still wrapped with ifdef because the\nmodule can be really NULL when all sound drivers are built-in.\n\nNote that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would\nlead to a false-positive NULL module check. Admittedly it won't catch\nperfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no\nreal problem as it's only for debugging, and the condition is pretty\nrare.