In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported\n\nRussell King reports that on the ZII dev rev B, deleting a bridge VLAN\nfrom a user port fails with -ENOENT:\nhttps://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/\n\nThis comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(),\nwhich tries to find an MST entry in &chip->msts associated with the SID,\nbut fails and returns -ENOENT as such.\n\nBut we know that this chip does not support MST at all, so that is not\nsurprising. The question is why does the guard in mv88e6xxx_mst_put()\nnot exit early:\n\n if (!sid)\n return 0;\n\nAnd the answer seems to be simple: the sid comes from vlan.sid which\nsupposedly was previously populated by mv88e6xxx_vtu_get().\nBut some chip->info->ops->vtu_getnext() implementations do not populate\nvlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case,\nlater in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is\njust residual stack memory.\n\nTesting for sid == 0 covers all cases of a non-bridge VLAN or a bridge\nVLAN mapped to the default MSTI. For some chips, SID 0 is valid and\ninstalled by mv88e6xxx_stu_setup(). A chip which does not support the\nSTU would implicitly only support mapping all VLANs to the default MSTI,\nso although SID 0 is not valid, it would be sufficient, if we were to\nzero-initialize the vlan structure, to fix the bug, due to the\ncoincidence that a test for vlan.sid == 0 already exists and leads to\nthe same (correct) behavior.\n\nAnother option which would be sufficient would be to add a test for\nmv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one\nwhich already exists in mv88e6xxx_mst_get(). But that placement means\nthe caller will have to dereference vlan.sid, which means it will access\nuninitialized memory, which is not nice even if it ignores it later.\n\nSo we end up making both modifications, in order to not rely just on the\nsid == 0 coincidence, but also to avoid having uninitialized structure\nfields which might get temporarily accessed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: clean up FDB, MDB, VLAN entries on unbind\n\nAs explained in many places such as commit b117e1e8a86d ("net: dsa:\ndelete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given\nthe assumption that higher layers have balanced additions/deletions.\nAs such, it only makes sense to be extremely vocal when those\nassumptions are violated and the driver unbinds with entries still\npresent.\n\nBut Ido Schimmel points out a very simple situation where that is wrong:\nhttps://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/\n(also briefly discussed by me in the aforementioned commit).\n\nBasically, while the bridge bypass operations are not something that DSA\nexplicitly documents, and for the majority of DSA drivers this API\nsimply causes them to go to promiscuous mode, that isn't the case for\nall drivers. Some have the necessary requirements for bridge bypass\noperations to do something useful - see dsa_switch_supports_uc_filtering().\n\nAlthough in tools/testing/selftests/net/forwarding/local_termination.sh,\nwe made an effort to popularize better mechanisms to manage address\nfilters on DSA interfaces from user space - namely macvlan for unicast,\nand setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the\nfact is that 'bridge fdb add ... self static local' also exists as\nkernel UAPI, and might be useful to someone, even if only for a quick\nhack.\n\nIt seems counter-productive to block that path by implementing shim\n.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP\nin order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from\nrunning, although we could do that.\n\nAccepting that cleanup is necessary seems to be the only option.\nEspecially since we appear to be coming back at this from a different\nangle as well. Russell King is noticing that the WARN_ON() triggers even\nfor VLANs:\nhttps://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/\n\nWhat happens in the bug report above is that dsa_port_do_vlan_del() fails,\nthen the VLAN entry lingers on, and then we warn on unbind and leak it.\n\nThis is not a straight revert of the blamed commit, but we now add an\ninformational print to the kernel log (to still have a way to see\nthat bugs exist), and some extra comments gathered from past years'\nexperience, to justify the logic.

In the Linux kernel, the following vulnerability has been resolved:\n\novl: don't allow datadir only\n\nIn theory overlayfs could support upper layer directly referring to a data\nlayer, but there's no current use case for this.\n\nOriginally, when data-only layers were introduced, this wasn't allowed,\nonly introduced by the "datadir+" feature, but without actually handling\nthis case, resulting in an Oops.\n\nFix by disallowing datadir without lowerdir.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: pidff: Fix null pointer dereference in pidff_find_fields\n\nThis function triggered a null pointer dereference if used to search for\na report that isn't implemented on the device. This happened both for\noptional and required reports alike.\n\nThe same logic was applied to pidff_find_special_field and although\npidff_init_fields should return an error earlier if one of the required\nreports is missing, future modifications could change this logic and\nresurface this possible null pointer dereference again.\n\nLKML bug report:\nhttps://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue\n\nWhen the task management thread processes reply queues while the reset\nthread resets them, the task management thread accesses an invalid queue ID\n(0xFFFF), set by the reset thread, which points to unallocated memory,\ncausing a crash.\n\nAdd flag 'io_admin_reset_sync' to synchronize access between the reset,\nI/O, and admin threads. Before a reset, the reset handler sets this flag to\nblock I/O and admin processing threads. If any thread bypasses the initial\ncheck, the reset thread waits up to 10 seconds for processing to finish. If\nthe wait exceeds 10 seconds, the controller is marked as unrecoverable.

In the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix NULL dereferences in ef100_process_design_param()\n\nSince cited commit, ef100_probe_main() and hence also\n ef100_check_design_params() run before efx->net_dev is created;\n consequently, we cannot netif_set_tso_max_size() or _segs() at this\n point.\nMove those netif calls to ef100_probe_netdev(), and also replace\n netif_err within the design params code with pci_err.

In the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: avoid infinite loop to schedule delayed worker\n\nWe noticed the kworker in page_pool_release_retry() was waken\nup repeatedly and infinitely in production because of the\nbuggy driver causing the inflight less than 0 and warning\nus in page_pool_inflight()[1].\n\nSince the inflight value goes negative, it means we should\nnot expect the whole page_pool to get back to work normally.\n\nThis patch mitigates the adverse effect by not rescheduling\nthe kworker when detecting the inflight negative in\npage_pool_release_retry().\n\n[1]\n[Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------\n[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages\n...\n[Mon Feb 10 20:36:11 2025] Call Trace:\n[Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70\n[Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370\n[Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0\n[Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140\n[Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370\n[Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40\n[Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40\n[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---\nNote: before this patch, the above calltrace would flood the\ndmesg due to repeated reschedule of release_dw kworker.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/jfs: Prevent integer overflow in AG size calculation\n\nThe JFS filesystem calculates allocation group (AG) size using 1 <<\nl2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with >2TB\naggregates on 32-bit systems), this 32-bit shift operation causes undefined\nbehavior and improper AG sizing.\n\nOn 32-bit architectures:\n- Left-shifting 1 by 32+ bits results in 0 due to integer overflow\n- This creates invalid AG sizes (0 or garbage values) in\nsbi->bmap->db_agsize\n- Subsequent block allocations would reference invalid AG structures\n- Could lead to:\n - Filesystem corruption during extend operations\n - Kernel crashes due to invalid memory accesses\n - Security vulnerabilities via malformed on-disk structures\n\nFix by casting to s64 before shifting:\nbmp->db_agsize = (s64)1 << l2agsize;\n\nThis ensures 64-bit arithmetic even on 32-bit architectures. The cast\nmatches the data type of db_agsize (s64) and follows similar patterns in\nJFS block calculation code.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: st: Fix array overflow in st_setup()\n\nChange the array size to follow parms size instead of a fixed value.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: harden block_group::bg_list against list_del() races\n\nAs far as I can tell, these calls of list_del_init() on bg_list cannot\nrun concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),\nas they are in transaction error paths and situations where the block\ngroup is readonly.\n\nHowever, if there is any chance at all of racing with mark_bg_unused(),\nor a different future user of bg_list, better to be safe than sorry.\n\nOtherwise we risk the following interleaving (bg_list refcount in parens)\n\nT1 (some random op) T2 (btrfs_mark_bg_unused)\n !list_empty(&bg->bg_list); (1)\nlist_del_init(&bg->bg_list); (1)\n list_move_tail (1)\nbtrfs_put_block_group (0)\n btrfs_delete_unused_bgs\n bg = list_first_entry\n list_del_init(&bg->bg_list);\n btrfs_put_block_group(bg); (-1)\n\nUltimately, this results in a broken ref count that hits zero one deref\nearly and the real final deref underflows the refcount, resulting in a WARNING.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Guard Possible Null Pointer Dereference\n\n[WHY]\nIn some situations, dc->res_pool may be null.\n\n[HOW]\nCheck if pointer is null before dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix mode1 reset crash issue\n\nIf HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal\nuser space to abort the processes. After process abort exit, user queues\nstill use the GPU to access system memory before h/w is reset while KFD\ncleanup worker free system memory and free VRAM.\n\nThere is use-after-free race bug that KFD allocate and reuse the freed\nsystem memory, and user queue write to the same system memory to corrupt\nthe data structure and cause driver crash.\n\nTo fix this race, KFD cleanup worker terminate user queues, then flush\nreset_domain wq to wait for any GPU ongoing reset complete, and then\nfree outstanding BOs.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: debugfs hang_hws skip GPU with MES\n\ndebugfs hang_hws is used by GPU reset test with HWS, for MES this crash\nthe kernel with NULL pointer access because dqm->packet_mgr is not setup\nfor MES path.\n\nSkip GPU with MES for now, MES hang_hws debugfs interface will be\nsupported later.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()\n\nAdd error handling to propagate amdgpu_cgs_create_device() failures\nto the caller. When amdgpu_cgs_create_device() fails, release hwmgr\nand return -ENOMEM to prevent null pointer dereference.\n\n[v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.

In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: omapfb: Add 'plane' value check\n\nFunction dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB\nof the enum parameter plane.\n\nThe value of this parameter is initialized in dss_init_overlays and in the\ncurrent state of the code it cannot take this value so it's not a real\nproblem.\n\nFor the purposes of defensive coding it wouldn't be superfluous to check\nthe parameter value, because some functions down the call stack process\nthis value correctly and some not.\n\nFor example, in dispc_ovl_setup_global_alpha it may lead to buffer\noverflow.\n\nAdd check for this value.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE static\nanalysis tool.

In the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK. Regardless it's\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Tear down vGIC on failed vCPU creation\n\nIf kvm_arch_vcpu_create() fails to share the vCPU page with the\nhypervisor, we propagate the error back to the ioctl but leave the\nvGIC vCPU data initialised. Note only does this leak the corresponding\nmemory when the vCPU is destroyed but it can also lead to use-after-free\nif the redistributor device handling tries to walk into the vCPU.\n\nAdd the missing cleanup to kvm_arch_vcpu_create(), ensuring that the\nvGIC vCPU structures are destroyed on error.

In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix PM related deadlocks in MS IOCTLs\n\nPrevent runtime resume/suspend while MS IOCTLs are in progress.\nFailed suspend will call ivpu_ms_cleanup() that would try to acquire\nfile_priv->ms_lock, which is already held by the IOCTLs.

In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix deadlock in ivpu_ms_cleanup()\n\nFix deadlock in ivpu_ms_cleanup() by preventing runtime resume after\nfile_priv->ms_lock is acquired.\n\nDuring a failure in runtime resume, a cold boot is executed, which\ncalls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup()\nthat acquires file_priv->ms_lock and causes the deadlock.

In the Linux kernel, the following vulnerability has been resolved:\n\narm64: mops: Do not dereference src reg for a set operation\n\nThe source register is not used for SET* and reading it can result in\na UBSAN out-of-bounds array access error, specifically when the MOPS\nexception is taken from a SET* sequence with XZR (reg 31) as the\nsource. Architecturally this is the only case where a src/dst/size\nfield in the ESR can be reported as 31.\n\nPrior to 2de451a329cf662b the code in do_el0_mops() was benign as the\nuse of pt_regs_read_reg() prevented the out-of-bounds access.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: fprobe events: Fix possible UAF on modules\n\nCommit ac91052f0ae5 ("tracing: tprobe-events: Fix leakage of module\nrefcount") moved try_module_get() from __find_tracepoint_module_cb()\nto find_tracepoint() caller, but that introduced a possible UAF\nbecause the module can be unloaded before try_module_get(). In this\ncase, the module object should be freed too. Thus, try_module_get()\ndoes not only fail but may access to the freed object.\n\nTo avoid that, try_module_get() in __find_tracepoint_module_cb()\nagain.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: pciehp: Avoid unnecessary device replacement check\n\nHot-removal of nested PCI hotplug ports suffers from a long-standing race\ncondition which can lead to a deadlock: A parent hotplug port acquires\npci_lock_rescan_remove(), then waits for pciehp to unbind from a child\nhotplug port. Meanwhile that child hotplug port tries to acquire\npci_lock_rescan_remove() as well in order to remove its own children.\n\nThe deadlock only occurs if the parent acquires pci_lock_rescan_remove()\nfirst, not if the child happens to acquire it first.\n\nSeveral workarounds to avoid the issue have been proposed and discarded\nover the years, e.g.:\n\nhttps://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/\n\nA proper fix is being worked on, but needs more time as it is nontrivial\nand necessarily intrusive.\n\nRecent commit 9d573d19547b ("PCI: pciehp: Detect device replacement during\nsystem sleep") provokes more frequent occurrence of the deadlock when\nremoving more than one Thunderbolt device during system sleep. The commit\nsought to detect device replacement, but also triggered on device removal.\nDifferentiating reliably between replacement and removal is impossible\nbecause pci_get_dsn() returns 0 both if the device was removed, as well as\nif it was replaced with one lacking a Device Serial Number.\n\nAvoid the more frequent occurrence of the deadlock by checking whether the\nhotplug port itself was hot-removed. If so, there's no sense in checking\nwhether its child device was replaced.\n\nThis works because the ->resume_noirq() callback is invoked in top-down\norder for the entire hierarchy: A parent hotplug port detecting device\nreplacement (or removal) marks all children as removed using\npci_dev_set_disconnected() and a child hotplug port can then reliably\ndetect being removed.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: fsl-qspi: use devm function instead of driver remove\n\nDriver use devm APIs to manage clk/irq/resources and register the spi\ncontroller, but the legacy remove function will be called first during\ndevice detach and trigger kernel panic. Drop the remove function and use\ndevm_add_action_or_reset() for driver cleanup to ensure the release\nsequence.\n\nTrigger kernel panic on i.MX8MQ by\necho 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind

In the Linux kernel, the following vulnerability has been resolved:\n\npm: cpupower: bench: Prevent NULL dereference on malloc failure\n\nIf malloc returns NULL due to low memory, 'config' pointer can be NULL.\nAdd a check to prevent NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: rawnand: brcmnand: fix PM resume warning\n\nFixed warning on PM resume as shown below caused due to uninitialized\nstruct nand_operation that checks chip select field :\nWARN_ON(op->cs >= nanddev_ntargets(&chip->base)\n\n[ 14.588522] ------------[ cut here ]------------\n[ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8\n[ 14.588553] Modules linked in: bdc udc_core\n[ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16\n[ 14.588590] Tainted: [W]=WARN\n[ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree)\n[ 14.588598] Call trace:\n[ 14.588604] dump_backtrace from show_stack+0x18/0x1c\n[ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c\n[ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c\n[ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c\n[ 14.588653] r5:c08d40b0 r4:c1003cb0\n[ 14.588656] dump_stack from __warn+0x84/0xe4\n[ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194\n[ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000\n[ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8\n[ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048\n[ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150\n[ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040\n[ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54\n[ 14.588735] r5:00000010 r4:c0840a50\n[ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c\n[ 14.588757] dpm_run_callback from device_resume+0xc0/0x324\n[ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010\n[ 14.588779] device_resume from dpm_resume+0x130/0x160\n[ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0\n[ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20\n[ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414\n[ 14.588826] r4:00000010\n[ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8\n[ 14.588848] r5:c228a414 r4:00000000\n[ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc\n[ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000\n[ 14.588871] r4:00000003\n[ 14.588874] pm_suspend from state_store+0x74/0xd0\n[ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003\n[ 14.588892] state_store from kobj_attr_store+0x1c/0x28\n[ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250\n[ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c\n[ 14.588936] r5:c3502900 r4:c0d92a48\n[ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0\n[ 14.588956] r5:c3502900 r4:c3501f40\n[ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420\n[ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00\n[ 14.588983] r4:c042a88c\n[ 14.588987] vfs_write from ksys_write+0x74/0xe4\n[ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00\n[ 14.589008] r4:c34f7f00\n[ 14.589011] ksys_write from sys_write+0x10/0x14\n[ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004\n[ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c\n[ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0)\n[ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001\n[ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78\n[ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8\n[ 14.589065] ---[ end trace 0000000000000000 ]---\n\nThe fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, when\ndoing PM resume operation in compliance with the controller support for single\ndie nand chip. Switching from nand_reset_op() to nan\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: remove wrong sb->s_sequence check\n\nJournal emptiness is not determined by sb->s_sequence == 0 but rather by\nsb->s_start == 0 (which is set a few lines above). Furthermore 0 is a\nvalid transaction ID so the check can spuriously trigger. Remove the\ninvalid WARN_ON.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/tegra241-cmdqv: Fix warnings due to dmam_free_coherent()\n\nTwo WARNINGs are observed when SMMU driver rolls back upon failure:\n arm-smmu-v3.9.auto: Failed to register iommu\n arm-smmu-v3.9.auto: probe with driver arm-smmu-v3 failed with error -22\n ------------[ cut here ]------------\n WARNING: CPU: 5 PID: 1 at kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8\n Call trace:\n dmam_free_coherent+0xc0/0xd8 (P)\n tegra241_vintf_free_lvcmdq+0x74/0x188\n tegra241_cmdqv_remove_vintf+0x60/0x148\n tegra241_cmdqv_remove+0x48/0xc8\n arm_smmu_impl_remove+0x28/0x60\n devm_action_release+0x1c/0x40\n ------------[ cut here ]------------\n 128 pages are still in use!\n WARNING: CPU: 16 PID: 1 at mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8\n Call trace:\n free_contig_range+0x18c/0x1c8 (P)\n cma_release+0x154/0x2f0\n dma_free_contiguous+0x38/0xa0\n dma_direct_free+0x10c/0x248\n dma_free_attrs+0x100/0x290\n dmam_free_coherent+0x78/0xd8\n tegra241_vintf_free_lvcmdq+0x74/0x160\n tegra241_cmdqv_remove+0x98/0x198\n arm_smmu_impl_remove+0x28/0x60\n devm_action_release+0x1c/0x40\n\nThis is because the LVCMDQ queue memory are managed by devres, while that\ndmam_free_coherent() is called in the context of devm_action_release().\n\nJason pointed out that "arm_smmu_impl_probe() has mis-ordered the devres\ncallbacks if ops->device_remove() is going to be manually freeing things\nthat probe allocated":\nhttps://lore.kernel.org/linux-iommu/20250407174408.GB1722458@nvidia.com/\n\nIn fact, tegra241_cmdqv_init_structures() only allocates memory resources\nwhich means any failure that it generates would be similar to -ENOMEM, so\nthere is no point in having that "falling back to standard SMMU" routine,\nas the standard SMMU would likely fail to allocate memory too.\n\nRemove the unwind part in tegra241_cmdqv_init_structures(), and return a\nproper error code to ask SMMU driver to call tegra241_cmdqv_remove() via\nimpl_ops->device_remove(). Then, drop tegra241_vintf_free_lvcmdq() since\ndevres will take care of that.

In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix reference leak in pci_register_host_bridge()\n\nIf device_register() fails, call put_device() to give up the reference to\navoid a memory leak, per the comment at device_register().\n\nFound by code review.\n\n[bhelgaas: squash Dan Carpenter's double free fix from\nhttps://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads\n\nFix niu_try_msix() to not cause a fatal trap on sparc systems.\n\nSet PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to\nwork around a bug in the hardware or firmware.\n\nFor each vector entry in the msix table, niu chips will cause a fatal\ntrap if any registers in that entry are read before that entries'\nENTRY_DATA register is written to. Testing indicates writes to other\nregisters are not sufficient to prevent the fatal trap, however the value\ndoes not appear to matter. This only needs to happen once after power up,\nso simply rebooting into a kernel lacking this fix will NOT cause the\ntrap.\n\nNON-RESUMABLE ERROR: Reporting on cpu 64\nNON-RESUMABLE ERROR: TPC [0x00000000005f6900] \nNON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff\nNON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]\nNON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]\nNON-RESUMABLE ERROR: type [precise nonresumable]\nNON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >\nNON-RESUMABLE ERROR: raddr [0xffffffffffffffff]\nNON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]\nNON-RESUMABLE ERROR: size [0x8]\nNON-RESUMABLE ERROR: asi [0x00]\nCPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63\nWorkqueue: events work_for_cpu_fn\nTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted\nTPC: \ng0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100\ng4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000\no0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620\no4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128\nRPC: <__pci_enable_msix_range+0x3cc/0x460>\nl0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020\nl4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734\ni0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d\ni4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0\nI7: \nCall Trace:\n[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu]\n[<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu]\n[<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu]\n[<00000000005ef3e4>] local_pci_probe+0x28/0x74\n[<0000000000469240>] work_for_cpu_fn+0x8/0x1c\n[<000000000046b008>] process_scheduled_works+0x144/0x210\n[<000000000046b518>] worker_thread+0x13c/0x1c0\n[<00000000004710e0>] kthread+0xb8/0xc8\n[<00000000004060c8>] ret_from_fork+0x1c/0x2c\n[<0000000000000000>] 0x0\nKernel panic - not syncing: Non-resumable error.

In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy->cpus mask. apple_soc_cpufreq_get_rate() does not check\nfor this case, which results in a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy->cpus mask. scmi_cpufreq_get_rate() does not check for\nthis case, which results in a NULL pointer dereference.\n\nAdd NULL check after cpufreq_cpu_get_raw() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy->cpus mask. scpi_cpufreq_get_rate() does not check for\nthis case, which results in a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()\n\nA race can occur between the MCQ completion path and the abort handler:\nonce a request completes, __blk_mq_free_request() sets rq->mq_hctx to\nNULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in\nufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is\ndereferenced, the kernel will crash.\n\nAdd a NULL check for the returned hwq pointer. If hwq is NULL, log an\nerror and return FAILED, preventing a potential NULL-pointer\ndereference. As suggested by Bart, the ufshcd_cmd_inflight() check is\nremoved.\n\nThis is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix\nufshcd_abort_one racing issue").\n\nThis is found by our static analysis tool KNighter.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: return EIO on RAID1 block group write pointer mismatch\n\nThere was a bug report about a NULL pointer dereference in\n__btrfs_add_free_space_zoned() that ultimately happens because a\nconversion from the default metadata profile DUP to a RAID1 profile on two\ndisks.\n\nThe stack trace has the following signature:\n\n BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile\n BUG: kernel NULL pointer dereference, address: 0000000000000058\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0\n RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001\n RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410\n RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000\n R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000\n R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000\n FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0\n Call Trace:\n \n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15c/0x2f0\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0\n btrfs_add_free_space_async_trimmed+0x34/0x40\n btrfs_add_new_free_space+0x107/0x120\n btrfs_make_block_group+0x104/0x2b0\n btrfs_create_chunk+0x977/0xf20\n btrfs_chunk_alloc+0x174/0x510\n ? srso_return_thunk+0x5/0x5f\n btrfs_inc_block_group_ro+0x1b1/0x230\n btrfs_relocate_block_group+0x9e/0x410\n btrfs_relocate_chunk+0x3f/0x130\n btrfs_balance+0x8ac/0x12b0\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? __kmalloc_cache_noprof+0x14c/0x3e0\n btrfs_ioctl+0x2686/0x2a80\n ? srso_return_thunk+0x5/0x5f\n ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120\n __x64_sys_ioctl+0x97/0xc0\n do_syscall_64+0x82/0x160\n ? srso_return_thunk+0x5/0x5f\n ? __memcg_slab_free_hook+0x11a/0x170\n ? srso_return_thunk+0x5/0x5f\n ? kmem_cache_free+0x3f0/0x450\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? syscall_exit_to_user_mode+0x10/0x210\n ? srso_return_thunk+0x5/0x5f\n ? do_syscall_64+0x8e/0x160\n ? sysfs_emit+0xaf/0xc0\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? seq_read_iter+0x207/0x460\n ? srso_return_thunk+0x5/0x5f\n ? vfs_read+0x29c/0x370\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? syscall_exit_to_user_mode+0x10/0x210\n ? srso_return_thunk+0x5/0x5f\n ? do_syscall_64+0x8e/0x160\n ? srso_return_thunk+0x5/0x5f\n ? exc_page_fault+0x7e/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7fdab1e0ca6d\n RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d\n RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003\n RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001\n \n CR2: 0000000000000058\n ---[ end trace 0000000000000000 ]---\n\nThe 1st line is the most interesting here:\n\n BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile\n\nWhen a RAID1 block-group is created and a write pointer mismatch between\nthe disks in the RAID set is detected, btrfs sets the alloc_offset to the\nlength of the block group marking it as full. Afterwards the code expects\nthat a balance operation will evacuate the data in this block-group and\nrepair the problems.\n\nBut before this is possible, the new space of this block-group will be\naccounted in the free space cache. But in __btrfs_\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Add NULL check in ufshcd_mcq_compl_pending_transfer()\n\nAdd a NULL check for the returned hwq pointer by ufshcd_mcq_req_to_hwq().\n\nThis is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix\nufshcd_abort_one racing issue").

In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix out-of-bounds access in nvmet_enable_port\n\nWhen trying to enable a port that has no transport configured yet,\nnvmet_enable_port() uses NVMF_TRTYPE_MAX (255) to query the transports\narray, causing an out-of-bounds access:\n\n[ 106.058694] BUG: KASAN: global-out-of-bounds in nvmet_enable_port+0x42/0x1da\n[ 106.058719] Read of size 8 at addr ffffffff89dafa58 by task ln/632\n[...]\n[ 106.076026] nvmet: transport type 255 not supported\n\nSince commit 200adac75888, NVMF_TRTYPE_MAX is the default state as configured by\nnvmet_ports_make().\nAvoid this by checking for NVMF_TRTYPE_MAX before proceeding.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too\n\nSimilarly to the previous patch, we need to safe guard hfsc_dequeue()\ntoo. But for this one, we don't have a reliable reproducer.

In the Linux kernel, the following vulnerability has been resolved:\n\nsched/eevdf: Fix se->slice being set to U64_MAX and resulting crash\n\nThere is a code path in dequeue_entities() that can set the slice of a\nsched_entity to U64_MAX, which sometimes results in a crash.\n\nThe offending case is when dequeue_entities() is called to dequeue a\ndelayed group entity, and then the entity's parent's dequeue is delayed.\nIn that case:\n\n1. In the if (entity_is_task(se)) else block at the beginning of\n dequeue_entities(), slice is set to\n cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then\n it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.\n2. The first for_each_sched_entity() loop dequeues the entity.\n3. If the entity was its parent's only child, then the next iteration\n tries to dequeue the parent.\n4. If the parent's dequeue needs to be delayed, then it breaks from the\n first for_each_sched_entity() loop _without updating slice_.\n5. The second for_each_sched_entity() loop sets the parent's ->slice to\n the saved slice, which is still U64_MAX.\n\nThis throws off subsequent calculations with potentially catastrophic\nresults. A manifestation we saw in production was:\n\n6. In update_entity_lag(), se->slice is used to calculate limit, which\n ends up as a huge negative number.\n7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit\n is negative, vlag > limit, so se->vlag is set to the same huge\n negative number.\n8. In place_entity(), se->vlag is scaled, which overflows and results in\n another huge (positive or negative) number.\n9. The adjusted lag is subtracted from se->vruntime, which increases or\n decreases se->vruntime by a huge number.\n10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which\n incorrectly returns false because the vruntime is so far from the\n other vruntimes on the queue, causing the\n (vruntime - cfs_rq->min_vruntime) * load calulation to overflow.\n11. Nothing appears to be eligible, so pick_eevdf() returns NULL.\n12. pick_next_entity() tries to dereference the return value of\n pick_eevdf() and crashes.\n\nDumping the cfs_rq states from the core dumps with drgn showed tell-tale\nhuge vruntime ranges and bogus vlag values, and I also traced se->slice\nbeing set to U64_MAX on live systems (which was usually "benign" since\nthe rest of the runqueue needed to be in a particular state to crash).\n\nFix it in dequeue_entities() by always setting slice from the first\nnon-empty cfs_rq.

In the Linux kernel, the following vulnerability has been resolved:\n\nxen-netfront: handle NULL returned by xdp_convert_buff_to_frame()\n\nThe function xdp_convert_buff_to_frame() may return NULL if it fails\nto correctly convert the XDP buffer into an XDP frame due to memory\nconstraints, internal errors, or invalid data. Failing to check for NULL\nmay lead to a NULL pointer dereference if the result is used later in\nprocessing, potentially causing crashes, data corruption, or undefined\nbehavior.\n\nOn XDP redirect failure, the associated page must be released explicitly\nif it was previously retained via get_page(). Failing to do so may result\nin a memory leak, as the pages reference count is not decremented.

In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()\n\nWith ACPI in place, gicv2m_get_fwnode() is registered with the pci\nsubsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime\nduring a PCI host bridge probe. But, the call back is wrongly marked as\n__init, causing it to be freed, while being registered with the PCI\nsubsystem and could trigger:\n\n Unable to handle kernel paging request at virtual address ffff8000816c0400\n gicv2m_get_fwnode+0x0/0x58 (P)\n pci_set_bus_msi_domain+0x74/0x88\n pci_register_host_bridge+0x194/0x548\n\nThis is easily reproducible on a Juno board with ACPI boot.\n\nRetain the function for later use.

In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Return NULL from huge_pte_offset() for invalid PMD\n\nLoongArch's huge_pte_offset() currently returns a pointer to a PMD slot\neven if the underlying entry points to invalid_pte_table (indicating no\nmapping). Callers like smaps_hugetlb_range() fetch this invalid entry\nvalue (the address of invalid_pte_table) via this pointer.\n\nThe generic is_swap_pte() check then incorrectly identifies this address\nas a swap entry on LoongArch, because it satisfies the "!pte_present()\n&& !pte_none()" conditions. This misinterpretation, combined with a\ncoincidental match by is_migration_entry() on the address bits, leads to\nkernel crashes in pfn_swap_entry_to_page().\n\nFix this at the architecture level by modifying huge_pte_offset() to\ncheck the PMD entry's content using pmd_none() before returning. If the\nentry is invalid (i.e., it points to invalid_pte_table), return NULL\ninstead of the pointer to the slot.

In the Linux kernel, the following vulnerability has been resolved:\n\nmei: vsc: Fix fortify-panic caused by invalid counted_by() use\n\ngcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[]\nand the vsc-tp.c code is using this in a wrong way. len does not contain\nthe available size in the buffer, it contains the actual packet length\n*without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to\nbuf[] the fortify-panic handler gets triggered:\n\n[ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0\n[ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50\n...\n[ 80.843175] __fortify_panic+0x9/0xb\n[ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw]\n[ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90\n[ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110\n[ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc]\n[ 80.843270] mei_reset+0x11d/0x420 [mei]\n\nThe easiest fix would be to just drop the counted-by but with the exception\nof the ack buffer in vsc_tp_xfer_helper() which only contains enough room\nfor the packet-header, all other uses of vsc_tp_packet always use a buffer\nof VSC_TP_MAX_XFER_SIZE bytes for the packet.\n\nInstead of just dropping the counted-by, split the vsc_tp_packet struct\ndefinition into a header and a full-packet definition and use a fixed\nsize buf[] in the packet definition, this way fortify-source buffer\noverrun checking still works when enabled.

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration\n\nResolve kernel panic while accessing IRQ handler associated with the\ngenerated IRQ. This is done by acquiring the spinlock and storing the\ncurrent interrupt state before handling the interrupt request using\ngeneric_handle_irq.\n\nA previous fix patch was submitted where 'generic_handle_irq' was\nreplaced with 'handle_nested_irq'. However, this change also causes\nthe kernel panic where after determining which GPIO triggered the\ninterrupt and attempting to call handle_nested_irq with the mapped\nIRQ number, leads to a failure in locating the registered handler.

In the Linux kernel, the following vulnerability has been resolved:\n\ntty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT\n\nThis requirement was overeagerly loosened in commit 2f83e38a095f\n("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as\nit turns out,\n\n (1) the logic I implemented there was inconsistent (apologies!),\n\n (2) TIOCL_SELMOUSEREPORT might actually be a small security risk\n after all, and\n\n (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse\n daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN\n already.\n\nIn more detail:\n\n1. The previous patch has inconsistent logic:\n\n In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes\n without CAP_SYS_ADMIN"), we checked for sel_mode ==\n TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of\n this "mode" parameter were actually used as an additional way to\n pass an argument. So the patch did actually still require\n CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not\n require it if none of the mouse buttons bits are set.\n\n This logic is inconsistent and was not intentional. We should have\n the same policies for using TIOCL_SELMOUSEREPORT independent of the\n value of the "hidden" mouse button argument.\n\n I sent a separate documentation patch to the man page list with\n more details on TIOCL_SELMOUSEREPORT:\n https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/\n\n2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can\n let an attacker simulate "keyboard" input to command line\n applications on the same terminal, like TIOCSTI and some other\n TIOCLINUX "selection mode" IOCTLs.\n\n By enabling mouse reporting on a terminal and then injecting mouse\n reports through TIOCL_SELMOUSEREPORT, an attacker can simulate\n mouse movements on the same terminal, similar to the TIOCSTI\n keystroke injection attacks that were previously possible with\n TIOCSTI and other TIOCL_SETSEL selection modes.\n\n Many programs (including libreadline/bash) are then prone to\n misinterpret these mouse reports as normal keyboard input because\n they do not expect input in the X11 mouse protocol form. The\n attacker does not have complete control over the escape sequence,\n but they can at least control the values of two consecutive bytes\n in the binary mouse reporting escape sequence.\n\n I went into more detail on that in the discussion at\n https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/\n\n It is not equally trivial to simulate arbitrary keystrokes as it\n was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be\n disabled")), but the general mechanism is there, and together with\n the small number of existing legit use cases (see below), it would\n be better to revert back to requiring CAP_SYS_ADMIN for\n TIOCL_SELMOUSEREPORT, as it was already the case before\n commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without\n CAP_SYS_ADMIN").\n\n3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or\n Consolation), and they are the only legit use case:\n\n To quote console_codes(4):\n\n The mouse tracking facility is intended to return\n xterm(1)-compatible mouse status reports. Because the console\n driver has no way to know the device or type of the mouse, these\n reports are returned in the console input stream only when the\n virtual terminal driver receives a mouse update ioctl. These\n ioctls must be generated by a mouse-aware user-mode application\n such as the gpm(8) daemon.\n\n Jared Finder has also confirmed in\n https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/\n that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it\n would be difficult to find good reasons for doing that, given that\n it would interfere with the reports that GPM is sending.\n\n More information on the interaction between GPM, terminals and th\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Fix invalid pointer dereference in Etron workaround\n\nThis check is performed before prepare_transfer() and prepare_ring(), so\nenqueue can already point at the final link TRB of a segment. And indeed\nit will, some 0.4% of times this code is called.\n\nThen enqueue + 1 is an invalid pointer. It will crash the kernel right\naway or load some junk which may look like a link TRB and cause the real\nlink TRB to be replaced with a NOOP. This wouldn't end well.\n\nUse a functionally equivalent test which doesn't dereference the pointer\nand always gives correct result.\n\nSomething has crashed my machine twice in recent days while playing with\nan Etron HC, and a control transfer stress test ran for confirmation has\njust crashed it again. The same test passes with this patch applied.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: Fix deadlock when using NCM gadget\n\nThe cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit\n58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").\n\nUnder PREEMPT_RT the deadlock can be readily triggered by heavy network\ntraffic, for example using "iperf --bidir" over NCM ethernet link.\n\nThe deadlock occurs because the threaded interrupt handler gets\npreempted by a softirq, but both are protected by the same spinlock.\nPrevent deadlock by disabling softirq during threaded irq handler.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: chipidea: ci_hdrc_imx: fix usbmisc handling\n\nusbmisc is an optional device property so it is totally valid for the\ncorresponding data->usbmisc_data to have a NULL value.\n\nCheck that before dereferencing the pointer.\n\nFound by Linux Verification Center (linuxtesting.org) with Svace static\nanalysis tool.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: gadget: check that event count does not exceed event buffer length\n\nThe event count is read from register DWC3_GEVNTCOUNT.\nThere is a check for the count being zero, but not for exceeding the\nevent buffer length.\nCheck that event count does not exceed event buffer length,\navoiding an out-of-bounds access when memcpy'ing the event.\nCrash log:\nUnable to handle kernel paging request at virtual address ffffffc0129be000\npc : __memcpy+0x114/0x180\nlr : dwc3_check_event_buf+0xec/0x348\nx3 : 0000000000000030 x2 : 000000000000dfc4\nx1 : ffffffc0129be000 x0 : ffffff87aad60080\nCall trace:\n__memcpy+0x114/0x180\ndwc3_interrupt+0x24/0x34

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: class: Fix NULL pointer access\n\nConcurrent calls to typec_partner_unlink_device can lead to a NULL pointer\ndereference. This patch adds a mutex to protect USB device pointers and\nprevent this issue. The same mutex protects both the device pointers and\nthe partner device registration.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: null - Use spin lock instead of mutex\n\nAs the null algorithm may be freed in softirq context through\naf_alg, use spin locks instead of mutexes to protect the default\nnull algorithm.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kmemleak warning for percpu hashmap\n\nVlad Poenaru reported the following kmemleak issue:\n\n unreferenced object 0x606fd7c44ac8 (size 32):\n backtrace (crc 0):\n pcpu_alloc_noprof+0x730/0xeb0\n bpf_map_alloc_percpu+0x69/0xc0\n prealloc_init+0x9d/0x1b0\n htab_map_alloc+0x363/0x510\n map_create+0x215/0x3a0\n __sys_bpf+0x16b/0x3e0\n __x64_sys_bpf+0x18/0x20\n do_syscall_64+0x7b/0x150\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFurther investigation shows the reason is due to not 8-byte aligned\nstore of percpu pointer in htab_elem_set_ptr():\n *(void __percpu **)(l->key + key_size) = pptr;\n\nNote that the whole htab_elem alignment is 8 (for x86_64). If the key_size\nis 4, that means pptr is stored in a location which is 4 byte aligned but\nnot 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based\non 8 byte stride, so it won't detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n htab->elem_size = sizeof(struct htab_elem) +\n round_up(htab->map.key_size, 8);\n if (percpu)\n htab->elem_size += sizeof(void *);\n else\n htab->elem_size += round_up(htab->map.value_size, 8);\n\nSo storing pptr with 8-byte alignment won't cause any problem and can fix\nkmemleak too.\n\nThe issue can be reproduced with bpf selftest as well:\n 1. Enable CONFIG_DEBUG_KMEMLEAK config\n 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.\n The purpose is to keep map available so kmemleak can be detected.\n 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Keep write operations atomic\n\nsyzbot reported a NULL pointer dereference in __generic_file_write_iter. [1]\n\nBefore the write operation is completed, the user executes ioctl[2] to clear\nthe compress flag of the file, which causes the is_compressed() judgment to\nreturn 0, further causing the program to enter the wrong process and call the\nwrong ops ntfs_aops_cmpr, which triggers the null pointer dereference of\nwrite_begin.\n\nUse inode lock to synchronize ioctl and write to avoid this case.\n\n[1]\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\nMem abort info:\n ESR = 0x0000000086000006\n EC = 0x21: IABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x06: level 2 translation fault\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000011896d000\n[0000000000000000] pgd=0800000118b44403, p4d=0800000118b44403, pud=0800000117517403, pmd=0000000000000000\nInternal error: Oops: 0000000086000006 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 UID: 0 PID: 6427 Comm: syz-executor347 Not tainted 6.13.0-rc3-syzkaller-g573067a5a685 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : 0x0\nlr : generic_perform_write+0x29c/0x868 mm/filemap.c:4055\nsp : ffff80009d4978a0\nx29: ffff80009d4979c0 x28: dfff800000000000 x27: ffff80009d497bc8\nx26: 0000000000000000 x25: ffff80009d497960 x24: ffff80008ba71c68\nx23: 0000000000000000 x22: ffff0000c655dac0 x21: 0000000000001000\nx20: 000000000000000c x19: 1ffff00013a92f2c x18: ffff0000e183aa1c\nx17: 0004060000000014 x16: ffff800083275834 x15: 0000000000000001\nx14: 0000000000000000 x13: 0000000000000001 x12: ffff0000c655dac0\nx11: 0000000000ff0100 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : ffff80009d497980 x4 : ffff80009d497960 x3 : 0000000000001000\nx2 : 0000000000000000 x1 : ffff0000e183a928 x0 : ffff0000d60b0fc0\nCall trace:\n 0x0 (P)\n __generic_file_write_iter+0xfc/0x204 mm/filemap.c:4156\n ntfs_file_write_iter+0x54c/0x630 fs/ntfs3/file.c:1267\n new_sync_write fs/read_write.c:586 [inline]\n vfs_write+0x920/0xcf4 fs/read_write.c:679\n ksys_write+0x15c/0x26c fs/read_write.c:731\n __do_sys_write fs/read_write.c:742 [inline]\n __se_sys_write fs/read_write.c:739 [inline]\n __arm64_sys_write+0x7c/0x90 fs/read_write.c:739\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n\n[2]\nioctl$FS_IOC_SETFLAGS(r0, 0x40086602, &(0x7f00000000c0)=0x20)

In the Linux kernel, the following vulnerability has been resolved:\n\nsound/virtio: Fix cancel_sync warnings on uninitialized work_structs\n\nBetty reported hitting the following warning:\n\n[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182\n...\n[ 8.713282][ T221] Call trace:\n[ 8.713365][ T221] __flush_work+0x8d0/0x914\n[ 8.713468][ T221] __cancel_work_sync+0xac/0xfc\n[ 8.713570][ T221] cancel_work_sync+0x24/0x34\n[ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]\n[ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]\n[ 8.714035][ T221] virtio_dev_probe+0x28c/0x390\n[ 8.714139][ T221] really_probe+0x1bc/0x4c8\n...\n\nIt seems we're hitting the error path in virtsnd_probe(), which\ntriggers a virtsnd_remove() which iterates over the substreams\ncalling cancel_work_sync() on the elapsed_period work_struct.\n\nLooking at the code, from earlier in:\nvirtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg()\n\nWe set snd->nsubstreams, allocate the snd->substreams, and if\nwe then hit an error on the info allocation or something in\nvirtsnd_ctl_query_info() fails, we will exit without having\ninitialized the elapsed_period work_struct.\n\nWhen that error path unwinds we then call virtsnd_remove()\nwhich as long as the substreams array is allocated, will iterate\nthrough calling cancel_work_sync() on the uninitialized work\nstruct hitting this warning.\n\nTakashi Iwai suggested this fix, which initializes the substreams\nstructure right after allocation, so that if we hit the error\npaths we avoid trying to cleanup uninitialized data.\n\nNote: I have not yet managed to reproduce the issue myself, so\nthis patch has had limited testing.\n\nFeedback or thoughts would be appreciated!

In the Linux kernel, the following vulnerability has been resolved:\n\nudmabuf: fix a buf size overflow issue during udmabuf creation\n\nby casting size_limit_mb to u64 when calculate pglimit.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix WARNING "do not call blocking ops when !TASK_RUNNING"\n\nwait_event_timeout() will set the state of the current\ntask to TASK_UNINTERRUPTIBLE, before doing the condition check. This\nmeans that ksmbd_durable_scavenger_alive() will try to acquire the mutex\nwhile already in a sleeping state. The scheduler warns us by giving\nthe following warning:\n\ndo not call blocking ops when !TASK_RUNNING; state=2 set at\n [<0000000061515a6f>] prepare_to_wait_event+0x9f/0x6c0\nWARNING: CPU: 2 PID: 4147 at kernel/sched/core.c:10099 __might_sleep+0x12f/0x160\n\nmutex lock is not needed in ksmbd_durable_scavenger_alive().

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spi-imx: Add check for spi_imx_setupxfer()\n\nAdd check for the return value of spi_imx_setupxfer().\nspi_imx->rx and spi_imx->tx function pointer can be NULL when\nspi_imx_setupxfer() return error, and make NULL pointer dereference.\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Call trace:\n 0x0\n spi_imx_pio_transfer+0x50/0xd8\n spi_imx_transfer_one+0x18c/0x858\n spi_transfer_one_message+0x43c/0x790\n __spi_pump_transfer_message+0x238/0x5d4\n __spi_sync+0x2b0/0x454\n spi_write_then_read+0x11c/0x200

In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential NULL pointer dereference in dev_uevent()\n\nIf userspace reads "uevent" device attribute at the same time as another\nthreads unbinds the device from its driver, change to dev->driver from a\nvalid pointer to NULL may result in crash. Fix this by using READ_ONCE()\nwhen fetching the pointer, and take bus' drivers klist lock to make sure\ndriver instance will not disappear while we access it.\n\nUse WRITE_ONCE() when setting the driver pointer to ensure there is no\ntearing.

In the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp\n\nvmxnet3 driver's XDP handling is buggy for packet sizes using ring0 (that\nis, packet sizes between 128 - 3k bytes).\n\nWe noticed MTU-related connectivity issues with Cilium's service load-\nbalancing in case of vmxnet3 as NIC underneath. A simple curl to a HTTP\nbackend service where the XDP LB was doing IPIP encap led to overly large\npacket sizes but only for *some* of the packets (e.g. HTTP GET request)\nwhile others (e.g. the prior TCP 3WHS) looked completely fine on the wire.\n\nIn fact, the pcap recording on the backend node actually revealed that the\nnode with the XDP LB was leaking uninitialized kernel data onto the wire\nfor the affected packets, for example, while the packets should have been\n152 bytes their actual size was 1482 bytes, so the remainder after 152 bytes\nwas padded with whatever other data was in that page at the time (e.g. we\nsaw user/payload data from prior processed packets).\n\nWe only noticed this through an MTU issue, e.g. when the XDP LB node and\nthe backend node both had the same MTU (e.g. 1500) then the curl request\ngot dropped on the backend node's NIC given the packet was too large even\nthough the IPIP-encapped packet normally would never even come close to\nthe MTU limit. Lowering the MTU on the XDP LB (e.g. 1480) allowed to let\nthe curl request succeed (which also indicates that the kernel ignored the\npadding, and thus the issue wasn't very user-visible).\n\nCommit e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") was too eager\nto also switch xdp_prepare_buff() from rcd->len to rbi->len. It really needs\nto stick to rcd->len which is the actual packet length from the descriptor.\nThe latter we also feed into vmxnet3_process_xdp_small(), by the way, and\nit indicates the correct length needed to initialize the xdp->{data,data_end}\nparts. For e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") the\nrelevant part was adapting xdp_init_buff() to address the warning given the\nxdp_data_hard_end() depends on xdp->frame_sz. With that fixed, traffic on\nthe wire looks good again.

In the Linux kernel, the following vulnerability has been resolved:\n\ncodel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()\n\nAfter making all ->qlen_notify() callbacks idempotent, now it is safe to\nremove the check of qlen!=0 from both fq_codel_dequeue() and\ncodel_qdisc_dequeue().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class handling\n\nThis patch fixes a Use-After-Free vulnerability in the HFSC qdisc class\nhandling. The issue occurs due to a time-of-check/time-of-use condition\nin hfsc_change_class() when working with certain child qdiscs like netem\nor codel.\n\nThe vulnerability works as follows:\n1. hfsc_change_class() checks if a class has packets (q.qlen != 0)\n2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,\n codel, netem) might drop packets and empty the queue\n3. The code continues assuming the queue is still non-empty, adding\n the class to vttree\n4. This breaks HFSC scheduler assumptions that only non-empty classes\n are in vttree\n5. Later, when the class is destroyed, this can lead to a Use-After-Free\n\nThe fix adds a second queue length check after qdisc_peek_len() to verify\nthe queue wasn't emptied.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: at76c50x: fix use after free access in at76_disconnect\n\nThe memory pointed to by priv is freed at the end of at76_delete_device\nfunction (using ieee80211_free_hw). But the code then accesses the udev\nfield of the freed object to put the USB device. This may also lead to a\nmemory leak of the usb device. Fix this by using udev from interface.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Purge vif txq in ieee80211_do_stop()\n\nAfter ieee80211_do_stop() SKB from vif's txq could still be processed.\nIndeed another concurrent vif schedule_and_wake_txq call could cause\nthose packets to be dequeued (see ieee80211_handle_wake_tx_queue())\nwithout checking the sdata current state.\n\nBecause vif.drv_priv is now cleared in this function, this could lead to\ndriver crash.\n\nFor example in ath12k, ahvif is store in vif.drv_priv. Thus if\nath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be\nNULL, leading the ath12k_warn(ahvif->ah,...) call in this function to\ntrigger the NULL deref below.\n\n Unable to handle kernel paging request at virtual address dfffffc000000001\n KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n batman_adv: bat0: Interface deactivated: brbh1337\n Mem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\n Data abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n [dfffffc000000001] address between user and kernel address ranges\n Internal error: Oops: 0000000096000004 [#1] SMP\n CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114\n Hardware name: HW (DT)\n pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k]\n lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k]\n sp : ffffffc086ace450\n x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4\n x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e\n x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0\n x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958\n x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8\n x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03\n x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40\n x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0\n x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001\n x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008\n Call trace:\n ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P)\n ieee80211_handle_wake_tx_queue+0x16c/0x260\n ieee80211_queue_skb+0xeec/0x1d20\n ieee80211_tx+0x200/0x2c8\n ieee80211_xmit+0x22c/0x338\n __ieee80211_subif_start_xmit+0x7e8/0xc60\n ieee80211_subif_start_xmit+0xc4/0xee0\n __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0\n ieee80211_subif_start_xmit_8023+0x124/0x488\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n br_dev_queue_push_xmit+0x120/0x4a8\n __br_forward+0xe4/0x2b0\n deliver_clone+0x5c/0xd0\n br_flood+0x398/0x580\n br_dev_xmit+0x454/0x9f8\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n ip6_finish_output2+0xc28/0x1b60\n __ip6_finish_output+0x38c/0x638\n ip6_output+0x1b4/0x338\n ip6_local_out+0x7c/0xa8\n ip6_send_skb+0x7c/0x1b0\n ip6_push_pending_frames+0x94/0xd0\n rawv6_sendmsg+0x1a98/0x2898\n inet_sendmsg+0x94/0xe0\n __sys_sendto+0x1e4/0x308\n __arm64_sys_sendto+0xc4/0x140\n do_el0_svc+0x110/0x280\n el0_svc+0x20/0x60\n el0t_64_sync_handler+0x104/0x138\n el0t_64_sync+0x154/0x158\n\nTo avoid that, empty vif's txq at ieee80211_do_stop() so no packet could\nbe dequeued after ieee80211_do_stop() (new packets cannot be queued\nbecause SDATA_STATE_RUNNING is cleared at this point).

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\navs_component_probe() does not check for this case, which results in a\nNULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btrtl: Prevent potential NULL dereference\n\nThe btrtl_initialize() function checks that rtl_load_file() either\nhad an error or it loaded a zero length file. However, if it loaded\na zero length file then the error code is not set correctly. It\nresults in an error pointer vs NULL bug, followed by a NULL pointer\ndereference. This was detected by Smatch:\n\ndrivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'

In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: cmis_cdb: use correct rpl size in ethtool_cmis_module_poll()\n\nrpl is passed as a pointer to ethtool_cmis_module_poll(), so the correct\nsize of rpl is sizeof(*rpl) which should be just 1 byte. Using the\npointer size instead can cause stack corruption:\n\nKernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ethtool_cmis_wait_for_cond+0xf4/0x100\nCPU: 72 UID: 0 PID: 4440 Comm: kworker/72:2 Kdump: loaded Tainted: G OE 6.11.0 #24\nTainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\nHardware name: Dell Inc. PowerEdge R760/04GWWM, BIOS 1.6.6 09/20/2023\nWorkqueue: events module_flash_fw_work\nCall Trace:\n \n panic+0x339/0x360\n ? ethtool_cmis_wait_for_cond+0xf4/0x100\n ? __pfx_status_success+0x10/0x10\n ? __pfx_status_fail+0x10/0x10\n __stack_chk_fail+0x10/0x10\n ethtool_cmis_wait_for_cond+0xf4/0x100\n ethtool_cmis_cdb_execute_cmd+0x1fc/0x330\n ? __pfx_status_fail+0x10/0x10\n cmis_cdb_module_features_get+0x6d/0xd0\n ethtool_cmis_cdb_init+0x8a/0xd0\n ethtool_cmis_fw_update+0x46/0x1d0\n module_flash_fw_work+0x17/0xa0\n process_one_work+0x179/0x390\n worker_thread+0x239/0x340\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xcc/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mctp: Set SOCK_RCU_FREE\n\nBind lookup runs under RCU, so ensure that a socket doesn't go away in\nthe middle of a lookup.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix nested key length validation in the set() action\n\nIt's not safe to access nla_len(ovs_key) if the data is smaller than\nthe netlink header. Check that the attribute is OK first.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path\n\nIn the for loop used to allocate the loc_array and bmap for each port, a\nmemory leak is possible when the allocation for loc_array succeeds,\nbut the allocation for bmap fails. This is because when the control flow\ngoes to the label free_eth_finfo, only the allocations starting from\n(i-1)th iteration are freed.\n\nFix that by freeing the loc_array in the bmap allocation error path.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registered\n\nRussell King reports that a system with mv88e6xxx dereferences a NULL\npointer when unbinding this driver:\nhttps://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/\n\nThe crash seems to be in devlink_region_destroy(), which is not NULL\ntolerant but is given a NULL devlink global region pointer.\n\nAt least on some chips, some devlink regions are conditionally registered\nsince the blamed commit, see mv88e6xxx_setup_devlink_regions_global():\n\n if (cond && !cond(chip))\n continue;\n\nThese are MV88E6XXX_REGION_STU and MV88E6XXX_REGION_PVT. If the chip\ndoes not have an STU or PVT, it should crash like this.\n\nTo fix the issue, avoid unregistering those regions which are NULL, i.e.\nwere skipped at mv88e6xxx_setup_devlink_regions_global() time.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: free routing table on probe failure\n\nIf complete = true in dsa_tree_setup(), it means that we are the last\nswitch of the tree which is successfully probing, and we should be\nsetting up all switches from our probe path.\n\nAfter "complete" becomes true, dsa_tree_setup_cpu_ports() or any\nsubsequent function may fail. If that happens, the entire tree setup is\nin limbo: the first N-1 switches have successfully finished probing\n(doing nothing but having allocated persistent memory in the tree's\ndst->ports, and maybe dst->rtable), and switch N failed to probe, ending\nthe tree setup process before anything is tangible from the user's PoV.\n\nIf switch N fails to probe, its memory (ports) will be freed and removed\nfrom dst->ports. However, the dst->rtable elements pointing to its ports,\nas created by dsa_link_touch(), will remain there, and will lead to\nuse-after-free if dereferenced.\n\nIf dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely\npossible because that is where ds->ops->setup() is, we get a kasan\nreport like this:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568\nRead of size 8 at addr ffff000004f56020 by task kworker/u8:3/42\n\nCall trace:\n __asan_report_load8_noabort+0x20/0x30\n mv88e6xxx_setup_upstream_port+0x240/0x568\n mv88e6xxx_setup+0xebc/0x1eb0\n dsa_register_switch+0x1af4/0x2ae0\n mv88e6xxx_register_switch+0x1b8/0x2a8\n mv88e6xxx_probe+0xc4c/0xf60\n mdio_probe+0x78/0xb8\n really_probe+0x2b8/0x5a8\n __driver_probe_device+0x164/0x298\n driver_probe_device+0x78/0x258\n __device_attach_driver+0x274/0x350\n\nAllocated by task 42:\n __kasan_kmalloc+0x84/0xa0\n __kmalloc_cache_noprof+0x298/0x490\n dsa_switch_touch_ports+0x174/0x3d8\n dsa_register_switch+0x800/0x2ae0\n mv88e6xxx_register_switch+0x1b8/0x2a8\n mv88e6xxx_probe+0xc4c/0xf60\n mdio_probe+0x78/0xb8\n really_probe+0x2b8/0x5a8\n __driver_probe_device+0x164/0x298\n driver_probe_device+0x78/0x258\n __device_attach_driver+0x274/0x350\n\nFreed by task 42:\n __kasan_slab_free+0x48/0x68\n kfree+0x138/0x418\n dsa_register_switch+0x2694/0x2ae0\n mv88e6xxx_register_switch+0x1b8/0x2a8\n mv88e6xxx_probe+0xc4c/0xf60\n mdio_probe+0x78/0xb8\n really_probe+0x2b8/0x5a8\n __driver_probe_device+0x164/0x298\n driver_probe_device+0x78/0x258\n __device_attach_driver+0x274/0x350\n\nThe simplest way to fix the bug is to delete the routing table in its\nentirety. dsa_tree_setup_routing_table() has no problem in regenerating\nit even if we deleted links between ports other than those of switch N,\nbecause dsa_link_touch() first checks whether the port pair already\nexists in dst->rtable, allocating if not.\n\nThe deletion of the routing table in its entirety already exists in\ndsa_tree_teardown(), so refactor that into a function that can also be\ncalled from the tree setup error path.\n\nIn my analysis of the commit to blame, it is the one which added\ndsa_link elements to dst->rtable. Prior to that, each switch had its own\nds->rtable which is freed when the switch fails to probe. But the tree\nis potentially persistent memory.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains '.' dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least '.'\nand '..' as directory entries in the first data block. It first loads\nthe '.' dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of '..' dir\nentry (in ext4_next_entry). It assumes the '..' dir entry fits into the\nsame data block.\n\nIf the rec_len of '.' is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves "struct ext4_dir_entry_2 *de" point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for '.' dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ti: icss-iep: Fix possible NULL pointer dereference for perout request\n\nThe ICSS IEP driver tracks perout and pps enable state with flags.\nCurrently when disabling pps and perout signals during icss_iep_exit(),\nresults in NULL pointer dereference for perout.\n\nTo fix the null pointer dereference issue, the icss_iep_perout_enable_hw\nfunction can be modified to directly clear the IEP CMP registers when\ndisabling PPS or PEROUT, without referencing the ptp_perout_request\nstructure, as its contents are irrelevant in this case.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dpu: Fix error pointers in dpu_plane_virtual_atomic_check\n\nThe function dpu_plane_virtual_atomic_check was dereferencing pointers\nreturned by drm_atomic_get_plane_state without checking for errors. This\ncould lead to undefined behavior if the function returns an error pointer.\n\nThis commit adds checks using IS_ERR to ensure that plane_state is\nvalid before dereferencing them.\n\nSimilar to commit da29abe71e16\n("drm/amd/display: Fix error pointers in amdgpu_dm_crtc_mem_type_changed").\n\nPatchwork: https://patchwork.freedesktop.org/patch/643132/

In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: cros-ec-tunnel: defer probe if parent EC is not present\n\nWhen i2c-cros-ec-tunnel and the EC driver are built-in, the EC parent\ndevice will not be found, leading to NULL pointer dereference.\n\nThat can also be reproduced by unbinding the controller driver and then\nloading i2c-cros-ec-tunnel module (or binding the device).\n\n[ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058\n[ 271.998215] #PF: supervisor read access in kernel mode\n[ 272.003351] #PF: error_code(0x0000) - not-present page\n[ 272.008485] PGD 0 P4D 0\n[ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI\n[ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5\n[ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC\n[ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021\n[ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel]\n[ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9\n[ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282\n[ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000\n[ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00\n[ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000\n[ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000\n[ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10\n[ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000\n[ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0\n[ 272.129155] Call Trace:\n[ 272.131606] \n[ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110\n[ 272.137985] platform_probe+0x69/0xa0\n[ 272.141652] really_probe+0x152/0x310\n[ 272.145318] __driver_probe_device+0x77/0x110\n[ 272.149678] driver_probe_device+0x1e/0x190\n[ 272.153864] __driver_attach+0x10b/0x1e0\n[ 272.157790] ? driver_attach+0x20/0x20\n[ 272.161542] bus_for_each_dev+0x107/0x150\n[ 272.165553] bus_add_driver+0x15d/0x270\n[ 272.169392] driver_register+0x65/0x110\n[ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698]\n[ 272.182617] do_one_initcall+0x110/0x350\n[ 272.186543] ? security_kernfs_init_security+0x49/0xd0\n[ 272.191682] ? __kernfs_new_node+0x1b9/0x240\n[ 272.195954] ? security_kernfs_init_security+0x49/0xd0\n[ 272.201093] ? __kernfs_new_node+0x1b9/0x240\n[ 272.205365] ? kernfs_link_sibling+0x105/0x130\n[ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0\n[ 272.214773] ? kernfs_activate+0x57/0x70\n[ 272.218699] ? kernfs_add_one+0x118/0x160\n[ 272.222710] ? __kernfs_create_file+0x71/0xa0\n[ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110\n[ 272.232033] ? internal_create_group+0x453/0x4a0\n[ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0\n[ 272.241355] ? __free_frozen_pages+0x1dc/0x420\n[ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0\n[ 272.250505] ? load_module+0x1509/0x16f0\n[ 272.254431] do_init_module+0x60/0x230\n[ 272.258181] __se_sys_finit_module+0x27a/0x370\n[ 272.262627] do_syscall_64+0x6a/0xf0\n[ 272.266206] ? do_syscall_64+0x76/0xf0\n[ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90\n[ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d\n[ 272.279887] RIP: 0033:0x7b9309168d39\n[ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8\n[ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nisofs: Prevent the use of too small fid\n\nsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]\n\nThe handle_bytes value passed in by the reproducing program is equal to 12.\nIn handle_to_path(), only 12 bytes of memory are allocated for the structure\nfile_handle->f_handle member, which causes an out-of-bounds access when\naccessing the member parent_block of the structure isofs_fid in isofs,\nbecause accessing parent_block requires at least 16 bytes of f_handle.\nHere, fh_len is used to indirectly confirm that the value of handle_bytes\nis greater than 3 before accessing parent_block.\n\n[1]\nBUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\nRead of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466\nCPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nCall trace:\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0x198/0x550 mm/kasan/report.c:521\n kasan_report+0xd8/0x138 mm/kasan/report.c:634\n __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380\n isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\n exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523\n do_handle_to_path+0xa0/0x198 fs/fhandle.c:257\n handle_to_path fs/fhandle.c:385 [inline]\n do_handle_open+0x8cc/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n\nAllocated by task 6466:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4294 [inline]\n __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306\n kmalloc_noprof include/linux/slab.h:905 [inline]\n handle_to_path fs/fhandle.c:357 [inline]\n do_handle_open+0x5a4/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix dangling pointer in krb_authenticate\n\nkrb_authenticate frees sess->user and does not set the pointer\nto NULL. It calls ksmbd_krb5_authenticate to reinitialise\nsess->user but that function may return without doing so. If\nthat happens then smb2_sess_setup, which calls krb_authenticate,\nwill be accessing free'd memory when it later uses sess->user.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in __smb2_lease_break_noti()\n\nMove tcp_transport free to ksmbd_conn_free. If ksmbd connection is\nreferenced when ksmbd server thread terminates, It will not be freed,\nbut conn->tcp_transport is freed. __smb2_lease_break_noti can be performed\nasynchronously when the connection is disconnected. __smb2_lease_break_noti\ncalls ksmbd_conn_write, which can cause use-after-free\nwhen conn->ksmbd_transport is already freed.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.

In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn't allow writing to directory.

In the Linux kernel, the following vulnerability has been resolved:\n\nslab: ensure slab->obj_exts is clear in a newly allocated slab page\n\nktest recently reported crashes while running several buffered io tests\nwith __alloc_tagging_slab_alloc_hook() at the top of the crash call stack.\nThe signature indicates an invalid address dereference with low bits of\nslab->obj_exts being set. The bits were outside of the range used by\npage_memcg_data_flags and objext_flags and hence were not masked out\nby slab_obj_exts() when obtaining the pointer stored in slab->obj_exts.\nThe typical crash log looks like this:\n\n00510 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010\n00510 Mem abort info:\n00510 ESR = 0x0000000096000045\n00510 EC = 0x25: DABT (current EL), IL = 32 bits\n00510 SET = 0, FnV = 0\n00510 EA = 0, S1PTW = 0\n00510 FSC = 0x05: level 1 translation fault\n00510 Data abort info:\n00510 ISV = 0, ISS = 0x00000045, ISS2 = 0x00000000\n00510 CM = 0, WnR = 1, TnD = 0, TagAccess = 0\n00510 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n00510 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000104175000\n00510 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000\n00510 Internal error: Oops: 0000000096000045 [#1] SMP\n00510 Modules linked in:\n00510 CPU: 10 UID: 0 PID: 7692 Comm: cat Not tainted 6.15.0-rc1-ktest-g189e17946605 #19327 NONE\n00510 Hardware name: linux,dummy-virt (DT)\n00510 pstate: 20001005 (nzCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)\n00510 pc : __alloc_tagging_slab_alloc_hook+0xe0/0x190\n00510 lr : __kmalloc_noprof+0x150/0x310\n00510 sp : ffffff80c87df6c0\n00510 x29: ffffff80c87df6c0 x28: 000000000013d1ff x27: 000000000013d200\n00510 x26: ffffff80c87df9e0 x25: 0000000000000000 x24: 0000000000000001\n00510 x23: ffffffc08041953c x22: 000000000000004c x21: ffffff80c0002180\n00510 x20: fffffffec3120840 x19: ffffff80c4821000 x18: 0000000000000000\n00510 x17: fffffffec3d02f00 x16: fffffffec3d02e00 x15: fffffffec3d00700\n00510 x14: fffffffec3d00600 x13: 0000000000000200 x12: 0000000000000006\n00510 x11: ffffffc080bb86c0 x10: 0000000000000000 x9 : ffffffc080201e58\n00510 x8 : ffffff80c4821060 x7 : 0000000000000000 x6 : 0000000055555556\n00510 x5 : 0000000000000001 x4 : 0000000000000010 x3 : 0000000000000060\n00510 x2 : 0000000000000000 x1 : ffffffc080f50cf8 x0 : ffffff80d801d000\n00510 Call trace:\n00510 __alloc_tagging_slab_alloc_hook+0xe0/0x190 (P)\n00510 __kmalloc_noprof+0x150/0x310\n00510 __bch2_folio_create+0x5c/0xf8\n00510 bch2_folio_create+0x2c/0x40\n00510 bch2_readahead+0xc0/0x460\n00510 read_pages+0x7c/0x230\n00510 page_cache_ra_order+0x244/0x3a8\n00510 page_cache_async_ra+0x124/0x170\n00510 filemap_readahead.isra.0+0x58/0xa0\n00510 filemap_get_pages+0x454/0x7b0\n00510 filemap_read+0xdc/0x418\n00510 bch2_read_iter+0x100/0x1b0\n00510 vfs_read+0x214/0x300\n00510 ksys_read+0x6c/0x108\n00510 __arm64_sys_read+0x20/0x30\n00510 invoke_syscall.constprop.0+0x54/0xe8\n00510 do_el0_svc+0x44/0xc8\n00510 el0_svc+0x18/0x58\n00510 el0t_64_sync_handler+0x104/0x130\n00510 el0t_64_sync+0x154/0x158\n00510 Code: d5384100 f9401c01 b9401aa3 b40002e1 (f8227881)\n00510 ---[ end trace 0000000000000000 ]---\n00510 Kernel panic - not syncing: Oops: Fatal exception\n00510 SMP: stopping secondary CPUs\n00510 Kernel Offset: disabled\n00510 CPU features: 0x0000,000000e0,00000410,8240500b\n00510 Memory Limit: none\n\nInvestigation indicates that these bits are already set when we allocate\nslab page and are not zeroed out after allocation. We are not yet sure\nwhy these crashes start happening only recently but regardless of the\nreason, not initializing a field that gets used later is wrong. Fix it\nby initializing slab->obj_exts during slab page allocation.

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtiofs: add filesystem context source name check\n\nIn certain scenarios, for example, during fuzz testing, the source\nname may be NULL, which could lead to a kernel panic. Therefore, an\nextra check for the source name should be added.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix workqueue crash in cma_netevent_work_handler\n\nstruct rdma_cm_id has member "struct work_struct net_work"\nthat is reused for enqueuing cma_netevent_work_handler()s\nonto cma_wq.\n\nBelow crash[1] can occur if more than one call to\ncma_netevent_callback() occurs in quick succession,\nwhich further enqueues cma_netevent_work_handler()s for the\nsame rdma_cm_id, overwriting any previously queued work-item(s)\nthat was just scheduled to run i.e. there is no guarantee\nthe queued work item may run between two successive calls\nto cma_netevent_callback() and the 2nd INIT_WORK would overwrite\nthe 1st work item (for the same rdma_cm_id), despite grabbing\nid_table_lock during enqueue.\n\nAlso drgn analysis [2] indicates the work item was likely overwritten.\n\nFix this by moving the INIT_WORK() to __rdma_create_id(),\nso that it doesn't race with any existing queue_work() or\nits worker thread.\n\n[1] Trimmed crash stack:\n=============================================\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nkworker/u256:6 ... 6.12.0-0...\nWorkqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)\nRIP: 0010:process_one_work+0xba/0x31a\nCall Trace:\n worker_thread+0x266/0x3a0\n kthread+0xcf/0x100\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1a/0x30\n=============================================\n\n[2] drgn crash analysis:\n\n>>> trace = prog.crashed_thread().stack_trace()\n>>> trace\n(0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)\n(1) __crash_kexec (kernel/crash_core.c:122:4)\n(2) panic (kernel/panic.c:399:3)\n(3) oops_end (arch/x86/kernel/dumpstack.c:382:3)\n...\n(8) process_one_work (kernel/workqueue.c:3168:2)\n(9) process_scheduled_works (kernel/workqueue.c:3310:3)\n(10) worker_thread (kernel/workqueue.c:3391:4)\n(11) kthread (kernel/kthread.c:389:9)\n\nLine workqueue.c:3168 for this kernel version is in process_one_work():\n3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);\n\n>>> trace[8]["work"]\n*(struct work_struct *)0xffff92577d0a21d8 = {\n .data = (atomic_long_t){\n .counter = (s64)536870912, <=== Note\n },\n .entry = (struct list_head){\n .next = (struct list_head *)0xffff924d075924c0,\n .prev = (struct list_head *)0xffff924d075924c0,\n },\n .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,\n}\n\nSuspicion is that pwq is NULL:\n>>> trace[8]["pwq"]\n(struct pool_workqueue *)\n\nIn process_one_work(), pwq is assigned from:\nstruct pool_workqueue *pwq = get_work_pwq(work);\n\nand get_work_pwq() is:\nstatic struct pool_workqueue *get_work_pwq(struct work_struct *work)\n{\n unsigned long data = atomic_long_read(&work->data);\n\n if (data & WORK_STRUCT_PWQ)\n return work_struct_pwq(data);\n else\n return NULL;\n}\n\nWORK_STRUCT_PWQ is 0x4:\n>>> print(repr(prog['WORK_STRUCT_PWQ']))\nObject(prog, 'enum work_flags', value=4)\n\nBut work->data is 536870912 which is 0x20000000.\nSo, get_work_pwq() returns NULL and we crash in process_one_work():\n3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);\n=============================================

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: prime: fix ttm_bo_delayed_delete oops\n\nFix an oops in ttm_bo_delayed_delete which results from dererencing a\ndangling pointer:\n\nOops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP\nCPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216\nHardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024\nWorkqueue: ttm ttm_bo_delayed_delete [ttm]\nRIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290\nCode: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b\nRSP: 0018:ffffbf9383473d60 EFLAGS: 00010202\nRAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b\nR13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc\nFS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0\nPKRU: 55555554\nCall Trace:\n \n ? __die_body.cold+0x19/0x26\n ? die_addr+0x3d/0x70\n ? exc_general_protection+0x159/0x460\n ? asm_exc_general_protection+0x27/0x30\n ? dma_resv_iter_first_unlocked+0x55/0x290\n dma_resv_wait_timeout+0x56/0x100\n ttm_bo_delayed_delete+0x69/0xb0 [ttm]\n process_one_work+0x217/0x5c0\n worker_thread+0x1c8/0x3d0\n ? apply_wqattrs_cleanup.part.0+0xc0/0xc0\n kthread+0x10b/0x240\n ? kthreads_online_cpu+0x140/0x140\n ret_from_fork+0x40/0x70\n ? kthreads_online_cpu+0x140/0x140\n ret_from_fork_asm+0x11/0x20\n \n\nThe cause of this is:\n\n- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the\n reference to the shared dma_buf. The reference count is 0, so the\n dma_buf is destroyed, which in turn decrements the corresponding\n amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed -\n calling drm_gem_object_release then dma_resv_fini (which destroys the\n reservation object), then finally freeing the amdgpu_bo.\n\n- nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory\n formerly allocated to the amdgpu_bo.\n\n- nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls\n ttm_bo_release, which schedules ttm_bo_delayed_delete.\n\n- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer,\n resulting in a general protection fault.\n\nFix this by moving the drm_prime_gem_destroy call from\nnouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will\nbe run after ttm_bo_delayed_delete.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: take paired job reference\n\nFor paired jobs, have the fragment job take a reference on the\ngeometry job, so that the geometry job cannot be freed until\nthe fragment job has finished with it.\n\nThe geometry job structure is accessed when the fragment job is being\nprepared by the GPU scheduler. Taking the reference prevents the\ngeometry job being freed until the fragment job no longer requires it.\n\nFixes a use after free bug detected by KASAN:\n\n[ 124.256386] BUG: KASAN: slab-use-after-free in pvr_queue_prepare_job+0x108/0x868 [powervr]\n[ 124.264893] Read of size 1 at addr ffff0000084cb960 by task kworker/u16:4/63

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: Fix missed dmabuf unpinning in error path of prepare_fb()\n\nCorrect error handling in prepare_fb() to fix leaking resources when\nerror happens.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix an out-of-bounds shift when invalidating TLB\n\nWhen the size of the range invalidated is larger than\nrounddown_pow_of_two(ULONG_MAX),\nThe function macro roundup_pow_of_two(length) will hit an out-of-bounds\nshift [1].\n\nUse a full TLB invalidation for such cases.\nv2:\n- Use a define for the range size limit over which we use a full\n TLB invalidation. (Lucas)\n- Use a better calculation of the limit.\n\n[1]:\n[ 39.202421] ------------[ cut here ]------------\n[ 39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13\n[ 39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int'\n[ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G U 6.14.0+ #10\n[ 39.202690] Tainted: [U]=USER\n[ 39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023\n[ 39.202691] Call Trace:\n[ 39.202692] \n[ 39.202695] dump_stack_lvl+0x6e/0xa0\n[ 39.202699] ubsan_epilogue+0x5/0x30\n[ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6\n[ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe]\n[ 39.202800] ? find_held_lock+0x2b/0x80\n[ 39.202803] ? mark_held_locks+0x40/0x70\n[ 39.202806] xe_svm_invalidate+0x459/0x700 [xe]\n[ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm]\n[ 39.202900] __mmu_notifier_release+0x1f5/0x270\n[ 39.202905] exit_mmap+0x40e/0x450\n[ 39.202912] __mmput+0x45/0x110\n[ 39.202914] exit_mm+0xc5/0x130\n[ 39.202916] do_exit+0x21c/0x500\n[ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190\n[ 39.202920] do_group_exit+0x36/0xa0\n[ 39.202922] get_signal+0x8f8/0x900\n[ 39.202926] arch_do_signal_or_restart+0x35/0x100\n[ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290\n[ 39.202932] do_syscall_64+0xa1/0x180\n[ 39.202934] ? do_user_addr_fault+0x59f/0x8a0\n[ 39.202937] ? lock_release+0xd2/0x2a0\n[ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0\n[ 39.202942] ? trace_hardirqs_off+0x4b/0xc0\n[ 39.202944] ? clear_bhb_loop+0x25/0x80\n[ 39.202946] ? clear_bhb_loop+0x25/0x80\n[ 39.202947] ? clear_bhb_loop+0x25/0x80\n[ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 39.202952] RIP: 0033:0x7fa945e543e1\n[ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7.\n[ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293\n[ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3\n[ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff\n[ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0\n[ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000\n[ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000\n[ 39.202970] \n[ 39.202970] ---[ end trace ]---\n\n(cherry picked from commit b88f48f86500bc0b44b4f73ac66d500a40d320ad)

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vma: add give_up_on_oom option on modify/merge, use in uffd release\n\nCurrently, if a VMA merge fails due to an OOM condition arising on commit\nmerge or a failure to duplicate anon_vma's, we report this so the caller\ncan handle it.\n\nHowever there are cases where the caller is only ostensibly trying a\nmerge, and doesn't mind if it fails due to this condition.\n\nSince we do not want to introduce an implicit assumption that we only\nactually modify VMAs after OOM conditions might arise, add a 'give up on\noom' option and make an explicit contract that, should this flag be set, we\nabsolutely will not modify any VMAs should OOM arise and just bail out.\n\nSince it'd be very unusual for a user to try to vma_modify() with this flag\nset but be specifying a range within a VMA which ends up being split (which\ncan fail due to rlimit issues, not only OOM), we add a debug warning for\nthis condition.\n\nThe motivating reason for this is uffd release - syzkaller (and Pedro\nFalcato's VERY astute analysis) found a way in which an injected fault on\nallocation, triggering an OOM condition on commit merge, would result in\nuffd code becoming confused and treating an error value as if it were a VMA\npointer.\n\nTo avoid this, we make use of this new VMG flag to ensure that this never\noccurs, utilising the fact that, should we be clearing entire VMAs, we do\nnot wish an OOM event to be reported to us.\n\nMany thanks to Pedro Falcato for his excellent analysis and Jann Horn for\nhis insightful and intelligent analysis of the situation, both of whom were\ninstrumental in this fix.

In the Linux kernel, the following vulnerability has been resolved:\n\nublk: fix handling recovery & reissue in ublk_abort_queue()\n\nCommit 8284066946e6 ("ublk: grab request reference when the request is handled\nby userspace") doesn't grab request reference in case of recovery reissue.\nThen the request can be requeued & re-dispatch & failed when canceling\nuring command.\n\nIf it is one zc request, the request can be freed before io_uring\nreturns the zc buffer back, then cause kernel panic:\n\n[ 126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8\n[ 126.773657] #PF: supervisor read access in kernel mode\n[ 126.774052] #PF: error_code(0x0000) - not-present page\n[ 126.774455] PGD 0 P4D 0\n[ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI\n[ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ #182 PREEMPT(full)\n[ 126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014\n[ 126.776275] Workqueue: iou_exit io_ring_exit_work\n[ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv]\n\nFixes it by always grabbing request reference for aborting the request.

In the Linux kernel, the following vulnerability has been resolved:\n\nata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe()\n\ndevm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does\nnot check for this case, which can result in a NULL pointer dereference.\n\nAdd NULL check after devm_ioremap() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix memory leak in tipc_link_xmit\n\nIn case the backlog transmit queue for system-importance messages is overloaded,\ntipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to\nmemory leak and failure when a skb is allocated.\n\nThis commit fixes this issue by purging the skb list before tipc_link_xmit()\nreturns.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we'd need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that's just the easiest bug to trigger:\n\n WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n Call Trace:\n \n tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n sock_recvmsg_nosec net/socket.c:1023 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1045\n __sys_recvfrom+0x202/0x380 net/socket.c:2237

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: libwx: handle page_pool_dev_alloc_pages error\n\npage_pool_dev_alloc_pages could return NULL. There was a WARN_ON(!page)\nbut it would still proceed to use the NULL pointer and then crash.\n\nThis is similar to commit 001ba0902046\n("net: fec: handle page_pool_dev_alloc_pages error").\n\nThis is found by our static analysis tool KNighter.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/huc: Fix fence not released on early probe errors\n\nHuC delayed loading fence, introduced with commit 27536e03271da\n("drm/i915/huc: track delayed HuC load with a fence"), is registered with\nobject tracker early on driver probe but unregistered only from driver\nremove, which is not called on early probe errors. Since its memory is\nallocated under devres, then released anyway, it may happen to be\nallocated again to the fence and reused on future driver probes, resulting\nin kernel warnings that taint the kernel:\n\n<4> [309.731371] ------------[ cut here ]------------\n<3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915]\n<4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0\n...\n<4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1\n...\n<4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0\n...\n<4> [309.731728] Call Trace:\n<4> [309.731730] \n...\n<4> [309.731949] __debug_object_init+0x17b/0x1c0\n<4> [309.731957] debug_object_init+0x34/0x50\n<4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915]\n<4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915]\n<4> [309.732468] intel_uc_init_early+0x61/0x680 [i915]\n<4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915]\n<4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915]\n<4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915]\n<4> [309.733075] i915_pci_probe+0xe6/0x220 [i915]\n<4> [309.733198] local_pci_probe+0x44/0xb0\n<4> [309.733203] pci_device_probe+0xf4/0x270\n<4> [309.733209] really_probe+0xee/0x3c0\n<4> [309.733215] __driver_probe_device+0x8c/0x180\n<4> [309.733219] driver_probe_device+0x24/0xd0\n<4> [309.733223] __driver_attach+0x10f/0x220\n<4> [309.733230] bus_for_each_dev+0x7d/0xe0\n<4> [309.733236] driver_attach+0x1e/0x30\n<4> [309.733239] bus_add_driver+0x151/0x290\n<4> [309.733244] driver_register+0x5e/0x130\n<4> [309.733247] __pci_register_driver+0x7d/0x90\n<4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915]\n<4> [309.733413] i915_init+0x34/0x120 [i915]\n<4> [309.733655] do_one_initcall+0x62/0x3f0\n<4> [309.733667] do_init_module+0x97/0x2a0\n<4> [309.733671] load_module+0x25ff/0x2890\n<4> [309.733688] init_module_from_file+0x97/0xe0\n<4> [309.733701] idempotent_init_module+0x118/0x330\n<4> [309.733711] __x64_sys_finit_module+0x77/0x100\n<4> [309.733715] x64_sys_call+0x1f37/0x2650\n<4> [309.733719] do_syscall_64+0x91/0x180\n<4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n<4> [309.733792] \n...\n<4> [309.733806] ---[ end trace 0000000000000000 ]---\n\nThat scenario is most easily reproducible with\nigt@i915_module_load@reload-with-fault-injection.\n\nFix the issue by moving the cleanup step to driver release path.\n\n(cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: move the limit validation\n\nIt is not sufficient to directly validate the limit on the data that\nthe user passes as it can be updated based on how the other parameters\nare changed.\n\nMove the check at the end of the configuration update process to also\ncatch scenarios where the limit is indirectly updated, for example\nwith the following configurations:\n\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1\n\nThis fixes the following syzkaller reported crash:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6\nindex 65535 is out of range for type 'struct sfq_head[128]'\nCPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024\nCall Trace:\n \n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429\n sfq_link net/sched/sch_sfq.c:203 [inline]\n sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231\n sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493\n sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311\n netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]\n dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/cpu: Avoid running off the end of an AMD erratum table\n\nThe NULL array terminator at the end of erratum_1386_microcode was\nremoved during the switch from x86_cpu_desc to x86_cpu_id. This\ncauses readers to run off the end of the array.\n\nReplace the NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix UAF in decryption with multichannel\n\nAfter commit f7025d861694 ("smb: client: allocate crypto only for\nprimary server") and commit b0abcd65ec54 ("smb: client: fix UAF in\nasync decryption"), the channels started reusing AEAD TFM from primary\nchannel to perform synchronous decryption, but that can't done as\nthere could be multiple cifsd threads (one per channel) simultaneously\naccessing it to perform decryption.\n\nThis fixes the following KASAN splat when running fstest generic/249\nwith 'vers=3.1.1,multichannel,max_channels=4,seal' against Windows\nServer 2022:\n\nBUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110\nRead of size 8 at addr ffff8881046c18a0 by task cifsd/986\nCPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1\nPREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41\n04/01/2014\nCall Trace:\n \n dump_stack_lvl+0x5d/0x80\n print_report+0x156/0x528\n ? gf128mul_4k_lle+0xba/0x110\n ? __virt_addr_valid+0x145/0x300\n ? __phys_addr+0x46/0x90\n ? gf128mul_4k_lle+0xba/0x110\n kasan_report+0xdf/0x1a0\n ? gf128mul_4k_lle+0xba/0x110\n gf128mul_4k_lle+0xba/0x110\n ghash_update+0x189/0x210\n shash_ahash_update+0x295/0x370\n ? __pfx_shash_ahash_update+0x10/0x10\n ? __pfx_shash_ahash_update+0x10/0x10\n ? __pfx_extract_iter_to_sg+0x10/0x10\n ? ___kmalloc_large_node+0x10e/0x180\n ? __asan_memset+0x23/0x50\n crypto_ahash_update+0x3c/0xc0\n gcm_hash_assoc_remain_continue+0x93/0xc0\n crypt_message+0xe09/0xec0 [cifs]\n ? __pfx_crypt_message+0x10/0x10 [cifs]\n ? _raw_spin_unlock+0x23/0x40\n ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs]\n decrypt_raw_data+0x229/0x380 [cifs]\n ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]\n ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs]\n smb3_receive_transform+0x837/0xc80 [cifs]\n ? __pfx_smb3_receive_transform+0x10/0x10 [cifs]\n ? __pfx___might_resched+0x10/0x10\n ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs]\n cifs_demultiplex_thread+0x692/0x1570 [cifs]\n ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]\n ? rcu_is_watching+0x20/0x50\n ? rcu_lockdep_current_cpu_online+0x62/0xb0\n ? find_held_lock+0x32/0x90\n ? kvm_sched_clock_read+0x11/0x20\n ? local_clock_noinstr+0xd/0xd0\n ? trace_irq_enable.constprop.0+0xa8/0xe0\n ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]\n kthread+0x1fe/0x380\n ? kthread+0x10f/0x380\n ? __pfx_kthread+0x10/0x10\n ? local_clock_noinstr+0xd/0xd0\n ? ret_from_fork+0x1b/0x60\n ? local_clock+0x15/0x30\n ? lock_release+0x29b/0x390\n ? rcu_is_watching+0x20/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x60\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n