In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list\n\nUse list_for_each_entry_safe() to allow iterating through the list and\ndeleting the entry in the iteration process. The descriptor is freed via\nidxd_desc_complete() and there's a slight chance may cause issue for\nthe list iterator when the descriptor is reused by another thread\nwithout it being deleted from the list.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/kexec: Fix bug with call depth tracking\n\nThe call to cc_platform_has() triggers a fault and system crash if call depth\ntracking is active because the GS segment has been reset by load_segments() and\nGS_BASE is now 0 but call depth tracking uses per-CPU variables to operate.\n\nCall cc_platform_has() earlier in the function when GS is still valid.\n\n [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix tainted pointer delete is case of flow rules creation fail\n\nIn case of flow rule creation fail in mlx5_lag_create_port_sel_table(),\ninstead of previously created rules, the tainted pointer is deleted\ndeveral times.\nFix this bug by using correct flow rules pointers.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: iosm: Fix tainted pointer delete is case of region creation fail\n\nIn case of region creation fail in ipc_devlink_create_region(), previously\ncreated regions delete process starts from tainted pointer which actually\nholds error code value.\nFix this bug by decreasing region index before delete.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\ngve: Clear napi->skb before dev_kfree_skb_any()\n\ngve_rx_free_skb incorrectly leaves napi->skb referencing an skb after it\nis freed with dev_kfree_skb_any(). This can result in a subsequent call\nto napi_get_frags returning a dangling pointer.\n\nFix this by clearing napi->skb before the skb is freed.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/region: Fix memregion leaks in devm_cxl_add_region()\n\nMove the mode verification to __create_region() before allocating the\nmemregion to avoid the memregion leaks.

In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: flush all requests after setting CACHEFILES_DEAD\n\nIn ondemand mode, when the daemon is processing an open request, if the\nkernel flags the cache as CACHEFILES_DEAD, the cachefiles_daemon_write()\nwill always return -EIO, so the daemon can't pass the copen to the kernel.\nThen the kernel process that is waiting for the copen triggers a hung_task.\n\nSince the DEAD state is irreversible, it can only be exited by closing\n/dev/cachefiles. Therefore, after calling cachefiles_io_error() to mark\nthe cache as CACHEFILES_DEAD, if in ondemand mode, flush all requests to\navoid the above hungtask. We may still be able to read some of the cached\ndata before closing the fd of /dev/cachefiles.\n\nNote that this relies on the patch that adds reference counting to the req,\notherwise it may UAF.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: temperature: mlx90635: Fix ERR_PTR dereference in mlx90635_probe()\n\nWhen devm_regmap_init_i2c() fails, regmap_ee could be error pointer,\ninstead of checking for IS_ERR(regmap_ee), regmap is checked which looks\nlike a copy paste error.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: validate HE operation element parsing\n\nValidate that the HE operation element has the correct\nlength before parsing it.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethtool: fix the error condition in ethtool_get_phy_stats_ethtool()\n\nClang static checker (scan-build) warning:\nnet/ethtool/ioctl.c:line 2233, column 2\nCalled function pointer is null (null dereference).\n\nReturn '-EOPNOTSUPP' when 'ops->get_ethtool_phy_stats' is NULL to fix\nthis typo error.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: don't attempt to schedule hpd_work on headless cards\n\nIf the card doesn't have display hardware, hpd_work and hpd_lock are\nleft uninitialized which causes BUG when attempting to schedule hpd_work\non runtime PM resume.\n\nFix it by adding headless flag to DRM and skip any hpd if it's set.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/dpt: Make DPT object unshrinkable\n\nIn some scenarios, the DPT object gets shrunk but\nthe actual framebuffer did not and thus its still\nthere on the DPT's vm->bound_list. Then it tries to\nrewrite the PTEs via a stale CPU mapping. This causes panic.\n\n[vsyrjala: Add TODO comment]\n(cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)

In the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: disable rx data ring on dma allocation failure\n\nWhen vmxnet3_rq_create() fails to allocate memory for rq->data_ring.base,\nthe subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset\nrq->data_ring.desc_size for the data ring that failed, which presumably\ncauses the hypervisor to reference it on packet reception.\n\nTo fix this bug, rq->data_ring.desc_size needs to be set to 0 to tell\nthe hypervisor to disable this feature.\n\n[ 95.436876] kernel BUG at net/core/skbuff.c:207!\n[ 95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1\n[ 95.441558] Hardware name: VMware, Inc. VMware Virtual\nPlatform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018\n[ 95.443481] RIP: 0010:skb_panic+0x4d/0x4f\n[ 95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50\nff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9\nff <0f> 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24\n[ 95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246\n[ 95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f\n[ 95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f\n[ 95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60\n[ 95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000\n[ 95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0\n[ 95.455682] FS: 0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000\n[ 95.457178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0\n[ 95.459791] Call Trace:\n[ 95.460515] \n[ 95.461180] ? __die_body.cold+0x19/0x27\n[ 95.462150] ? die+0x2e/0x50\n[ 95.462976] ? do_trap+0xca/0x110\n[ 95.463973] ? do_error_trap+0x6a/0x90\n[ 95.464966] ? skb_panic+0x4d/0x4f\n[ 95.465901] ? exc_invalid_op+0x50/0x70\n[ 95.466849] ? skb_panic+0x4d/0x4f\n[ 95.467718] ? asm_exc_invalid_op+0x1a/0x20\n[ 95.468758] ? skb_panic+0x4d/0x4f\n[ 95.469655] skb_put.cold+0x10/0x10\n[ 95.470573] vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3]\n[ 95.471853] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3]\n[ 95.473185] __napi_poll+0x2b/0x160\n[ 95.474145] net_rx_action+0x2c6/0x3b0\n[ 95.475115] handle_softirqs+0xe7/0x2a0\n[ 95.476122] __irq_exit_rcu+0x97/0xb0\n[ 95.477109] common_interrupt+0x85/0xa0\n[ 95.478102] \n[ 95.478846] \n[ 95.479603] asm_common_interrupt+0x26/0x40\n[ 95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20\n[ 95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90\n[ 95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246\n[ 95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000\n[ 95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001\n[ 95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3\n[ 95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260\n[ 95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000\n[ 95.495035] acpi_safe_halt+0x14/0x20\n[ 95.496127] acpi_idle_do_entry+0x2f/0x50\n[ 95.497221] acpi_idle_enter+0x7f/0xd0\n[ 95.498272] cpuidle_enter_state+0x81/0x420\n[ 95.499375] cpuidle_enter+0x2d/0x40\n[ 95.500400] do_idle+0x1e5/0x240\n[ 95.501385] cpu_startup_entry+0x29/0x30\n[ 95.502422] start_secondary+0x11c/0x140\n[ 95.503454] common_startup_64+0x13e/0x141\n[ 95.504466] \n[ 95.505197] Modules linked in: nft_fib_inet nft_fib_ipv4\nnft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6\nnft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ip\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/rsrc: don't lock while !TASK_RUNNING\n\nThere is a report of io_rsrc_ref_quiesce() locking a mutex while not\nTASK_RUNNING, which is due to forgetting restoring the state back after\nio_run_task_work_sig() and attempts to break out of the waiting loop.\n\ndo not call blocking ops when !TASK_RUNNING; state=1 set at\n[] prepare_to_wait+0xa4/0x380\nkernel/sched/wait.c:237\nWARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099\n__might_sleep+0x114/0x160 kernel/sched/core.c:10099\nRIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099\nCall Trace:\n \n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752\n io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253\n io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799\n __io_uring_register io_uring/register.c:424 [inline]\n __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x6f/0x77

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: mst: pass vlan group directly to br_mst_vlan_set_state\n\nPass the already obtained vlan group pointer to br_mst_vlan_set_state()\ninstead of dereferencing it again. Each caller has already correctly\ndereferenced it for their context. This change is required for the\nfollowing suspicious RCU dereference fix. No functional changes\nintended.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: mst: fix suspicious rcu usage in br_mst_set_state\n\nI converted br_mst_set_state to RCU to avoid a vlan use-after-free\nbut forgot to change the vlan group dereference helper. Switch to vlan\ngroup RCU deref helper to fix the suspicious rcu usage warning.

In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send()\n\nIn case of token is released due to token->state == BNXT_HWRM_DEFERRED,\nreleased token (set to NULL) is used in log messages. This issue is\nexpected to be prevented by HWRM_ERR_CODE_PF_UNAVAILABLE error code. But\nthis error code is returned by recent firmware. So some firmware may not\nreturn it. This may lead to NULL pointer dereference.\nAdjust this issue by adding token pointer check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Try to fix random segmentation faults in package builds\n\nPA-RISC systems with PA8800 and PA8900 processors have had problems\nwith random segmentation faults for many years. Systems with earlier\nprocessors are much more stable.\n\nSystems with PA8800 and PA8900 processors have a large L2 cache which\nneeds per page flushing for decent performance when a large range is\nflushed. The combined cache in these systems is also more sensitive to\nnon-equivalent aliases than the caches in earlier systems.\n\nThe majority of random segmentation faults that I have looked at\nappear to be memory corruption in memory allocated using mmap and\nmalloc.\n\nMy first attempt at fixing the random faults didn't work. On\nreviewing the cache code, I realized that there were two issues\nwhich the existing code didn't handle correctly. Both relate\nto cache move-in. Another issue is that the present bit in PTEs\nis racy.\n\n1) PA-RISC caches have a mind of their own and they can speculatively\nload data and instructions for a page as long as there is a entry in\nthe TLB for the page which allows move-in. TLBs are local to each\nCPU. Thus, the TLB entry for a page must be purged before flushing\nthe page. This is particularly important on SMP systems.\n\nIn some of the flush routines, the flush routine would be called\nand then the TLB entry would be purged. This was because the flush\nroutine needed the TLB entry to do the flush.\n\n2) My initial approach to trying the fix the random faults was to\ntry and use flush_cache_page_if_present for all flush operations.\nThis actually made things worse and led to a couple of hardware\nlockups. It finally dawned on me that some lines weren't being\nflushed because the pte check code was racy. This resulted in\nrandom inequivalent mappings to physical pages.\n\nThe __flush_cache_page tmpalias flush sets up its own TLB entry\nand it doesn't need the existing TLB entry. As long as we can find\nthe pte pointer for the vm page, we can get the pfn and physical\naddress of the page. We can also purge the TLB entry for the page\nbefore doing the flush. Further, __flush_cache_page uses a special\nTLB entry that inhibits cache move-in.\n\nWhen switching page mappings, we need to ensure that lines are\nremoved from the cache. It is not sufficient to just flush the\nlines to memory as they may come back.\n\nThis made it clear that we needed to implement all the required\nflush operations using tmpalias routines. This includes flushes\nfor user and kernel pages.\n\nAfter modifying the code to use tmpalias flushes, it became clear\nthat the random segmentation faults were not fully resolved. The\nfrequency of faults was worse on systems with a 64 MB L2 (PA8900)\nand systems with more CPUs (rp4440).\n\nThe warning that I added to flush_cache_page_if_present to detect\npages that couldn't be flushed triggered frequently on some systems.\n\nHelge and I looked at the pages that couldn't be flushed and found\nthat the PTE was either cleared or for a swap page. Ignoring pages\nthat were swapped out seemed okay but pages with cleared PTEs seemed\nproblematic.\n\nI looked at routines related to pte_clear and noticed ptep_clear_flush.\nThe default implementation just flushes the TLB entry. However, it was\nobvious that on parisc we need to flush the cache page as well. If\nwe don't flush the cache page, stale lines will be left in the cache\nand cause random corruption. Once a PTE is cleared, there is no way\nto find the physical address associated with the PTE and flush the\nassociated page at a later time.\n\nI implemented an updated change with a parisc specific version of\nptep_clear_flush. It fixed the random data corruption on Helge's rp4440\nand rp3440, as well as on my c8000.\n\nAt this point, I realized that I could restore the code where we only\nflush in flush_cache_page_if_present if the page has been accessed.\nHowever, for this, we also need to flush the cache when the accessed\nbit is cleared in\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nmemblock: make memblock_set_node() also warn about use of MAX_NUMNODES\n\nOn an (old) x86 system with SRAT just covering space above 4Gb:\n\n ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff] hotplug\n\nthe commit referenced below leads to this NUMA configuration no longer\nbeing refused by a CONFIG_NUMA=y kernel (previously\n\n NUMA: nodes only cover 6144MB of your 8185MB e820 RAM. Not used.\n No NUMA configuration found\n Faking a node at [mem 0x0000000000000000-0x000000027fffffff]\n\nwas seen in the log directly after the message quoted above), because of\nmemblock_validate_numa_coverage() checking for NUMA_NO_NODE (only). This\nin turn led to memblock_alloc_range_nid()'s warning about MAX_NUMNODES\ntriggering, followed by a NULL deref in memmap_init() when trying to\naccess node 64's (NODE_SHIFT=6) node data.\n\nTo compensate said change, make memblock_set_node() warn on and adjust\na passed in value of MAX_NUMNODES, just like various other functions\nalready do.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: rewrite __kernel_map_pages() to fix sleeping in invalid context\n\n__kernel_map_pages() is a debug function which clears the valid bit in page\ntable entry for deallocated pages to detect illegal memory accesses to\nfreed pages.\n\nThis function set/clear the valid bit using __set_memory(). __set_memory()\nacquires init_mm's semaphore, and this operation may sleep. This is\nproblematic, because __kernel_map_pages() can be called in atomic context,\nand thus is illegal to sleep. An example warning that this causes:\n\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd\npreempt_count: 2, expected: 0\nCPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37\nHardware name: riscv-virtio,qemu (DT)\nCall Trace:\n[] dump_backtrace+0x1c/0x24\n[] show_stack+0x2c/0x38\n[] dump_stack_lvl+0x5a/0x72\n[] dump_stack+0x14/0x1c\n[] __might_resched+0x104/0x10e\n[] __might_sleep+0x3e/0x62\n[] down_write+0x20/0x72\n[] __set_memory+0x82/0x2fa\n[] __kernel_map_pages+0x5a/0xd4\n[] __alloc_pages_bulk+0x3b2/0x43a\n[] __vmalloc_node_range+0x196/0x6ba\n[] copy_process+0x72c/0x17ec\n[] kernel_clone+0x60/0x2fe\n[] kernel_thread+0x82/0xa0\n[] kthreadd+0x14a/0x1be\n[] ret_from_fork+0xe/0x1c\n\nRewrite this function with apply_to_existing_page_range(). It is fine to\nnot have any locking, because __kernel_map_pages() works with pages being\nallocated/deallocated and those pages are not changed by anyone else in the\nmeantime.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: don't unpoison huge_zero_folio\n\nWhen I did memory failure tests recently, below panic occurs:\n\n kernel BUG at include/linux/mm.h:1135!\n invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14\n RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0\n RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246\n RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8\n RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0\n RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492\n R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000\n R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00\n FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0\n Call Trace:\n \n do_shrink_slab+0x14f/0x6a0\n shrink_slab+0xca/0x8c0\n shrink_node+0x2d0/0x7d0\n balance_pgdat+0x33a/0x720\n kswapd+0x1f3/0x410\n kthread+0xd5/0x100\n ret_from_fork+0x2f/0x50\n ret_from_fork_asm+0x1a/0x30\n \n Modules linked in: mce_inject hwpoison_inject\n ---[ end trace 0000000000000000 ]---\n RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0\n RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246\n RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8\n RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0\n RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492\n R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000\n R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00\n FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0\n\nThe root cause is that HWPoison flag will be set for huge_zero_folio\nwithout increasing the folio refcnt. But then unpoison_memory() will\ndecrease the folio refcnt unexpectedly as it appears like a successfully\nhwpoisoned folio leading to VM_BUG_ON_PAGE(page_ref_count(page) == 0) when\nreleasing huge_zero_folio.\n\nSkip unpoisoning huge_zero_folio in unpoison_memory() to fix this issue. \nWe're not prepared to unpoison huge_zero_folio yet.

In the Linux kernel, the following vulnerability has been resolved:\n\nax25: Fix refcount imbalance on inbound connections\n\nWhen releasing a socket in ax25_release(), we call netdev_put() to\ndecrease the refcount on the associated ax.25 device. However, the\nexecution path for accepting an incoming connection never calls\nnetdev_hold(). This imbalance leads to refcount errors, and ultimately\nto kernel crashes.\n\nA typical call trace for the above situation will start with one of the\nfollowing errors:\n\n refcount_t: decrement hit 0; leaking memory.\n refcount_t: underflow; use-after-free.\n\nAnd will then have a trace like:\n\n Call Trace:\n \n ? show_regs+0x64/0x70\n ? __warn+0x83/0x120\n ? refcount_warn_saturate+0xb2/0x100\n ? report_bug+0x158/0x190\n ? prb_read_valid+0x20/0x30\n ? handle_bug+0x3e/0x70\n ? exc_invalid_op+0x1c/0x70\n ? asm_exc_invalid_op+0x1f/0x30\n ? refcount_warn_saturate+0xb2/0x100\n ? refcount_warn_saturate+0xb2/0x100\n ax25_release+0x2ad/0x360\n __sock_release+0x35/0xa0\n sock_close+0x19/0x20\n [...]\n\nOn reboot (or any attempt to remove the interface), the kernel gets\nstuck in an infinite loop:\n\n unregister_netdevice: waiting for ax0 to become free. Usage count = 0\n\nThis patch corrects these issues by ensuring that we call netdev_hold()\nand ax25_dev_hold() for new connections in ax25_accept(). This makes the\nlogic leading to ax25_accept() match the logic for ax25_bind(): in both\ncases we increment the refcount, which is ultimately decremented in\nax25_release().

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a potential use-after-free in bpf_link_free()\n\nAfter commit 1a80dbcb2dba, bpf_link can be freed by\nlink->ops->dealloc_deferred, but the code still tests and uses\nlink->ops->dealloc afterward, which leads to a use-after-free as\nreported by syzbot. Actually, one of them should be sufficient, so\njust call one of them instead of both. Also add a WARN_ON() in case\nof any problematic implementation.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Set run context for rawtp test_run callback\n\nsyzbot reported crash when rawtp program executed through the\ntest_run interface calls bpf_get_attach_cookie helper or any\nother helper that touches task->bpf_ctx pointer.\n\nSetting the run context (task->bpf_ctx pointer) for test_run\ncallback.

In the Linux kernel, the following vulnerability has been resolved:\n\nionic: fix kernel panic in XDP_TX action\n\nIn the XDP_TX path, ionic driver sends a packet to the TX path with rx\npage and corresponding dma address.\nAfter tx is done, ionic_tx_clean() frees that page.\nBut RX ring buffer isn't reset to NULL.\nSo, it uses a freed page, which causes kernel panic.\n\nBUG: unable to handle page fault for address: ffff8881576c110c\nPGD 773801067 P4D 773801067 PUD 87f086067 PMD 87efca067 PTE 800ffffea893e060\nOops: Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI\nCPU: 1 PID: 25 Comm: ksoftirqd/1 Not tainted 6.9.0+ #11\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nRIP: 0010:bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f\nCode: 00 53 41 55 41 56 41 57 b8 01 00 00 00 48 8b 5f 08 4c 8b 77 00 4c 89 f7 48 83 c7 0e 48 39 d8\nRSP: 0018:ffff888104e6fa28 EFLAGS: 00010283\nRAX: 0000000000000002 RBX: ffff8881576c1140 RCX: 0000000000000002\nRDX: ffffffffc0051f64 RSI: ffffc90002d33048 RDI: ffff8881576c110e\nRBP: ffff888104e6fa88 R08: 0000000000000000 R09: ffffed1027a04a23\nR10: 0000000000000000 R11: 0000000000000000 R12: ffff8881b03a21a8\nR13: ffff8881589f800f R14: ffff8881576c1100 R15: 00000001576c1100\nFS: 0000000000000000(0000) GS:ffff88881ae00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff8881576c110c CR3: 0000000767a90000 CR4: 00000000007506f0\nPKRU: 55555554\nCall Trace:\n\n? __die+0x20/0x70\n? page_fault_oops+0x254/0x790\n? __pfx_page_fault_oops+0x10/0x10\n? __pfx_is_prefetch.constprop.0+0x10/0x10\n? search_bpf_extables+0x165/0x260\n? fixup_exception+0x4a/0x970\n? exc_page_fault+0xcb/0xe0\n? asm_exc_page_fault+0x22/0x30\n? 0xffffffffc0051f64\n? bpf_prog_f0b8caeac1068a55_balancer_ingress+0x3b/0x44f\n? do_raw_spin_unlock+0x54/0x220\nionic_rx_service+0x11ab/0x3010 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]\n? ionic_tx_clean+0x29b/0xc60 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]\n? __pfx_ionic_tx_clean+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]\n? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]\n? ionic_tx_cq_service+0x25d/0xa00 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]\n? __pfx_ionic_rx_service+0x10/0x10 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]\nionic_cq_service+0x69/0x150 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]\nionic_txrx_napi+0x11a/0x540 [ionic 9180c3001ab627d82bbc5f3ebe8a0decaf6bb864]\n__napi_poll.constprop.0+0xa0/0x440\nnet_rx_action+0x7e7/0xc30\n? __pfx_net_rx_action+0x10/0x10

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Always stop health timer during driver removal\n\nCurrently, if teardown_hca fails to execute during driver removal, mlx5\ndoes not stop the health timer. Afterwards, mlx5 continue with driver\nteardown. This may lead to a UAF bug, which results in page fault\nOops[1], since the health timer invokes after resources were freed.\n\nHence, stop the health monitor even if teardown_hca fails.\n\n[1]\nmlx5_core 0000:18:00.0: E-Switch: Unload vfs: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\nmlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\nmlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\nmlx5_core 0000:18:00.0: E-Switch: cleanup\nmlx5_core 0000:18:00.0: wait_func:1155:(pid 1967079): TEARDOWN_HCA(0x103) timeout. Will cause a leak of a command resource\nmlx5_core 0000:18:00.0: mlx5_function_close:1288:(pid 1967079): tear_down_hca failed, skip cleanup\nBUG: unable to handle page fault for address: ffffa26487064230\nPGD 100c00067 P4D 100c00067 PUD 100e5a067 PMD 105ed7067 PTE 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE ------- --- 6.7.0-68.fc38.x86_64 #1\nHardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020\nRIP: 0010:ioread32be+0x34/0x60\nRSP: 0018:ffffa26480003e58 EFLAGS: 00010292\nRAX: ffffa26487064200 RBX: ffff9042d08161a0 RCX: ffff904c108222c0\nRDX: 000000010bbf1b80 RSI: ffffffffc055ddb0 RDI: ffffa26487064230\nRBP: ffff9042d08161a0 R08: 0000000000000022 R09: ffff904c108222e8\nR10: 0000000000000004 R11: 0000000000000441 R12: ffffffffc055ddb0\nR13: ffffa26487064200 R14: ffffa26480003f00 R15: ffff904c108222c0\nFS: 0000000000000000(0000) GS:ffff904c10800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffa26487064230 CR3: 00000002c4420006 CR4: 00000000007706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \n ? __die+0x23/0x70\n ? page_fault_oops+0x171/0x4e0\n ? exc_page_fault+0x175/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n ? ioread32be+0x34/0x60\n mlx5_health_check_fatal_sensors+0x20/0x100 [mlx5_core]\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n poll_health+0x42/0x230 [mlx5_core]\n ? __next_timer_interrupt+0xbc/0x110\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n call_timer_fn+0x21/0x130\n ? __pfx_poll_health+0x10/0x10 [mlx5_core]\n __run_timers+0x222/0x2c0\n run_timer_softirq+0x1d/0x40\n __do_softirq+0xc9/0x2c8\n __irq_exit_rcu+0xa6/0xc0\n sysvec_apic_timer_interrupt+0x72/0x90\n \n \n asm_sysvec_apic_timer_interrupt+0x1a/0x20\nRIP: 0010:cpuidle_enter_state+0xcc/0x440\n ? cpuidle_enter_state+0xbd/0x440\n cpuidle_enter+0x2d/0x40\n do_idle+0x20d/0x270\n cpu_startup_entry+0x2a/0x30\n rest_init+0xd0/0xd0\n arch_call_rest_init+0xe/0x30\n start_kernel+0x709/0xa90\n x86_64_start_reservations+0x18/0x30\n x86_64_start_kernel+0x96/0xa0\n secondary_startup_64_no_verify+0x18f/0x19b\n---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps\n\nThere could be a potential use-after-free case in\ntcpm_register_source_caps(). This could happen when:\n * new (say invalid) source caps are advertised\n * the existing source caps are unregistered\n * tcpm_register_source_caps() returns with an error as\n usb_power_delivery_register_capabilities() fails\n\nThis causes port->partner_source_caps to hold on to the now freed source\ncaps.\n\nReset port->partner_source_caps value to NULL after unregistering\nexisting source caps.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/io-wq: Use set_bit() and test_bit() at worker->flags\n\nUtilize set_bit() and test_bit() on worker->flags within io_uring/io-wq\nto address potential data races.\n\nThe structure io_worker->flags may be accessed through various data\npaths, leading to concurrency issues. When KCSAN is enabled, it reveals\ndata races occurring in io_worker_handle_work and\nio_wq_activate_free_worker functions.\n\n\t BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker\n\t write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:\n\t io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)\n\t io_wq_worker (io_uring/io-wq.c:?)\n\n\n\t read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:\n\t io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)\n\t io_wq_enqueue (io_uring/io-wq.c:947)\n\t io_queue_iowq (io_uring/io_uring.c:524)\n\t io_req_task_submit (io_uring/io_uring.c:1511)\n\t io_handle_tw_list (io_uring/io_uring.c:1198)\n\n\nLine numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of\ngit://git.kernel.org/pub/scm/virt/kvm/kvm").\n\nThese races involve writes and reads to the same memory location by\ndifferent tasks running on different CPUs. To mitigate this, refactor\nthe code to use atomic operations such as set_bit(), test_bit(), and\nclear_bit() instead of basic "and" and "or" operations. This ensures\nthread-safe manipulation of worker flags.\n\nAlso, move `create_index` to avoid holes in the structure.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash problem in concurrent scenario\n\nWhen link status change, the nic driver need to notify the roce\ndriver to handle this event, but at this time, the roce driver\nmay uninit, then cause kernel crash.\n\nTo fix the problem, when link status change, need to check\nwhether the roce registered, and when uninit, need to wait link\nupdate finish.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_inner: validate mandatory meta and payload\n\nCheck for mandatory netlink attributes in payload and meta expression\nwhen used embedded from the inner expression, otherwise NULL pointer\ndereference is possible from userspace.

In the Linux kernel, the following vulnerability has been resolved:\n\nsock_map: avoid race between sock_map_close and sk_psock_put\n\nsk_psock_get will return NULL if the refcount of psock has gone to 0, which\nwill happen when the last call of sk_psock_put is done. However,\nsk_psock_drop may not have finished yet, so the close callback will still\npoint to sock_map_close despite psock being NULL.\n\nThis can be reproduced with a thread deleting an element from the sock map,\nwhile the second one creates a socket, adds it to the map and closes it.\n\nThat will trigger the WARN_ON_ONCE:\n\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nModules linked in:\nCPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nCode: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02\nRSP: 0018:ffffc9000441fda8 EFLAGS: 00010293\nRAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000\nRDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0\nRBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3\nR10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840\nR13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870\nFS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0\nCall Trace:\n \n unix_release+0x87/0xc0 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0xbe/0x240 net/socket.c:1421\n __fput+0x42b/0x8a0 fs/file_table.c:422\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close fs/open.c:1541 [inline]\n __x64_sys_close+0x7f/0x110 fs/open.c:1541\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fb37d618070\nCode: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c\nRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003\nRAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070\nRDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n \n\nUse sk_psock, which will only check that the pointer is not been set to\nNULL yet, which should only happen after the callbacks are restored. If,\nthen, a reference can still be gotten, we may call sk_psock_stop and cancel\npsock->work.\n\nAs suggested by Paolo Abeni, reorder the condition so the control flow is\nless convoluted.\n\nAfter that change, the reproducer does not trigger the WARN_ON_ONCE\nanymore.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)\n\nLack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap\nallows users to call mmap with PROT_WRITE and MAP_PRIVATE flag\ncausing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:\nBUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags));\n\nReturn -EINVAL early if COW mapping is detected.\n\nThis bug affects all drm drivers using default shmem helpers.\nIt can be reproduced by this simple example:\nvoid *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);\nptr[0] = 0;

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: fix use-after-free due to race with dev replace\n\nWhile loading a zone's info during creation of a block group, we can race\nwith a device replace operation and then trigger a use-after-free on the\ndevice that was just replaced (source device of the replace operation).\n\nThis happens because at btrfs_load_zone_info() we extract a device from\nthe chunk map into a local variable and then use the device while not\nunder the protection of the device replace rwsem. So if there's a device\nreplace operation happening when we extract the device and that device\nis the source of the replace operation, we will trigger a use-after-free\nif before we finish using the device the replace operation finishes and\nfrees the device.\n\nFix this by enlarging the critical section under the protection of the\ndevice replace rwsem so that all uses of the device are done inside the\ncritical section.

In the Linux kernel, the following vulnerability has been resolved:\n\nima: Fix use-after-free on a dentry's dname.name\n\n->d_name.name can change on rename and the earlier value can be freed;\nthere are conditions sufficient to stabilize it (->d_lock on dentry,\n->d_lock on its parent, ->i_rwsem exclusive on the parent's inode,\nrename_lock), but none of those are met at any of the sites. Take a stable\nsnapshot of the name instead.

In the Linux kernel, the following vulnerability has been resolved:\n\nmailbox: mtk-cmdq: Fix pm_runtime_get_sync() warning in mbox shutdown\n\nThe return value of pm_runtime_get_sync() in cmdq_mbox_shutdown()\nwill return 1 when pm runtime state is active, and we don't want to\nget the warning message in this case.\n\nSo we change the return value < 0 for WARN_ON().

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sr: fix missing sk_buff release in seg6_input_core\n\nThe seg6_input() function is responsible for adding the SRH into a\npacket, delegating the operation to the seg6_input_core(). This function\nuses the skb_cow_head() to ensure that there is sufficient headroom in\nthe sk_buff for accommodating the link-layer header.\nIn the event that the skb_cow_header() function fails, the\nseg6_input_core() catches the error but it does not release the sk_buff,\nwhich will result in a memory leak.\n\nThis issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due\nto headroom too small after SRH push") and persists even after commit\n7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"),\nwhere the entire seg6_input() code was refactored to deal with netfilter\nhooks.\n\nThe proposed patch addresses the identified memory leak by requiring the\nseg6_input_core() function to release the sk_buff in the event that\nskb_cow_head() fails.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_file: Fix pid refcounting race\n\n, Maxime Ripard\n, Thomas Zimmermann \n\nfilp->pid is supposed to be a refcounted pointer; however, before this\npatch, drm_file_update_pid() only increments the refcount of a struct\npid after storing a pointer to it in filp->pid and dropping the\ndev->filelist_mutex, making the following race possible:\n\nprocess A process B\n========= =========\n begin drm_file_update_pid\n mutex_lock(&dev->filelist_mutex)\n rcu_replace_pointer(filp->pid, , 1)\n mutex_unlock(&dev->filelist_mutex)\nbegin drm_file_update_pid\nmutex_lock(&dev->filelist_mutex)\nrcu_replace_pointer(filp->pid, , 1)\nmutex_unlock(&dev->filelist_mutex)\nget_pid()\nsynchronize_rcu()\nput_pid() *** pid B reaches refcount 0 and is freed here ***\n get_pid() *** UAF ***\n synchronize_rcu()\n put_pid()\n\nAs far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y\nbecause it requires RCU to detect a quiescent state in code that is not\nexplicitly calling into the scheduler.\n\nThis race leads to use-after-free of a "struct pid".\nIt is probably somewhat hard to hit because process A has to pass\nthrough a synchronize_rcu() operation while process B is between\nmutex_unlock() and get_pid().\n\nFix it by ensuring that by the time a pointer to the current task's pid\nis stored in the file, an extra reference to the pid has been taken.\n\nThis fix also removes the condition for synchronize_rcu(); I think\nthat optimization is unnecessary complexity, since in that case we\nwould usually have bailed out on the lockless check above.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l: async: Properly re-initialise notifier entry in unregister\n\nThe notifier_entry of a notifier is not re-initialised after unregistering\nthe notifier. This leads to dangling pointers being left there so use\nlist_del_init() to return the notifier_entry an empty list.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked\n\nWhen requesting an NMI window, WARN on vNMI support being enabled if and\nonly if NMIs are actually masked, i.e. if the vCPU is already handling an\nNMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of\nview) is to inject one NMI and pend the other. When using vNMI, KVM pends\nthe second NMI simply by setting V_NMI_PENDING, and lets the CPU do the\nrest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).\n\nHowever, if KVM can't immediately inject an NMI, e.g. because the vCPU is\nin an STI shadow or is running with GIF=0, then KVM will request an NMI\nwindow and trigger the WARN (but still function correctly).\n\nWhether or not the GIF=0 case makes sense is debatable, as the intent of\nKVM's behavior is to provide functionality that is as close to real\nhardware as possible. E.g. if two NMIs are sent in quick succession, the\nprobability of both NMIs arriving in an STI shadow is infinitesimally low\non real hardware, but significantly larger in a virtual environment, e.g.\nif the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't\nas clear cut, because the window where two NMIs can collide is much larger\nin bare metal (though still small).\n\nThat said, KVM should not have divergent behavior for the GIF=0 case based\non whether or not vNMI support is enabled. And KVM has allowed\nsimultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400\n("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be\nmodified without a *really* good reason to do so, and if KVM's behavior\nwere to be modified, it should be done irrespective of vNMI support.

In the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix variable length array abuse in btree_iter\n\nbtree_iter is used in two ways: either allocated on the stack with a\nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the\nspecific cache set. Previously, the struct had a fixed-length array of\nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized\niterators, which causes UBSAN to complain.\n\nThis patch uses the same approach as in bcachefs's sort_iter and splits\nthe iterator into a btree_iter with a flexible array member and a\nbtree_iter_stack which embeds a btree_iter as well as a fixed-length\ndata array.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mc: Fix graph walk in media_pipeline_start\n\nThe graph walk tries to follow all links, even if they are not between\npads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link.\n\nFix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK\nlinks.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/hwmon: Get rid of devm\n\nWhen both hwmon and hwmon drvdata (on which hwmon depends) are device\nmanaged resources, the expectation, on device unbind, is that hwmon will be\nreleased before drvdata. However, in i915 there are two separate code\npaths, which both release either drvdata or hwmon and either can be\nreleased before the other. These code paths (for device unbind) are as\nfollows (see also the bug referenced below):\n\nCall Trace:\nrelease_nodes+0x11/0x70\ndevres_release_group+0xb2/0x110\ncomponent_unbind_all+0x8d/0xa0\ncomponent_del+0xa5/0x140\nintel_pxp_tee_component_fini+0x29/0x40 [i915]\nintel_pxp_fini+0x33/0x80 [i915]\ni915_driver_remove+0x4c/0x120 [i915]\ni915_pci_remove+0x19/0x30 [i915]\npci_device_remove+0x32/0xa0\ndevice_release_driver_internal+0x19c/0x200\nunbind_store+0x9c/0xb0\n\nand\n\nCall Trace:\nrelease_nodes+0x11/0x70\ndevres_release_all+0x8a/0xc0\ndevice_unbind_cleanup+0x9/0x70\ndevice_release_driver_internal+0x1c1/0x200\nunbind_store+0x9c/0xb0\n\nThis means that in i915, if use devm, we cannot gurantee that hwmon will\nalways be released before drvdata. Which means that we have a uaf if hwmon\nsysfs is accessed when drvdata has been released but hwmon hasn't.\n\nThe only way out of this seems to be do get rid of devm_ and release/free\neverything explicitly during device unbind.\n\nv2: Change commit message and other minor code changes\nv3: Cleanup from i915_hwmon_register on error (Armin Wolf)\nv4: Eliminate potential static analyzer warning (Rodrigo)\n Eliminate fetch_and_zero (Jani)\nv5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: do not call vma_add_reservation upon ENOMEM\n\nsysbot reported a splat [1] on __unmap_hugepage_range(). This is because\nvma_needs_reservation() can return -ENOMEM if\nallocate_file_region_entries() fails to allocate the file_region struct\nfor the reservation.\n\nCheck for that and do not call vma_add_reservation() if that is the case,\notherwise region_abort() and region_del() will see that we do not have any\nfile_regions.\n\nIf we detect that vma_needs_reservation() returned -ENOMEM, we clear the\nhugetlb_restore_reserve flag as if this reservation was still consumed, so\nfree_huge_folio() will not increment the resv count.\n\n[1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension\n\nIf a process module does not have base config extension then the same\nformat applies to all of it's inputs and the process->base_config_ext is\nNULL, causing NULL dereference when specifically crafted topology and\nsequences used.

In the Linux kernel, the following vulnerability has been resolved:\n\neventfs: Fix a possible null pointer dereference in eventfs_find_events()\n\nIn function eventfs_find_events,there is a potential null pointer\nthat may be caused by calling update_events_attr which will perform\nsome operations on the members of the ei struct when ei is NULL.\n\nHence,When ei->is_freed is set,return NULL directly.

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/drivers/qcom/lmh: Check for SCM availability at probe\n\nUp until now, the necessary scm availability check has not been\nperformed, leading to possible null pointer dereferences (which did\nhappen for me on RB1).\n\nFix that.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mgb4: Fix double debugfs remove\n\nFixes an error where debugfs_remove_recursive() is called first on a parent\ndirectory and then again on a child which causes a kernel panic.\n\n[hverkuil: added Fixes/Cc tags]

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l: async: Fix notifier list entry init\n\nstruct v4l2_async_notifier has several list_head members, but only\nwaiting_list and done_list are initialized. notifier_entry was kept\n'zeroed' leading to an uninitialized list_head.\nThis results in a NULL-pointer dereference if csi2_async_register() fails,\ne.g. node for remote endpoint is disabled, and returns -ENOTCONN.\nThe following calls to v4l2_async_nf_unregister() results in a NULL\npointer dereference.\nAdd the missing list head initializer.

In the Linux kernel, the following vulnerability has been resolved:\n\n9p: add missing locking around taking dentry fid list\n\nFix a use-after-free on dentry's d_fsdata fid list when a thread\nlooks up a fid through dentry while another thread unlinks it:\n\nUAF thread:\nrefcount_t: addition on 0; use-after-free.\n p9_fid_get linux/./include/net/9p/client.h:262\n v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129\n v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181\n v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314\n v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400\n vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248\n\nFreed by:\n p9_fid_destroy (inlined)\n p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456\n p9_fid_put linux/./include/net/9p/client.h:278\n v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55\n v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518\n vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335\n\nThe problem is that d_fsdata was not accessed under d_lock, because\nd_release() normally is only called once the dentry is otherwise no\nlonger accessible but since we also call it explicitly in v9fs_remove\nthat lock is required:\nmove the hlist out of the dentry under lock then unref its fids once\nthey are no longer accessible.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: bcm: dvp: Assign ->num before accessing ->hws\n\nCommit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with\n__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'\nwith __counted_by, which informs the bounds sanitizer about the number\nof elements in hws, so that it can warn when hws is accessed out of\nbounds. As noted in that change, the __counted_by member must be\ninitialized with the number of elements before the first array access\nhappens, otherwise there will be a warning from each access prior to the\ninitialization because the number of elements is zero. This occurs in\nclk_dvp_probe() due to ->num being assigned after ->hws has been\naccessed:\n\n UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2\n index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')\n\nMove the ->num initialization to before the first access of ->hws, which\nclears up the warning.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: bcm: rpi: Assign ->num before accessing ->hws\n\nCommit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with\n__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'\nwith __counted_by, which informs the bounds sanitizer about the number\nof elements in hws, so that it can warn when hws is accessed out of\nbounds. As noted in that change, the __counted_by member must be\ninitialized with the number of elements before the first array access\nhappens, otherwise there will be a warning from each access prior to the\ninitialization because the number of elements is zero. This occurs in\nraspberrypi_discover_clocks() due to ->num being assigned after ->hws\nhas been accessed:\n\n UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4\n index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')\n\nMove the ->num initialization to before the first access of ->hws, which\nclears up the warning.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: check for non-NULL file pointer in io_file_can_poll()\n\nIn earlier kernels, it was possible to trigger a NULL pointer\ndereference off the forced async preparation path, if no file had\nbeen assigned. The trace leading to that looks as follows:\n\nBUG: kernel NULL pointer dereference, address: 00000000000000b0\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022\nRIP: 0010:io_buffer_select+0xc3/0x210\nCode: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b\nRSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246\nRAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040\nRDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700\nRBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020\nR10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8\nR13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000\nFS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0\nCall Trace:\n <TASK>\n ? __die+0x1f/0x60\n ? page_fault_oops+0x14d/0x420\n ? do_user_addr_fault+0x61/0x6a0\n ? exc_page_fault+0x6c/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? io_buffer_select+0xc3/0x210\n __io_import_iovec+0xb5/0x120\n io_readv_prep_async+0x36/0x70\n io_queue_sqe_fallback+0x20/0x260\n io_submit_sqes+0x314/0x630\n __do_sys_io_uring_enter+0x339/0xbc0\n ? __do_sys_io_uring_register+0x11b/0xc50\n ? vm_mmap_pgoff+0xce/0x160\n do_syscall_64+0x5f/0x180\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\nRIP: 0033:0x55e0a110a67e\nCode: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6\n\nbecause the request is marked forced ASYNC and has a bad file fd, and\nhence takes the forced async prep path.\n\nCurrent kernels with the request async prep cleaned up can no longer hit\nthis issue, but for ease of backporting, let's add this safety check in\nhere too as it really doesn't hurt. For both cases, this will inevitably\nend with a CQE posted with -EBADF.

In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix oops during rmmod\n\n"rmmod bonding" causes an oops ever since commit cc317ea3d927 ("bonding:\nremove redundant NULL check in debugfs function"). Here are the relevant\nfunctions being called:\n\nbonding_exit()\n bond_destroy_debugfs()\n debugfs_remove_recursive(bonding_debug_root);\n bonding_debug_root = NULL; <--------- SET TO NULL HERE\n bond_netlink_fini()\n rtnl_link_unregister()\n __rtnl_link_unregister()\n unregister_netdevice_many_notify()\n bond_uninit()\n bond_debug_unregister()\n (commit removed check for bonding_debug_root == NULL)\n debugfs_remove()\n simple_recursive_removal()\n down_write() -> OOPS\n\nHowever, reverting the bad commit does not solve the problem completely\nbecause the original code contains a race that could cause the same\noops, although it was much less likely to be triggered unintentionally:\n\nCPU1\n rmmod bonding\n bonding_exit()\n bond_destroy_debugfs()\n debugfs_remove_recursive(bonding_debug_root);\n\nCPU2\n echo -bond0 > /sys/class/net/bonding_masters\n bond_uninit()\n bond_debug_unregister()\n if (!bonding_debug_root)\n\nCPU1\n bonding_debug_root = NULL;\n\nSo do NOT revert the bad commit (since the removed checks were racy\nanyway), and instead change the order of actions taken during module\nremoval. The same oops can also happen if there is an error during\nmodule init, so apply the same fix there.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "xsk: Support redirect to any socket bound to the same umem"\n\nThis reverts commit 2863d665ea41282379f108e4da6c8a2366ba66db.\n\nThis patch introduced a potential kernel crash when multiple napi instances\nredirect to the same AF_XDP socket. By removing the queue_index check, it is\npossible for multiple napi instances to access the Rx ring at the same time,\nwhich will result in a corrupted ring state which can lead to a crash when\nflushing the rings in __xsk_flush(). This can happen when the linked list of\nsockets to flush gets corrupted by concurrent accesses. A quick and small fix\nis not possible, so let us revert this for now.

In the Linux kernel, the following vulnerability has been resolved:\n\ndma-mapping: benchmark: handle NUMA_NO_NODE correctly\n\ncpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark()\nresulting in the following sanitizer report:\n\nUBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28\nindex -1 is out of range for type 'cpumask [64][1]'\nCPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n <TASK>\ndump_stack_lvl (lib/dump_stack.c:117)\nubsan_epilogue (lib/ubsan.c:232)\n__ubsan_handle_out_of_bounds (lib/ubsan.c:429)\ncpumask_of_node (arch/x86/include/asm/topology.h:72) [inline]\ndo_map_benchmark (kernel/dma/map_benchmark.c:104)\nmap_benchmark_ioctl (kernel/dma/map_benchmark.c:246)\nfull_proxy_unlocked_ioctl (fs/debugfs/file.c:333)\n__x64_sys_ioctl (fs/ioctl.c:890)\ndo_syscall_64 (arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nUse cpumask_of_node() in place when binding a kernel thread to a cpuset\nof a particular node.\n\nNote that the provided node id is checked inside map_benchmark_ioctl().\nIt's just a NUMA_NO_NODE case which is not handled properly later.\n\nFound by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: prevent pt_regs corruption for secondary idle threads\n\nTop of the kernel thread stack should be reserved for pt_regs. However\nthis is not the case for the idle threads of the secondary boot harts.\nTheir stacks overlap with their pt_regs, so both may get corrupted.\n\nSimilar issue has been fixed for the primary hart, see c7cdd96eca28\n("riscv: prevent stack corruption by reserving task_pt_regs(p) early").\nHowever that fix was not propagated to the secondary harts. The problem\nhas been noticed in some CPU hotplug tests with V enabled. The function\nsmp_callin stored several registers on stack, corrupting top of pt_regs\nstructure including status field. As a result, kernel attempted to save\nor restore inexistent V context.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: zynqmp_dpsub: Always register bridge\n\nWe must always register the DRM bridge, since zynqmp_dp_hpd_work_func\ncalls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be\ninitialized. We do this before zynqmp_dpsub_drm_init since that calls\ndrm_bridge_attach. This fixes the following lockdep warning:\n\n[ 19.217084] ------------[ cut here ]------------\n[ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock)\n[ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550\n[ 19.241696] Modules linked in:\n[ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96\n[ 19.252046] Hardware name: xlnx,zynqmp (DT)\n[ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func\n[ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 19.269104] pc : __mutex_lock+0x4bc/0x550\n[ 19.273364] lr : __mutex_lock+0x4bc/0x550\n[ 19.277592] sp : ffffffc085c5bbe0\n[ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8\n[ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000\n[ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000\n[ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000\n[ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720\n[ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001\n[ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888\n[ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000\n[ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000\n[ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880\n[ 19.356581] Call trace:\n[ 19.359160] __mutex_lock+0x4bc/0x550\n[ 19.363032] mutex_lock_nested+0x24/0x30\n[ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c\n[ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54\n[ 19.376364] process_one_work+0x3ac/0x988\n[ 19.380660] worker_thread+0x398/0x694\n[ 19.384736] kthread+0x1bc/0x1c0\n[ 19.388241] ret_from_fork+0x10/0x20\n[ 19.392031] irq event stamp: 183\n[ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4\n[ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04\n[ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c\n[ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c\n[ 19.432614] ---[ end trace 0000000000000000 ]---\n\n(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)

In the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix list corruption from resetting io stat\n\nSince commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"),\neach iostat instance is added to blkcg percpu list, so blkcg_reset_stats()\ncan't reset the stat instance by memset(), otherwise the llist may be\ncorrupted.\n\nFix the issue by only resetting the counter part.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Allow delete from sockmap/sockhash only if update is allowed\n\nWe have seen an influx of syzkaller reports where a BPF program attached to\na tracepoint triggers a locking rule violation by performing a map_delete\non a sockmap/sockhash.\n\nWe don't intend to support this artificial use scenario. Extend the\nexisting verifier allowed-program-type check for updating sockmap/sockhash\nto also cover deleting from a map.\n\n>From now on only BPF programs which were previously allowed to update\nsockmap/sockhash can delete from these map types.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: multidev: fix to recognize valid zero block address\n\nAs reported by Yi Zhang in mailing list [1], kernel warning was catched\nduring zbd/010 test as below:\n\n./check zbd/010\nzbd/010 (test gap zone support with F2FS) [failed]\n runtime ... 3.752s\n something found in dmesg:\n [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13\n [ 4378.192349] null_blk: module loaded\n [ 4378.209860] null_blk: disk nullb0 created\n [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim\npoll_queues to 0. poll_q/nr_hw = (0/1)\n [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]\n dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0\n [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux\nscsi_debug 0191 PQ: 0 ANSI: 7\n [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred\n [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20\n [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device\n ...\n (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg'\n\nWARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51\nCPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1\nRIP: 0010:iomap_iter+0x32b/0x350\nCall Trace:\n <TASK>\n __iomap_dio_rw+0x1df/0x830\n f2fs_file_read_iter+0x156/0x3d0 [f2fs]\n aio_read+0x138/0x210\n io_submit_one+0x188/0x8c0\n __x64_sys_io_submit+0x8c/0x1a0\n do_syscall_64+0x86/0x170\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nShinichiro Kawasaki helps to analyse this issue and proposes a potential\nfixing patch in [2].\n\nQuoted from reply of Shinichiro Kawasaki:\n\n"I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a\nlook in the commit, but it looks fine to me. So I thought the cause is not\nin the commit diff.\n\nI found the WARN is printed when the f2fs is set up with multiple devices,\nand read requests are mapped to the very first block of the second device in the\ndirect read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()\nmodify map->m_pblk as the physical block address from each block device. It\nbecomes zero when it is mapped to the first block of the device. However,\nf2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the\nwhole f2fs, across the all block devices. It compares map->m_pblk against\nNULL_ADDR == 0, then go into the unexpected branch and sets the invalid\niomap->length. The WARN catches the invalid iomap->length.\n\nThis WARN is printed even for non-zoned block devices, by following steps.\n\n - Create two (non-zoned) null_blk devices memory backed with 128MB size each:\n nullb0 and nullb1.\n # mkfs.f2fs /dev/nullb0 -c /dev/nullb1\n # mount -t f2fs /dev/nullb0 "${mount_dir}"\n # dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192\n # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct\n\n..."\n\nSo, the root cause of this issue is: when multi-devices feature is on,\nf2fs_map_blocks() may return zero blkaddr in non-primary device, which is\na verified valid block address, however, f2fs_iomap_begin() treats it as\nan invalid block address, and then it triggers the warning in iomap\nframework code.\n\nFinally, as discussed, we decide to use a more simple and direct way that\nchecking (map.m_flags & F2FS_MAP_MAPPED) condition instead of\n(map.m_pblk != NULL_ADDR) to fix this issue.\n\nThanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this\nissue.\n\n[1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/\n[2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/

In the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: fix potential memory leak in vfio_intx_enable()\n\nIf vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: PAC1934: fix accessing out of bounds array index\n\nFix accessing out of bounds array index for average\ncurrent and voltage measurements. The device itself has\nonly 4 channels, but in sysfs there are "fake"\nchannels for the average voltages and currents too.

In the Linux kernel, the following vulnerability has been resolved:\n\nwatchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger\n\nWhen the cpu5wdt module is removing, the origin code uses del_timer() to\nde-activate the timer. If the timer handler is running, del_timer() could\nnot stop it and will return directly. If the port region is released by\nrelease_region() and then the timer handler cpu5wdt_trigger() calls outb()\nto write into the region that is released, the use-after-free bug will\nhappen.\n\nChange del_timer() to timer_shutdown_sync() in order that the timer handler\ncould be finished before the port region is released.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Avoid unnecessary destruction of file_ida\n\nfile_ida is allocated during cdev open and is freed accordingly\nduring cdev release. This sequence is guaranteed by driver file\noperations. Therefore, there is no need to destroy an already empty\nfile_ida when the WQ cdev is removed.\n\nWorse, ida_free() in cdev release may happen after destruction of\nfile_ida per WQ cdev. This can lead to accessing an id in file_ida\nafter it has been destroyed, resulting in a kernel panic.\n\nRemove ida_destroy(&file_ida) to address these issues.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.\n\nHang on to the control IDs instead of pointers since those are correctly\nhandled with locks.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Check 'folio' pointer for NULL\n\nIt can be NULL if bmap is called.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Use 64 bit variable to avoid 32 bit overflow\n\nFor example, in the expression:\n vbo = 2 * vbo + skip

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Use variable length array instead of fixed size\n\nShould fix smatch warning:\n ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dpu: Add callback function pointer check before its call\n\nIn dpu_core_irq_callback_handler() callback function pointer is compared to NULL,\nbut then callback function is unconditionally called by this pointer.\nFix this bug by adding conditional return.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\nPatchwork: https://patchwork.freedesktop.org/patch/588237/

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: HCI: Remove HCI_AMP support\n\nSince BT_HS has been remove HCI_AMP controllers no longer has any use so\nremove it along with the capability of creating AMP controllers.\n\nSince we no longer need to differentiate between AMP and Primary\ncontrollers, as only HCI_PRIMARY is left, this also remove\nhdev->dev_type altogether.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()\n\nIn the prueth_probe() function, if one of the calls to emac_phy_connect()\nfails due to of_phy_connect() returning NULL, then the subsequent call to\nphy_attached_info() will dereference a NULL pointer.\n\nCheck the return code of emac_phy_connect and fail cleanly if there is an\nerror.

In the Linux kernel, the following vulnerability has been resolved:\n\nlibbpf: Prevent null-pointer dereference when prog to load has no BTF\n\nIn bpf_objec_load_prog(), there's no guarantee that obj->btf is non-NULL\nwhen passing it to btf__fd(), and this function does not perform any\ncheck before dereferencing its argument (as bpf_object__btf_fd() used to\ndo). As a consequence, we get segmentation fault errors in bpftool (for\nexample) when trying to load programs that come without BTF information.\n\nv2: Keep btf__fd() in the fix instead of reverting to bpf_object__btf_fd().

In the Linux kernel, the following vulnerability has been resolved:\n\nof: module: add buffer overflow check in of_modalias()\n\nIn of_modalias(), if the buffer happens to be too small even for the 1st\nsnprintf() call, the len parameter will become negative and str parameter\n(if not NULL initially) will point beyond the buffer's end. Add the buffer\noverflow check after the 1st snprintf() call and fix such check after the\nstrlen() call (accounting for the terminating NUL char).

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda/cs_dsp_ctl: Use private_free for control cleanup\n\nUse the control private_free callback to free the associated data\nblock. This ensures that the memory won't leak, whatever way the\ncontrol gets destroyed.\n\nThe original implementation didn't actually remove the ALSA\ncontrols in hda_cs_dsp_control_remove(). It only freed the internal\ntracking structure. This meant it was possible to remove/unload the\namp driver while leaving its ALSA controls still present in the\nsoundcard. Obviously attempting to access them could cause segfaults\nor at least dereferencing stale pointers.

In the Linux kernel, the following vulnerability has been resolved:\n\ngenirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()\n\nirq_find_at_or_after() dereferences the interrupt descriptor which is\nreturned by mt_find() while neither holding sparse_irq_lock nor RCU read\nlock, which means the descriptor can be freed between mt_find() and the\ndereference:\n\n CPU0 CPU1\n desc = mt_find()\n delayed_free_desc(desc)\n irq_desc_get_irq(desc)\n\nThe use-after-free is reported by KASAN:\n\n Call trace:\n irq_get_next_irq+0x58/0x84\n show_stat+0x638/0x824\n seq_read_iter+0x158/0x4ec\n proc_reg_read_iter+0x94/0x12c\n vfs_read+0x1e0/0x2c8\n\n Freed by task 4471:\n slab_free_freelist_hook+0x174/0x1e0\n __kmem_cache_free+0xa4/0x1dc\n kfree+0x64/0x128\n irq_kobj_release+0x28/0x3c\n kobject_put+0xcc/0x1e0\n delayed_free_desc+0x14/0x2c\n rcu_do_batch+0x214/0x720\n\nGuard the access with a RCU read lock section.

In the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix list corruption from reorder of WRITE ->lqueued\n\n__blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start\nis being executed.\n\nIf WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in\nthe loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one\nstat instance being added in blk_cgroup_bio_start(), then the local\nlist in __blkcg_rstat_flush() could be corrupted.\n\nFix the issue by adding one barrier.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix crash on racing fsync and size-extending write into prealloc\n\nWe have been seeing crashes on duplicate keys in\nbtrfs_set_item_key_safe():\n\n BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\n ------------[ cut here ]------------\n kernel BUG at fs/btrfs/ctree.c:2620!\n invalid opcode: 0000 [#1] PREEMPT SMP PTI\n CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\n\nWith the following stack trace:\n\n #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\n #1 btrfs_drop_extents (fs/btrfs/file.c:411:4)\n #2 log_one_extent (fs/btrfs/tree-log.c:4732:9)\n #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\n #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\n #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\n #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\n #7 btrfs_sync_file (fs/btrfs/file.c:1933:8)\n #8 vfs_fsync_range (fs/sync.c:188:9)\n #9 vfs_fsync (fs/sync.c:202:9)\n #10 do_fsync (fs/sync.c:212:9)\n #11 __do_sys_fdatasync (fs/sync.c:225:9)\n #12 __se_sys_fdatasync (fs/sync.c:223:1)\n #13 __x64_sys_fdatasync (fs/sync.c:223:1)\n #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\n #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\n #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\n\nSo we're logging a changed extent from fsync, which is splitting an\nextent in the log tree. But this split part already exists in the tree,\ntriggering the BUG().\n\nThis is the state of the log tree at the time of the crash, dumped with\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\nto get more details than btrfs_print_leaf() gives us:\n\n >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"])\n leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\n leaf 33439744 flags 0x100000000000000\n fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\n generation 7 transid 9 size 8192 nbytes 8473563889606862198\n block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n sequence 204 flags 0x10(PREALLOC)\n atime 1716417703.220000000 (2024-05-22 15:41:43)\n ctime 1716417704.983333333 (2024-05-22 15:41:44)\n mtime 1716417704.983333333 (2024-05-22 15:41:44)\n otime 17592186044416.000000000 (559444-03-08 01:40:16)\n item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\n index 195 namelen 3 name: 193\n item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\n location key (0 UNKNOWN.0 0) type XATTR\n transid 7 data_len 1 name_len 6\n name: user.a\n data a\n item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\n generation 9 type 1 (regular)\n extent data disk byte 303144960 nr 12288\n extent data offset 0 nr 4096 ram 12288\n extent compression 0 (none)\n item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\n generation 9 type 2 (prealloc)\n prealloc data disk byte 303144960 nr 12288\n prealloc data offset 4096 nr 8192\n item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\n generation 9 type 2 (prealloc)\n prealloc data disk byte 303144960 nr 12288\n prealloc data offset 8192 nr 4096\n ...\n\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\nitem 5 starts at i_size.\n\nHere is the state of the filesystem tree at the time of the crash:\n\n >>> root = prog.crashed_thread().stack_trace()[2]["inode"].root\n >>> ret, nodes, slots = btrfs_search_slot(root, BtrfsKey(450, 0, 0))\n >>> print_extent_buffer(nodes[0])\n leaf 30425088 level 0 items 184 generation 9 owner 5\n leaf 30425088 flags 0x100000000000000\n fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n ...\n item 179 key (450 INODE_ITEM 0) itemoff 4907 itemsize 160\n generation 7 transid 7 size 4096 nbytes 12288\n block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n sequence 6 flags 0x10(PREALLOC)\n atime 1716417703.220000000 (2024-05-22 15:41:43)\n ctime 1716417703.220000000 (2024-05-22 15:41:43)\n mtime 1716417703.220000000 (2024-05-22 15:41:43)\n otime 1716417703.220000000 (2024-05-22 15:41:43)\n item 180 key (450 INODE_REF 256) itemoff 4894 itemsize 13\n index 195 namelen 3 name: 193\n item 181 key (450 XATTR_ITEM 1640047104) itemoff 4857 itemsize 37\n location key (0 UNKNOWN.0 0) type XATTR\n transid 7 data_len 1 name_len 6\n name: user.a\n data a\n item 182 key (450 EXTENT_DATA 0) itemoff 4804 itemsize 53\n generation 9 type 1 (regular)\n extent data disk byte 303144960 nr 12288\n extent data offset 0 nr 8192 ram 12288\n extent compression 0 (none)\n item 183 key (450 EXTENT_DATA 8192) itemoff 4751 itemsize 53\n generation 9 type 2 (prealloc)\n prealloc data disk byte 303144960 nr 12288\n prealloc data offset 8192 nr 4096\n\nItem 5 in the log tree corresponds to item 183 in the filesystem tree,\nbut nothing matches item 4. Furthermore, item 183 is the last item in\nthe leaf.\n\nbtrfs_log_prealloc_extents() is responsible for logging prealloc extents\nbeyond i_size. It first truncates any previously logged prealloc extents\nthat start beyond i_size. Then, it walks the filesystem tree and copies\nthe prealloc extent items to the log tree.\n\nIf it hits the end of a leaf, then it calls btrfs_next_leaf(), which\nunlocks the tree and does another search. However, while the filesystem\ntree is unlocked, an ordered extent completion may modify the tree. In\nparticular, it may insert an extent item that overlaps with an extent\nitem that was already copied to the log tree.\n\nThis may manifest in several ways depending on the exact scenario,\nincluding an EEXIST error that is silently translated to a full sync,\noverlapping items in the log tree, or this crash. This particular crash\nis triggered by the following sequence of events:\n\n- Initially, the file has i_size=4k, a regular extent from 0-4k, and a\n prealloc extent beyond i_size from 4k-12k. The prealloc extent item is\n the last item in its B-tree leaf.\n- The file is fsync'd, which copies its inode item and both extent items\n to the log tree.\n- An xattr is set on the file, which sets the\n BTRFS_INODE_COPY_EVERYTHING flag.\n- The range 4k-8k in the file is written using direct I/O. i_size is\n extended to 8k, but the ordered extent is still in flight.\n- The file is fsync'd. Since BTRFS_INODE_COPY_EVERYTHING is set, this\n calls copy_inode_items_to_log(), which calls\n btrfs_log_prealloc_extents().\n- btrfs_log_prealloc_extents() finds the 4k-12k prealloc extent in the\n filesystem tree. Since it starts before i_size, it skips it. Since it\n is the last item in its B-tree leaf, it calls btrfs_next_leaf().\n- btrfs_next_leaf() unlocks the path.\n- The ordered extent completion runs, which converts the 4k-8k part of\n the prealloc extent to written and inserts the remaining prealloc part\n from 8k-12k.\n- btrfs_next_leaf() does a search and finds the new prealloc extent\n 8k-12k.\n- btrfs_log_prealloc_extents() copies the 8k-12k prealloc extent into\n the log tree. Note that it overlaps with the 4k-12k prealloc extent\n that was copied to the log tree by the first fsync.\n- fsync calls btrfs_log_changed_extents(), which tries to log the 4k-8k\n extent that was written.\n- This tries to drop the range 4k-8k in the log tree, which requires\n adjusting the start of the 4k-12k prealloc extent in the log tree to\n 8k.\n- btrfs_set_item_key_safe() sees that there is already an extent\n starting at 8k in the log tree and calls BUG().\n\nFix this by detecting when we're about to insert an overlapping file\nextent item in the log tree and truncating the part that would overlap.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Only use reserved BCS instances for usm migrate exec queue\n\nThe GuC context scheduling queue is 2 entires deep, thus it is possible\nfor a migration job to be stuck behind a fault if migration exec queue\nshares engines with user jobs. This can deadlock as the migrate exec\nqueue is required to service page faults. Avoid deadlock by only using\nreserved BCS instances for usm migrate exec queue.\n\n(cherry picked from commit 04f4a70a183a688a60fe3882d6e4236ea02cfc67)

In the Linux kernel, the following vulnerability has been resolved:\n\nfpga: manager: add owner module and take its refcount\n\nThe current implementation of the fpga manager assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module's refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the manager if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_manager\nstruct and use it to take the module's refcount. Modify the functions for\nregistering the manager to take an additional owner module parameter and\nrename them to avoid conflicts. Use the old function names for helper\nmacros that automatically set the module that registers the manager as the\nowner. This ensures compatibility with existing low-level control modules\nand reduces the chances of registering a manager without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga manager.\n\nOther changes: opportunistically move put_device() from __fpga_mgr_get() to\nfpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the\nmanager device is taken in these functions.

In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: mediatek: Make sure IPI buffer fits in L2TCM\n\nThe IPI buffer location is read from the firmware that we load to the\nSystem Companion Processor, and it's not granted that both the SRAM\n(L2TCM) size that is defined in the devicetree node is large enough\nfor that, and while this is especially true for multi-core SCP, it's\nstill useful to check on single-core variants as well.\n\nFailing to perform this check may make this driver perform R/W\noperations out of the L2TCM boundary, resulting (at best) in a\nkernel panic.\n\nTo fix that, check that the IPI buffer fits, otherwise return a\nfailure and refuse to boot the relevant SCP core (or the SCP at\nall, if this is single core).

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()\n\nThe documentation for device_get_named_child_node() mentions this\nimportant point:\n\n"\nThe caller is responsible for calling fwnode_handle_put() on the\nreturned fwnode pointer.\n"\n\nAdd fwnode_handle_put() to avoid a leaked reference.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue\n\nFix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which\nsyzbot reported [1].\n\n[1]\nBUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue\n\nwrite to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:\n sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]\n sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843\n sk_psock_put include/linux/skmsg.h:459 [inline]\n sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648\n unix_release+0x4b/0x80 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0x68/0x150 net/socket.c:1421\n __fput+0x2c1/0x660 fs/file_table.c:422\n __fput_sync+0x44/0x60 fs/file_table.c:507\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close+0x101/0x1b0 fs/open.c:1541\n __x64_sys_close+0x1f/0x30 fs/open.c:1541\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nread to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:\n sk_psock_data_ready include/linux/skmsg.h:464 [inline]\n sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555\n sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606\n sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]\n sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202\n unix_read_skb net/unix/af_unix.c:2546 [inline]\n unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682\n sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223\n unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x140/0x180 net/socket.c:745\n ____sys_sendmsg+0x312/0x410 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x1e9/0x280 net/socket.c:2667\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nvalue changed: 0xffffffff83d7feb0 -> 0x0000000000000000\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\n\nPrior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer\ndereference in sk_psock_verdict_data_ready()") fixed one NULL pointer\nsimilarly due to no protection of saved_data_ready. Here is another\ndifferent caller causing the same issue because of the same reason. So\nwe should protect it with sk_callback_lock read lock because the writer\nside in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);".\n\nTo avoid errors that could happen in future, I move those two pairs of\nlock into the sk_psock_data_ready(), which is suggested by John Fastabend.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: LPAR panics during boot up with a frozen PE\n\nAt the time of LPAR boot up, partition firmware provides Open Firmware\nproperty ibm,dma-window for the PE. This property is provided on the PCI\nbus the PE is attached to.\n\nThere are execptions where the partition firmware might not provide this\nproperty for the PE at the time of LPAR boot up. One of the scenario is\nwhere the firmware has frozen the PE due to some error condition. This\nPE is frozen for 24 hours or unless the whole system is reinitialized.\n\nWithin this time frame, if the LPAR is booted, the frozen PE will be\npresented to the LPAR but ibm,dma-window property could be missing.\n\nToday, under these circumstances, the LPAR oopses with NULL pointer\ndereference, when configuring the PCI bus the PE is attached to.\n\n BUG: Kernel NULL pointer dereference on read at 0x000000c8\n Faulting instruction address: 0xc0000000001024c0\n Oops: Kernel access of bad area, sig: 7 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n Modules linked in:\n Supported: Yes\n CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-150600.9-default #1\n Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_023) hv:phyp pSeries\n NIP: c0000000001024c0 LR: c0000000001024b0 CTR: c000000000102450\n REGS: c0000000037db5c0 TRAP: 0300 Not tainted (6.4.0-150600.9-default)\n MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28000822 XER: 00000000\n CFAR: c00000000010254c DAR: 00000000000000c8 DSISR: 00080000 IRQMASK: 0\n ...\n NIP [c0000000001024c0] pci_dma_bus_setup_pSeriesLP+0x70/0x2a0\n LR [c0000000001024b0] pci_dma_bus_setup_pSeriesLP+0x60/0x2a0\n Call Trace:\n pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 (unreliable)\n pcibios_setup_bus_self+0x1c0/0x370\n __of_scan_bus+0x2f8/0x330\n pcibios_scan_phb+0x280/0x3d0\n pcibios_init+0x88/0x12c\n do_one_initcall+0x60/0x320\n kernel_init_freeable+0x344/0x3e4\n kernel_init+0x34/0x1d0\n ret_from_kernel_user_thread+0x14/0x1c

In the Linux kernel, the following vulnerability has been resolved:\n\nuio_hv_generic: Don't free decrypted memory\n\nIn CoCo VMs it is possible for the untrusted host to cause\nset_memory_encrypted() or set_memory_decrypted() to fail such that an\nerror is returned and the resulting memory is shared. Callers need to\ntake care to handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional or security\nissues.\n\nThe VMBus device UIO driver could free decrypted/shared pages if\nset_memory_decrypted() fails. Check the decrypted field in the gpadl\nto decide whether to free the memory.

In the Linux kernel, the following vulnerability has been resolved:\n\nblk-iocost: do not WARN if iocg was already offlined\n\nIn iocg_pay_debt(), warn is triggered if 'active_list' is empty, which\nis intended to confirm iocg is active when it has debt. However, warn\ncan be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()\nis run at that time:\n\n WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190\n Call trace:\n iocg_pay_debt+0x14c/0x190\n iocg_kick_waitq+0x438/0x4c0\n iocg_waitq_timer_fn+0xd8/0x130\n __run_hrtimer+0x144/0x45c\n __hrtimer_run_queues+0x16c/0x244\n hrtimer_interrupt+0x2cc/0x7b0\n\nThe warn in this situation is meaningless. Since this iocg is being\nremoved, the state of the 'active_list' is irrelevant, and 'waitq_timer'\nis canceled after removing 'active_list' in ioc_pd_free(), which ensures\niocg is freed after iocg_waitq_timer_fn() returns.\n\nTherefore, add the check if iocg was already offlined to avoid warn\nwhen removing a blkcg or disk.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix potential uninit-value access in __ip6_make_skb()\n\nAs it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in\n__ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags\ninstead of testing HDRINCL on the socket to avoid a race condition which\ncauses uninit-value access.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Atom Integrated System Info v2_2 for DCN35\n\nNew request from KMD/VBIOS in order to support new UMA carveout\nmodel. This fixes a null dereference from accessing\nCtx->dc_bios->integrated_info while it was NULL.\n\nDAL parses through the BIOS and extracts the necessary\nintegrated_info but was missing a case for the new BIOS\nversion 2.3.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab: make __free(kfree) accept error pointers\n\nCurrently, if an automatically freed allocation is an error pointer that\nwill lead to a crash. An example of this is in wm831x_gpio_dbg_show().\n\n 171 char *label __free(kfree) = gpiochip_dup_line_label(chip, i);\n 172 if (IS_ERR(label)) {\n 173 dev_err(wm831x->dev, "Failed to duplicate label\\n");\n 174 continue;\n 175 }\n\nThe auto clean up function should check for error pointers as well,\notherwise we're going to keep hitting issues like this.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/probes: fix error check in parse_btf_field()\n\nbtf_find_struct_member() might return NULL or an error via the\nERR_PTR() macro. However, its caller in parse_btf_field() only checks\nfor the NULL condition. Fix this by using IS_ERR() and returning the\nerror up the stack.

In the Linux kernel, the following vulnerability has been resolved:\n\nfpga: bridge: add owner module and take its refcount\n\nThe current implementation of the fpga bridge assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module's refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the bridge if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_bridge\nstruct and use it to take the module's refcount. Modify the function for\nregistering a bridge to take an additional owner module parameter and\nrename it to avoid conflicts. Use the old function name for a helper macro\nthat automatically sets the module that registers the bridge as the owner.\nThis ensures compatibility with existing low-level control modules and\nreduces the chances of registering a bridge without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga bridge.\n\nOther changes: opportunistically move put_device() from __fpga_bridge_get()\nto fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since\nthe bridge device is taken in these functions.

In the Linux kernel, the following vulnerability has been resolved:\n\ntpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer\n\nThe TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the\nmaximum transfer length and the size of the transfer buffer. As such, it\ndoes not account for the 4 bytes of header that prepends the SPI data\nframe. This can result in out-of-bounds accesses and was confirmed with\nKASAN.\n\nIntroduce SPI_HDRSIZE to account for the header and use to allocate the\ntransfer buffer.