In the Linux kernel, the following vulnerability has been resolved:\nwifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi\nIn certain cases, hardware might provide packets with a\nlength greater than the maximum native Wi-Fi header length.\nThis can lead to accessing and modifying fields in the header\nwithin the ath12k_dp_rx_h_undecap_nwifi function for\nDP_RX_DECAP_TYPE_NATIVE_WIFI decap type and\npotentially resulting in invalid data access and memory corruption.\nAdd a sanity check before processing the SKB to prevent invalid\ndata access in the undecap native Wi-Fi function for the\nDP_RX_DECAP_TYPE_NATIVE_WIFI decap type.\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\nsch_htb: make htb_qlen_notify() idempotent\nhtb_qlen_notify() always deactivates the HTB class and in fact could\ntrigger a warning if it is already deactivated. Therefore, it is not\nidempotent and not friendly to its callers, like fq_codel_dequeue().\nLet's make it idempotent to ease qdisc_tree_reduce_backlog() callers'\nlife.

In the Linux kernel, the following vulnerability has been resolved:\nice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()\nAs mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI\npointer values"), we need to perform a null pointer check on the return\nvalue of ice_get_vf_vsi() before using it.

The C++ method SignTraits::DeriveBits() may incorrectly call ThrowException() based on user-supplied inputs when executing in a background thread, crashing the Node.js process. Such cryptographic operations are commonly applied to untrusted inputs. Thus, this mechanism potentially allows an adversary to remotely crash a Node.js runtime.

A heap buffer overflow vulnerability was discovered in Perl. \nRelease branches 5.34, 5.36, 5.38 and 5.40 are affected, including development versions from 5.33.1 through 5.41.10.

containerd is a container runtime. A time-of-check to time-of-use (TOCTOU) vulnerability was found in containerd v2.1.0. While unpacking an image during an image pull, specially crafted container images could arbitrarily modify the host file system. The only affected version of containerd is 2.1.0. Other versions of containerd are not affected. This bug has been fixed in containerd 2.1.1. Users should update to this version to resolve the issue. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: light: Add check for array bounds in veml6075_read_int_time_ms\n\nThe array contains only 5 elements, but the index calculated by\nveml6075_read_int_time_index can range from 0 to 7,\nwhich could lead to out-of-bounds access. The check prevents this issue.\n\nCoverity Issue\nCID 1574309: (#1 of 1): Out-of-bounds read (OVERRUN)\noverrun-local: Overrunning array veml6075_it_ms of 5 4-byte\nelements at element index 7 (byte offset 31) using\nindex int_index (which evaluates to 7)\n\nThis is hardening against potentially broken hardware. Good to have\nbut not necessary to backport.

In the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()\n\nIf speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the\nentire amd_spi_freq array without breaking out early, causing 'i' to go\nbeyond the array bounds.\n\nFix that by stopping the loop when it gets to the last entry, so the low\nspeed_hz value gets clamped up to AMD_SPI_MIN_HZ.\n\nFixes the following warning with an UBSAN kernel:\n\n drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mce: use is_copy_from_user() to determine copy-from-user context\n\nPatch series "mm/hwpoison: Fix regressions in memory failure handling",\nv4.\n\n## 1. What am I trying to do:\n\nThis patchset resolves two critical regressions related to memory failure\nhandling that have appeared in the upstream kernel since version 5.17, as\ncompared to 5.10 LTS.\n\n - copyin case: poison found in user page while kernel copying from user space\n - instr case: poison found while instruction fetching in user space\n\n## 2. What is the expected outcome and why\n\n- For copyin case:\n\nKernel can recover from poison found where kernel is doing get_user() or\ncopy_from_user() if those places get an error return and the kernel return\n-EFAULT to the process instead of crashing. More specifily, MCE handler\nchecks the fixup handler type to decide whether an in kernel #MC can be\nrecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code\nspecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.\n\n- For instr case:\n\nIf a poison found while instruction fetching in user space, full recovery\nis possible. User process takes #PF, Linux allocates a new page and fills\nby reading from storage.\n\n\n## 3. What actually happens and why\n\n- For copyin case: kernel panic since v5.17\n\nCommit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new\nextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the\nextable fixup type for copy-from-user operations, changing it from\nEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS\nhandling when posion found in get_user() or copy_from_user().\n\n- For instr case: user process is killed by a SIGBUS signal due to #CMCI\n and #MCE race\n\nWhen an uncorrected memory error is consumed there is a race between the\nCMCI from the memory controller reporting an uncorrected error with a UCNA\nsignature, and the core reporting and SRAR signature machine check when\nthe data is about to be consumed.\n\n### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]\n\nPrior to Icelake memory controllers reported patrol scrub events that\ndetected a previously unseen uncorrected error in memory by signaling a\nbroadcast machine check with an SRAO (Software Recoverable Action\nOptional) signature in the machine check bank. This was overkill because\nit's not an urgent problem that no core is on the verge of consuming that\nbad data. It's also found that multi SRAO UCE may cause nested MCE\ninterrupts and finally become an IERR.\n\nHence, Intel downgrades the machine check bank signature of patrol scrub\nfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to\n#CMCI. Just to add to the confusion, Linux does take an action (in\nuc_decode_notifier()) to try to offline the page despite the UC*NA*\nsignature name.\n\n### Background: why #CMCI and #MCE race when poison is consuming in\n Intel platform [1]\n\nHaving decided that CMCI/UCNA is the best action for patrol scrub errors,\nthe memory controller uses it for reads too. But the memory controller is\nexecuting asynchronously from the core, and can't tell the difference\nbetween a "real" read and a speculative read. So it will do CMCI/UCNA if\nan error is found in any read.\n\nThus:\n\n1) Core is clever and thinks address A is needed soon, issues a\n speculative read.\n\n2) Core finds it is going to use address A soon after sending the read\n request\n\n3) The CMCI from the memory controller is in a race with MCE from the\n core that will soon try to retire the load from address A.\n\nQuite often (because speculation has got better) the CMCI from the memory\ncontroller is delivered before the core is committed to the instruction\nreading address A, so the interrupt is taken, and Linux offlines the page\n(marking it as poison).\n\n\n## Why user process is killed for instr case\n\nCommit 046545a661af ("mm/hwpoison: fix error page recovered but reported\n"not\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: simple-card-utils: Don't use __free(device_node) at graph_util_parse_dai()\n\ncommit 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for\ndevice node") uses __free(device_node) for dlc->of_node, but we need to\nkeep it while driver is in use.\n\nDon't use __free(device_node) in graph_util_parse_dai().

In the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, nvmet: Fix out-of-bounds stack access in nvmet_ctrl_state_show()\n\nThe csts_state_names[] array only has six sparse entries, but the\niteration code in nvmet_ctrl_state_show() iterates seven, resulting in a\npotential out-of-bounds stack read. Fix that.\n\nFixes the following warning with an UBSAN kernel:\n\n vmlinux.o: warning: objtool: .text.nvmet_ctrl_state_show: unexpected end of section

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: gpib: Fix cb7210 pcmcia Oops\n\nThe pcmcia_driver struct was still only using the old .name\ninitialization in the drv field. This led to a NULL pointer\nderef Oops in strcmp called from pcmcia_register_driver.\n\nInitialize the pcmcia_driver struct name field.

In the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix slab-out-of-bounds read in ea_get()\n\nDuring the "size_check" label in ea_get(), the code checks if the extended\nattribute list (xattr) size matches ea_size. If not, it logs\n"ea_get: invalid extended attribute" and calls print_hex_dump().\n\nHere, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds\nINT_MAX (2,147,483,647). Then ea_size is clamped:\n\n int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr));\n\nAlthough clamp_t aims to bound ea_size between 0 and 4110417968, the upper\nlimit is treated as an int, causing an overflow above 2^31 - 1. This leads\n"size" to wrap around and become negative (-184549328).\n\nThe "size" is then passed to print_hex_dump() (called "len" in\nprint_hex_dump()), it is passed as type size_t (an unsigned\ntype), this is then stored inside a variable called\n"int remaining", which is then assigned to "int linelen" which\nis then passed to hex_dump_to_buffer(). In print_hex_dump()\nthe for loop, iterates through 0 to len-1, where len is\n18446744073525002176, calling hex_dump_to_buffer()\non each iteration:\n\n for (i = 0; i < len; i += rowsize) {\n linelen = min(remaining, rowsize);\n remaining -= rowsize;\n\n hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,\n linebuf, sizeof(linebuf), ascii);\n\n ...\n }\n\nThe expected stopping condition (i < len) is effectively broken\nsince len is corrupted and very large. This eventually leads to\nthe "ptr+i" being passed to hex_dump_to_buffer() to get closer\nto the end of the actual bounds of "ptr", eventually an out of\nbounds access is done in hex_dump_to_buffer() in the following\nfor loop:\n\n for (j = 0; j < len; j++) {\n if (linebuflen < lx + 2)\n goto overflow2;\n ch = ptr[j];\n ...\n }\n\nTo fix this we should validate "EALIST_SIZE(ea_buf->xattr)"\nbefore it is utilised.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: samsung: Fix UBSAN panic in samsung_clk_init()\n\nWith UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to\ndereferencing `ctx->clk_data.hws` before setting\n`ctx->clk_data.num = nr_clks`. Move that up to fix the crash.\n\n UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP\n \n Call trace:\n samsung_clk_init+0x110/0x124 (P)\n samsung_clk_init+0x48/0x124 (L)\n samsung_cmu_register_one+0x3c/0xa0\n exynos_arm64_register_cmu+0x54/0x64\n __gs101_cmu_top_of_clk_init_declare+0x28/0x60\n ...

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: allow SC_STATUS_FREEABLE when searching via nfs4_lookup_stateid()\n\nThe pynfs DELEG8 test fails when run against nfsd. It acquires a\ndelegation and then lets the lease time out. It then tries to use the\ndeleg stateid and expects to see NFS4ERR_DELEG_REVOKED, but it gets\nbad NFS4ERR_BAD_STATEID instead.\n\nWhen a delegation is revoked, it's initially marked with\nSC_STATUS_REVOKED, or SC_STATUS_ADMIN_REVOKED and later, it's marked\nwith the SC_STATUS_FREEABLE flag, which denotes that it is waiting for\ns FREE_STATEID call.\n\nnfs4_lookup_stateid() accepts a statusmask that includes the status\nflags that a found stateid is allowed to have. Currently, that mask\nnever includes SC_STATUS_FREEABLE, which means that revoked delegations\nare (almost) never found.\n\nAdd SC_STATUS_FREEABLE to the always-allowed status flags, and remove it\nfrom nfsd4_delegreturn() since it's now always implied.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: skbprio: Remove overly strict queue assertions\n\nIn the current implementation, skbprio enqueue/dequeue contains an assertion\nthat fails under certain conditions when SKBPRIO is used as a child qdisc under\nTBF with specific parameters. The failure occurs because TBF sometimes peeks at\npackets in the child qdisc without actually dequeuing them when tokens are\nunavailable.\n\nThis peek operation creates a discrepancy between the parent and child qdisc\nqueue length counters. When TBF later receives a high-priority packet,\nSKBPRIO's queue length may show a different value than what's reflected in its\ninternal priority queue tracking, triggering the assertion.\n\nThe fix removes this overly strict assertions in SKBPRIO, they are not\nnecessary at all.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-edma: free irq correctly in remove path\n\nAdd fsl_edma->txirq/errirq check to avoid below warning because no\nerrirq at i.MX9 platform. Otherwise there will be kernel dump:\nWARNING: CPU: 0 PID: 11 at kernel/irq/devres.c:144 devm_free_irq+0x74/0x80\nModules linked in:\nCPU: 0 UID: 0 PID: 11 Comm: kworker/u8:0 Not tainted 6.12.0-rc7#18\nHardware name: NXP i.MX93 11X11 EVK board (DT)\nWorkqueue: events_unbound deferred_probe_work_func\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : devm_free_irq+0x74/0x80\nlr : devm_free_irq+0x48/0x80\nCall trace:\n devm_free_irq+0x74/0x80 (P)\n devm_free_irq+0x48/0x80 (L)\n fsl_edma_remove+0xc4/0xc8\n platform_remove+0x28/0x44\n device_remove+0x4c/0x80

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: dp: drm_err => dev_err in HPD path to avoid NULL ptr\n\nThe function mtk_dp_wait_hpd_asserted() may be called before the\n`mtk_dp->drm_dev` pointer is assigned in mtk_dp_bridge_attach().\nSpecifically it can be called via this callpath:\n - mtk_edp_wait_hpd_asserted\n - [panel probe]\n - dp_aux_ep_probe\n\nUsing "drm" level prints anywhere in this callpath causes a NULL\npointer dereference. Change the error message directly in\nmtk_dp_wait_hpd_asserted() to dev_err() to avoid this. Also change the\nerror messages in mtk_dp_parse_capabilities(), which is called by\nmtk_dp_wait_hpd_asserted().\n\nWhile touching these prints, also add the error code to them to make\nfuture debugging easier.

In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Clear table_sz when rproc_shutdown\n\nThere is case as below could trigger kernel dump:\nUse U-Boot to start remote processor(rproc) with resource table\npublished to a fixed address by rproc. After Kernel boots up,\nstop the rproc, load a new firmware which doesn't have resource table\n,and start rproc.\n\nWhen starting rproc with a firmware not have resource table,\n`memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will\ntrigger dump, because rproc->cache_table is set to NULL during the last\nstop operation, but rproc->table_sz is still valid.\n\nThis issue is found on i.MX8MP and i.MX9.\n\nDump as below:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\nMem 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\nData 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\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000\n[0000000000000000] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in:\nCPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38\nHardware name: NXP i.MX8MPlus EVK board (DT)\npstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __pi_memcpy_generic+0x110/0x22c\nlr : rproc_start+0x88/0x1e0\nCall trace:\n __pi_memcpy_generic+0x110/0x22c (P)\n rproc_boot+0x198/0x57c\n state_store+0x40/0x104\n dev_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x120/0x1cc\n vfs_write+0x240/0x378\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x30/0xcc\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n\nClear rproc->table_sz to address the issue.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Replace Mutex with Spinlock for RLCG register access to avoid Priority Inversion in SRIOV\n\nRLCG Register Access is a way for virtual functions to safely access GPU\nregisters in a virtualized environment., including TLB flushes and\nregister reads. When multiple threads or VFs try to access the same\nregisters simultaneously, it can lead to race conditions. By using the\nRLCG interface, the driver can serialize access to the registers. This\nmeans that only one thread can access the registers at a time,\npreventing conflicts and ensuring that operations are performed\ncorrectly. Additionally, when a low-priority task holds a mutex that a\nhigh-priority task needs, ie., If a thread holding a spinlock tries to\nacquire a mutex, it can lead to priority inversion. register access in\namdgpu_virt_rlcg_reg_rw especially in a fast code path is critical.\n\nThe call stack shows that the function amdgpu_virt_rlcg_reg_rw is being\ncalled, which attempts to acquire the mutex. This function is invoked\nfrom amdgpu_sriov_wreg, which in turn is called from\ngmc_v11_0_flush_gpu_tlb.\n\nThe [ BUG: Invalid wait context ] indicates that a thread is trying to\nacquire a mutex while it is in a context that does not allow it to sleep\n(like holding a spinlock).\n\nFixes the below:\n\n[ 253.013423] =============================\n[ 253.013434] [ BUG: Invalid wait context ]\n[ 253.013446] 6.12.0-amdstaging-drm-next-lol-050225 #14 Tainted: G U OE\n[ 253.013464] -----------------------------\n[ 253.013475] kworker/0:1/10 is trying to lock:\n[ 253.013487] ffff9f30542e3cf8 (&adev->virt.rlcg_reg_lock){+.+.}-{3:3}, at: amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]\n[ 253.013815] other info that might help us debug this:\n[ 253.013827] context-{4:4}\n[ 253.013835] 3 locks held by kworker/0:1/10:\n[ 253.013847] #0: ffff9f3040050f58 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x3f5/0x680\n[ 253.013877] #1: ffffb789c008be40 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: process_one_work+0x1d6/0x680\n[ 253.013905] #2: ffff9f3054281838 (&adev->gmc.invalidate_lock){+.+.}-{2:2}, at: gmc_v11_0_flush_gpu_tlb+0x198/0x4f0 [amdgpu]\n[ 253.014154] stack backtrace:\n[ 253.014164] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G U OE 6.12.0-amdstaging-drm-next-lol-050225 #14\n[ 253.014189] Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n[ 253.014203] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/18/2024\n[ 253.014224] Workqueue: events work_for_cpu_fn\n[ 253.014241] Call Trace:\n[ 253.014250] \n[ 253.014260] dump_stack_lvl+0x9b/0xf0\n[ 253.014275] dump_stack+0x10/0x20\n[ 253.014287] __lock_acquire+0xa47/0x2810\n[ 253.014303] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 253.014321] lock_acquire+0xd1/0x300\n[ 253.014333] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]\n[ 253.014562] ? __lock_acquire+0xa6b/0x2810\n[ 253.014578] __mutex_lock+0x85/0xe20\n[ 253.014591] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]\n[ 253.014782] ? sched_clock_noinstr+0x9/0x10\n[ 253.014795] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 253.014808] ? local_clock_noinstr+0xe/0xc0\n[ 253.014822] ? amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]\n[ 253.015012] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 253.015029] mutex_lock_nested+0x1b/0x30\n[ 253.015044] ? mutex_lock_nested+0x1b/0x30\n[ 253.015057] amdgpu_virt_rlcg_reg_rw+0xf6/0x330 [amdgpu]\n[ 253.015249] amdgpu_sriov_wreg+0xc5/0xd0 [amdgpu]\n[ 253.015435] gmc_v11_0_flush_gpu_tlb+0x44b/0x4f0 [amdgpu]\n[ 253.015667] gfx_v11_0_hw_init+0x499/0x29c0 [amdgpu]\n[ 253.015901] ? __pfx_smu_v13_0_update_pcie_parameters+0x10/0x10 [amdgpu]\n[ 253.016159] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 253.016173] ? smu_hw_init+0x18d/0x300 [amdgpu]\n[ 253.016403] amdgpu_device_init+0x29ad/0x36a0 [amdgpu]\n[ 253.016614] amdgpu_driver_load_kms+0x1a/0xc0 [amdgpu]\n[ 253.0170\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors\n\nCommit\n\n 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid")\n\nadded logic that causes resctrl to search for the CLOSID with the fewest dirty\ncache lines when creating a new control group, if requested by the arch code.\nThis depends on the values read from the llc_occupancy counters. The logic is\napplicable to architectures where the CLOSID effectively forms part of the\nmonitoring identifier and so do not allow complete freedom to choose an unused\nmonitoring identifier for a given CLOSID.\n\nThis support missed that some platforms may not have these counters. This\ncauses a NULL pointer dereference when creating a new control group as the\narray was not allocated by dom_data_init().\n\nAs this feature isn't necessary on platforms that don't have cache occupancy\nmonitors, add this to the check that occurs when a new control group is\nallocated.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()\n\nThe function brcmf_usb_dl_writeimage() calls the function\nbrcmf_usb_dl_cmd() but dose not check its return value. The\n'state.state' and the 'state.bytes' are uninitialized if the\nfunction brcmf_usb_dl_cmd() fails. It is dangerous to use\nuninitialized variables in the conditions.\n\nAdd error handling for brcmf_usb_dl_cmd() to jump to error\nhandling path if the brcmf_usb_dl_cmd() fails and the\n'state.state' and the 'state.bytes' are uninitialized.\n\nImprove the error message to report more detailed error\ninformation.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: leds: fix memory leak\n\nA network restart test on a router led to an out-of-memory condition,\nwhich was traced to a memory leak in the PHY LED trigger code.\n\nThe root cause is misuse of the devm API. The registration function\n(phy_led_triggers_register) is called from phy_attach_direct, not\nphy_probe, and the unregister function (phy_led_triggers_unregister)\nis called from phy_detach, not phy_remove. This means the register and\nunregister functions can be called multiple times for the same PHY\ndevice, but devm-allocated memory is not freed until the driver is\nunbound.\n\nThis also prevents kmemleak from detecting the leak, as the devm API\ninternally stores the allocated pointer.\n\nFix this by replacing devm_kzalloc/devm_kcalloc with standard\nkzalloc/kcalloc, and add the corresponding kfree calls in the unregister\npath.

In the Linux kernel, the following vulnerability has been resolved:\n\nfix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()\n\nNormally do_lock_mount(path, _) is locking a mountpoint pinned by\n*path and at the time when matching unlock_mount() unlocks that\nlocation it is still pinned by the same thing.\n\nUnfortunately, for 'beneath' case it's no longer that simple -\nthe object being locked is not the one *path points to. It's the\nmountpoint of path->mnt. The thing is, without sufficient locking\n->mnt_parent may change under us and none of the locks are held\nat that point. The rules are\n * mount_lock stabilizes m->mnt_parent for any mount m.\n * namespace_sem stabilizes m->mnt_parent, provided that\nm is mounted.\n * if either of the above holds and refcount of m is positive,\nwe are guaranteed the same for refcount of m->mnt_parent.\n\nnamespace_sem nests inside inode_lock(), so do_lock_mount() has\nto take inode_lock() before grabbing namespace_sem. It does\nrecheck that path->mnt is still mounted in the same place after\ngetting namespace_sem, and it does take care to pin the dentry.\nIt is needed, since otherwise we might end up with racing mount --move\n(or umount) happening while we were getting locks; in that case\ndentry would no longer be a mountpoint and could've been evicted\non memory pressure along with its inode - not something you want\nwhen grabbing lock on that inode.\n\nHowever, pinning a dentry is not enough - the matching mount is\nalso pinned only by the fact that path->mnt is mounted on top it\nand at that point we are not holding any locks whatsoever, so\nthe same kind of races could end up with all references to\nthat mount gone just as we are about to enter inode_lock().\nIf that happens, we are left with filesystem being shut down while\nwe are holding a dentry reference on it; results are not pretty.\n\nWhat we need to do is grab both dentry and mount at the same time;\nthat makes inode_lock() safe *and* avoids the problem with fs getting\nshut down under us. After taking namespace_sem we verify that\npath->mnt is still mounted (which stabilizes its ->mnt_parent) and\ncheck that it's still mounted at the same place. From that point\non to the matching namespace_unlock() we are guaranteed that\nmount/dentry pair we'd grabbed are also pinned by being the mountpoint\nof path->mnt, so we can quietly drop both the dentry reference (as\nthe current code does) and mnt one - it's OK to do under namespace_sem,\nsince we are not dropping the final refs.\n\nThat solves the problem on do_lock_mount() side; unlock_mount()\nalso has one, since dentry is guaranteed to stay pinned only until\nthe namespace_unlock(). That's easy to fix - just have inode_unlock()\ndone earlier, while it's still pinned by mp->m_dentry.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: class: Invalidate USB device pointers on partner unregistration\n\nTo avoid using invalid USB device pointers after a Type-C partner\ndisconnects, this patch clears the pointers upon partner unregistration.\nThis ensures a clean state for future connections.

In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: wdm: close race between wdm_open and wdm_wwan_port_stop\n\nClearing WDM_WWAN_IN_USE must be the last action or\nwe can open a chardev whose URBs are still poisoned

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: smartpqi: Use is_kdump_kernel() to check for kdump\n\nThe smartpqi driver checks the reset_devices variable to determine\nwhether special adjustments need to be made for kdump. This has the\neffect that after a regular kexec reboot, some driver parameters such as\nmax_transfer_size are much lower than usual. More importantly, kexec\nreboot tests have revealed memory corruption caused by the driver log\nbeing written to system memory after a kexec.\n\nFix this by testing is_kdump_kernel() rather than reset_devices where\nappropriate.

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: integrity: Do not call set_page_dirty_lock()\n\nPlacing multiple protection information buffers inside the same page\ncan lead to oopses because set_page_dirty_lock() can't be called from\ninterrupt context.\n\nSince a protection information buffer is not backed by a file there is\nno point in setting its page dirty, there is nothing to synchronize.\nDrop the call to set_page_dirty_lock() and remove the last argument to\nbio_integrity_unpin_bvec().

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: exynos: Disable iocc if dma-coherent property isn't set\n\nIf dma-coherent property isn't set then descriptors are non-cacheable\nand the iocc shareability bits should be disabled. Without this UFS can\nend up in an incompatible configuration and suffer from random cache\nrelated stability issues.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: module: Fix out-of-bounds relocation access\n\nThe current code allows rel[j] to access one element past the end of the\nrelocation section. Simplify to num_relocations which is equivalent to\nthe existing size expression.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation\n\nCurrently during the multi-link element defragmentation process, the\nmulti-link element length added to the total IEs length when calculating\nthe length of remaining IEs after the multi-link element in\ncfg80211_defrag_mle(). This could lead to out-of-bounds access if the\nmulti-link element or its corresponding fragment elements are the last\nelements in the IEs buffer.\n\nTo address this issue, correctly calculate the remaining IEs length by\ndeducting the multi-link element end offset from total IEs end offset.

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: bcm2835-camera: Initialise dev in v4l2_dev\n\nCommit 42a2f6664e18 ("staging: vc04_services: Move global g_state to\nvchiq_state") changed mmal_init to pass dev->v4l2_dev.dev to\nvchiq_mmal_init, however nothing iniitialised dev->v4l2_dev, so we got\na NULL pointer dereference.\n\nSet dev->v4l2_dev.dev during bcm2835_mmal_probe. The device pointer\ncould be passed into v4l2_device_register to set it, however that also\nhas other effects that would need additional changes.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo\n\nPrevent st_lsm6dsx_read_fifo from falling in an infinite loop in case\npattern_len is equal to zero and the device FIFO is not empty.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo\n\nPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in\ncase pattern_len is equal to zero and the device FIFO is not empty.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: light: opt3001: fix deadlock due to concurrent flag access\n\nThe threaded IRQ function in this driver is reading the flag twice: once to\nlock a mutex and once to unlock it. Even though the code setting the flag\nis designed to prevent it, there are subtle cases where the flag could be\ntrue at the mutex_lock stage and false at the mutex_unlock stage. This\nresults in the mutex not being unlocked, resulting in a deadlock.\n\nFix it by making the opt3001_irq() code generally more robust, reading the\nflag into a variable and using the variable value at both stages.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: displayport: Fix deadlock\n\nThis patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlock\nfunctions to the UCSI driver. ucsi_con_mutex_lock ensures the connector\nmutex is only locked if a connection is established and the partner pointer\nis valid. This resolves a deadlock scenario where\nucsi_displayport_remove_partner holds con->mutex waiting for\ndp_altmode_work to complete while dp_altmode_work attempts to acquire it.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL\n\nWhen userspace does PR_SET_TAGGED_ADDR_CTRL, but Supm extension is not\navailable, the kernel crashes:\n\nOops - illegal instruction [#1]\n [snip]\nepc : set_tagged_addr_ctrl+0x112/0x15a\n ra : set_tagged_addr_ctrl+0x74/0x15a\nepc : ffffffff80011ace ra : ffffffff80011a30 sp : ffffffc60039be10\n [snip]\nstatus: 0000000200000120 badaddr: 0000000010a79073 cause: 0000000000000002\n set_tagged_addr_ctrl+0x112/0x15a\n __riscv_sys_prctl+0x352/0x73c\n do_trap_ecall_u+0x17c/0x20c\n andle_exception+0x150/0x15c\n\nFix it by checking if Supm is available.

In the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix uninit-value for saddr in do_output_route4\n\nsyzbot reports for uninit-value for the saddr argument [1].\ncommit 4754957f04f5 ("ipvs: do not use random local source address for\ntunnels") already implies that the input value of saddr\nshould be ignored but the code is still reading it which can prevent\nto connect the route. Fix it by changing the argument to ret_saddr.\n\n[1]\nBUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4167 [inline]\n slab_alloc_node mm/slub.c:4210 [inline]\n __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367\n kmalloc_noprof include/linux/slab.h:905 [inline]\n ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]\n __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)\nHardware name: Google Google Compute Engi\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nmemblock: Accept allocated memory before use in memblock_double_array()\n\nWhen increasing the array size in memblock_double_array() and the slab\nis not yet available, a call to memblock_find_in_range() is used to\nreserve/allocate memory. However, the range returned may not have been\naccepted, which can result in a crash when booting an SNP guest:\n\n RIP: 0010:memcpy_orig+0x68/0x130\n Code: ...\n RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006\n RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000\n RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00\n RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000\n R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78\n R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00\n memblock_double_array+0xff/0x310\n memblock_add_range+0x1fb/0x2f0\n memblock_reserve+0x4f/0xa0\n memblock_alloc_range_nid+0xac/0x130\n memblock_alloc_internal+0x53/0xc0\n memblock_alloc_try_nid+0x3d/0xa0\n swiotlb_init_remap+0x149/0x2f0\n mem_init+0xb/0xb0\n mm_core_init+0x8f/0x350\n start_kernel+0x17e/0x5d0\n x86_64_start_reservations+0x14/0x30\n x86_64_start_kernel+0x92/0xa0\n secondary_startup_64_no_verify+0x194/0x19b\n\nMitigate this by calling accept_memory() on the memory range returned\nbefore the slab is available.\n\nPrior to v6.12, the accept_memory() interface used a 'start' and 'end'\nparameter instead of 'start' and 'size', therefore the accept_memory()\ncall must be adjusted to specify 'start + size' for 'end' when applying\nto kernels prior to v6.12.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Scrub packet on bpf_redirect_peer\n\nWhen bpf_redirect_peer is used to redirect packets to a device in\nanother network namespace, the skb isn't scrubbed. That can lead skb\ninformation from one namespace to be "misused" in another namespace.\n\nAs one example, this is causing Cilium to drop traffic when using\nbpf_redirect_peer to redirect packets that just went through IPsec\ndecryption to a container namespace. The following pwru trace shows (1)\nthe packet path from the host's XFRM layer to the container's XFRM\nlayer where it's dropped and (2) the number of active skb extensions at\neach function.\n\n NETNS MARK IFACE TUPLE FUNC\n 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive\n .active_extensions = (__u8)2,\n [...]\n 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core\n .active_extensions = (__u8)2,\n [...]\n 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)\n .active_extensions = (__u8)2,\n\nIn this case, there are no XFRM policies in the container's network\nnamespace so the drop is unexpected. When we decrypt the IPsec packet,\nthe XFRM state used for decryption is set in the skb extensions. This\ninformation is preserved across the netns switch. When we reach the\nXFRM policy check in the container's netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can't be found that matches the (host-side) XFRM state used for\ndecryption.\n\nThis patch fixes this by scrubbing the packet when using\nbpf_redirect_peer, as is done on typical netns switches via veth\ndevices except skb->mark and skb->tstamp are not zeroed.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix dereferencing invalid pmd migration entry\n\nWhen migrating a THP, concurrent access to the PMD migration entry during\na deferred split scan can lead to an invalid address access, as\nillustrated below. To prevent this invalid access, it is necessary to\ncheck the PMD migration entry and return early. In this context, there is\nno need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the\nequality of the target folio. Since the PMD migration entry is locked, it\ncannot be served as the target.\n\nMailing list discussion and explanation from Hugh Dickins: "An anon_vma\nlookup points to a location which may contain the folio of interest, but\nmight instead contain another folio: and weeding out those other folios is\nprecisely what the "folio != pmd_folio((*pmd)" check (and the "risk of\nreplacing the wrong folio" comment a few lines above it) is for."\n\nBUG: unable to handle page fault for address: ffffea60001db008\nCPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60\nCall Trace:\n\ntry_to_migrate_one+0x28c/0x3730\nrmap_walk_anon+0x4f6/0x770\nunmap_folio+0x196/0x1f0\nsplit_huge_page_to_list_to_order+0x9f6/0x1560\ndeferred_split_scan+0xac5/0x12a0\nshrinker_debugfs_scan_write+0x376/0x470\nfull_proxy_write+0x15c/0x220\nvfs_write+0x2fc/0xcb0\nksys_write+0x146/0x250\ndo_syscall_64+0x6a/0x120\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe bug is found by syzkaller on an internal kernel, then confirmed on\nupstream.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception\n\nPreviously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode\non vCPU reset") addressed an issue where a triple fault occurring in\nnested mode could lead to use-after-free scenarios. However, the commit\ndid not handle the analogous situation for System Management Mode (SMM).\n\nThis omission results in triggering a WARN when KVM forces a vCPU INIT\nafter SHUTDOWN interception while the vCPU is in SMM. This situation was\nreprodused using Syzkaller by:\n\n 1) Creating a KVM VM and vCPU\n 2) Sending a KVM_SMI ioctl to explicitly enter SMM\n 3) Executing invalid instructions causing consecutive exceptions and\n eventually a triple fault\n\nThe issue manifests as follows:\n\n WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112\n kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n Modules linked in:\n CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted\n 6.1.130-syzkaller-00157-g164fe5dde9b6 #0\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n BIOS 1.12.0-1 04/01/2014\n RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n Call Trace:\n \n shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136\n svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395\n svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457\n vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline]\n vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062\n kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283\n kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nArchitecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN()\nin kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper\nemulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to\ndo _something_ sane with the VMCB, since it's technically undefined, and\nINIT is the least awful choice given KVM's ABI.\n\nSo, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of\nSMM to avoid any weirdness (and the WARN).\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.\n\n[sean: massage changelog, make it clear this isn't architectural behavior]

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable()\n\nThe selftests added to our CI by Bui Quang Minh recently reveals\nthat there is a mem leak on the error path of virtnet_xsk_pool_enable():\n\nunreferenced object 0xffff88800a68a000 (size 2048):\n comm "xdp_helper", pid 318, jiffies 4294692778\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 0):\n __kvmalloc_node_noprof+0x402/0x570\n virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882)\n xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226)\n xsk_bind+0x6a5/0x1ae0\n __sys_bind+0x15e/0x230\n __x64_sys_bind+0x72/0xb0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix panic in failed foilio allocation\n\ncommit 7e119cff9d0a ("ocfs2: convert w_pages to w_folios") and commit\n9a5e08652dc4b ("ocfs2: use an array of folios instead of an array of\npages") save -ENOMEM in the folio array upon allocation failure and call\nthe folio array free code.\n\nThe folio array free code expects either valid folio pointers or NULL. \nFinding the -ENOMEM will result in a panic. Fix by NULLing the error\nfolio entry.

In the Linux kernel, the following vulnerability has been resolved:\n\nxenbus: Use kref to track req lifetime\n\nMarek reported seeing a NULL pointer fault in the xenbus_thread\ncallstack:\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nRIP: e030:__wake_up_common+0x4c/0x180\nCall Trace:\n \n __wake_up_common_lock+0x82/0xd0\n process_msg+0x18e/0x2f0\n xenbus_thread+0x165/0x1c0\n\nprocess_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), a\nthin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seems\nlike it was xs_wake_up() in this case.\n\nIt seems like req may have woken up the xs_wait_for_reply(), which\nkfree()ed the req. When xenbus_thread resumes, it faults on the zero-ed\ndata.\n\nLinux Device Drivers 2nd edition states:\n"Normally, a wake_up call can cause an immediate reschedule to happen,\nmeaning that other processes might run before wake_up returns."\n... which would match the behaviour observed.\n\nChange to keeping two krefs on each request. One for the caller, and\none for xenbus_thread. Each will kref_put() when finished, and the last\nwill free it.\n\nThis use of kref matches the description in\nDocumentation/core-api/kref.rst

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs\n\nWith commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize state\nof zpci_dev's") the code to ignore power off of a PF that has child VFs\nwas changed from a direct return to a goto to the unlock and\npci_dev_put() section. The change however left the existing pci_dev_put()\nuntouched resulting in a doubple put. This can subsequently cause a use\nafter free if the struct pci_dev is released in an unexpected state.\nFix this by removing the extra pci_dev_put().

In the Linux kernel, the following vulnerability has been resolved:\n\nlibbpf: Fix accessing BTF.ext core_relo header\n\nUpdate btf_ext_parse_info() to ensure the core_relo header is present\nbefore reading its fields. This avoids a potential buffer read overflow\nreported by the OSS Fuzz project.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Verify event formats that have "%*p.."\n\nThe trace event verifier checks the formats of trace events to make sure\nthat they do not point at memory that is not in the trace event itself or\nin data that will never be freed. If an event references data that was\nallocated when the event triggered and that same data is freed before the\nevent is read, then the kernel can crash by reading freed memory.\n\nThe verifier runs at boot up (or module load) and scans the print formats\nof the events and checks their arguments to make sure that dereferenced\npointers are safe. If the format uses "%*p.." the verifier will ignore it,\nand that could be dangerous. Cover this case as well.\n\nAlso add to the sample code a use case of "%*pbl".

In the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()\n\nIf dib8000_set_dds()'s call to dib8000_read32() returns zero, the result\nis a divide-by-zero. Prevent that from happening.\n\nFixes the following warning with an UBSAN kernel:\n\n drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value.\n\nWhen generating the MSR_IA32_PEBS_ENABLE value that will be loaded on\nVM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLE\nvalue. Consulting only the host kernel's host vs. guest masks results in\nrunning the guest with PEBS enabled even when the guest doesn't want to use\nPEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply\nlooking at exclude_host can't differentiate between events created by host\nuserspace, and events created by KVM on behalf of the guest.\n\nRunning the guest with PEBS unexpectedly enabled typically manifests as\ncrashes due to a near-infinite stream of #PFs. E.g. if the guest hasn't\nwritten MSR_IA32_DS_AREA, the CPU will hit page faults on address '0' when\ntrying to record PEBS events.\n\nThe issue is most easily reproduced by running `perf kvm top` from before\ncommit 7b100989b4f6 ("perf evlist: Remove __evlist__add_default") (after\nwhich, `perf kvm top` effectively stopped using PEBS).\tThe userspace side\nof perf creates a guest-only PEBS event, which intel_guest_get_msrs()\nmisconstrues a guest-*owned* PEBS event.\n\nArguably, this is a userspace bug, as enabling PEBS on guest-only events\nsimply cannot work, and userspace can kill VMs in many other ways (there\nis no danger to the host). However, even if this is considered to be bad\nuserspace behavior, there's zero downside to perf/KVM restricting PEBS to\nguest-owned events.\n\nNote, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily\nin two rare situations") fixed the case where host userspace is profiling\nKVM *and* userspace, but missed the case where userspace is profiling only\nKVM.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: simple-card-utils: Fix pointer check in graph_util_parse_link_direction\n\nActually check if the passed pointers are valid, before writing to them.\nThis also fixes a USBAN warning:\nUBSAN: invalid-load in ../sound/soc/fsl/imx-card.c:687:25\nload of value 255 is not a valid value for type '_Bool'\n\nThis is because playback_only is uninitialized and is not written to, as\nthe playback-only property is absent.

In the Linux kernel, the following vulnerability has been resolved:\n\nocteon_ep: Fix host hang issue during device reboot\n\nWhen the host loses heartbeat messages from the device,\nthe driver calls the device-specific ndo_stop function,\nwhich frees the resources. If the driver is unloaded in\nthis scenario, it calls ndo_stop again, attempting to free\nresources that have already been freed, leading to a host\nhang issue. To resolve this, dev_close should be called\ninstead of the device-specific stop function.dev_close\ninternally calls ndo_stop to stop the network interface\nand performs additional cleanup tasks. During the driver\nunload process, if the device is already down, ndo_stop\nis not called.

In the Linux kernel, the following vulnerability has been resolved:\n\ndm-bufio: don't schedule in atomic context\n\nA BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and\ntry_verify_in_tasklet are enabled.\n[ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421\n[ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4\n[ 129.444740][ T934] preempt_count: 201, expected: 0\n[ 129.444756][ T934] RCU nest depth: 0, expected: 0\n[ 129.444781][ T934] Preemption disabled at:\n[ 129.444789][ T934] [] shrink_work+0x21c/0x248\n[ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16!\n[ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n[ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0\n[ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8\n[ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)\n[ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work\n[ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug]\n[ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c\n[ 129.447451][ T934] sp : ffffffc0843dbc90\n[ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b\n[ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68\n[ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900\n[ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030\n[ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358\n[ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003\n[ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400\n[ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8\n[ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0\n[ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000\n[ 129.447647][ T934] Call trace:\n[ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6]\n[ 129.447681][ T934] __might_resched+0x190/0x1a8\n[ 129.447694][ T934] shrink_work+0x180/0x248\n[ 129.447706][ T934] process_one_work+0x260/0x624\n[ 129.447718][ T934] worker_thread+0x28c/0x454\n[ 129.447729][ T934] kthread+0x118/0x158\n[ 129.447742][ T934] ret_from_fork+0x10/0x20\n[ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)\n[ 129.447772][ T934] ---[ end trace 0000000000000000 ]---\n\ndm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet\nis enabled, and __scan will be called in atomic context.

In the Linux kernel, the following vulnerability has been resolved:\n\njfs: reject on-disk inodes of an unsupported type\n\nSyzbot has reported the following BUG:\n\nkernel BUG at fs/inode.c:668!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014\nRIP: 0010:clear_inode+0x168/0x190\nCode: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7\n 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f\nRSP: 0018:ffffc900027dfae8 EFLAGS: 00010093\nRAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\nRBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38\nR10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000\nR13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80\nFS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0\nCall Trace:\n \n ? __die_body+0x5f/0xb0\n ? die+0x9e/0xc0\n ? do_trap+0x15a/0x3a0\n ? clear_inode+0x168/0x190\n ? do_error_trap+0x1dc/0x2c0\n ? clear_inode+0x168/0x190\n ? __pfx_do_error_trap+0x10/0x10\n ? report_bug+0x3cd/0x500\n ? handle_invalid_op+0x34/0x40\n ? clear_inode+0x168/0x190\n ? exc_invalid_op+0x38/0x50\n ? asm_exc_invalid_op+0x1a/0x20\n ? clear_inode+0x57/0x190\n ? clear_inode+0x167/0x190\n ? clear_inode+0x168/0x190\n ? clear_inode+0x167/0x190\n jfs_evict_inode+0xb5/0x440\n ? __pfx_jfs_evict_inode+0x10/0x10\n evict+0x4ea/0x9b0\n ? __pfx_evict+0x10/0x10\n ? iput+0x713/0xa50\n txUpdateMap+0x931/0xb10\n ? __pfx_txUpdateMap+0x10/0x10\n jfs_lazycommit+0x49a/0xb80\n ? _raw_spin_unlock_irqrestore+0x8f/0x140\n ? lockdep_hardirqs_on+0x99/0x150\n ? __pfx_jfs_lazycommit+0x10/0x10\n ? __pfx_default_wake_function+0x10/0x10\n ? __kthread_parkme+0x169/0x1d0\n ? __pfx_jfs_lazycommit+0x10/0x10\n kthread+0x2f2/0x390\n ? __pfx_jfs_lazycommit+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x4d/0x80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \n\nThis happens when 'clear_inode()' makes an attempt to finalize an underlying\nJFS inode of unknown type. According to JFS layout description from\nhttps://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to\n15 are reserved for future extensions and should not be encountered on a valid\nfilesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.

In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: vnifilter: Fix unlocked deletion of default FDB entry\n\nWhen a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB\nentry associated with the default remote (assuming one was configured)\nis deleted without holding the hash lock. This is wrong and will result\nin a warning [1] being generated by the lockdep annotation that was\nadded by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").\n\nReproducer:\n\n # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1\n # bridge vni add vni 10010 remote 198.51.100.1 dev vx0\n # bridge vni del vni 10010 dev vx0\n\nFix by acquiring the hash lock before the deletion and releasing it\nafterwards. Blame the original commit that introduced the issue rather\nthan the one that exposed it.\n\n[1]\nWARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0\n[...]\nRIP: 0010:vxlan_find_mac+0x17f/0x1a0\n[...]\nCall Trace:\n \n __vxlan_fdb_delete+0xbe/0x560\n vxlan_vni_delete_group+0x2ba/0x940\n vxlan_vni_del.isra.0+0x15f/0x580\n vxlan_process_vni_filter+0x38b/0x7b0\n vxlan_vnifilter_process+0x3bb/0x510\n rtnetlink_rcv_msg+0x2f7/0xb70\n netlink_rcv_skb+0x131/0x360\n netlink_unicast+0x426/0x710\n netlink_sendmsg+0x75a/0xc20\n __sock_sendmsg+0xc1/0x150\n ____sys_sendmsg+0x5aa/0x7b0\n ___sys_sendmsg+0xfc/0x180\n __sys_sendmsg+0x121/0x1b0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Fix race condition in AF_XDP generic RX path\n\nMove rx_lock from xsk_socket to xsk_buff_pool.\nFix synchronization for shared umem mode in\ngeneric RX path where multiple sockets share\nsingle xsk_buff_pool.\n\nRX queue is exclusive to xsk_socket, while FILL\nqueue can be shared between multiple sockets.\nThis could result in race condition where two\nCPU cores access RX path of two different sockets\nsharing the same umem.\n\nProtect both queues by acquiring spinlock in shared\nxsk_buff_pool.\n\nLock contention may be minimized in the future by some\nper-thread FQ buffering.\n\nIt's safe and necessary to move spin_lock_bh(rx_lock)\nafter xsk_rcv_check():\n* xs->pool and spinlock_init is synchronized by\n xsk_bind() -> xsk_is_bound() memory barriers.\n* xsk_rcv_check() may return true at the moment\n of xsk_release() or xsk_unbind_dev(),\n however this will not cause any data races or\n race conditions. xsk_unbind_dev() removes xdp\n socket from all maps and waits for completion\n of all outstanding rx operations. Packets in\n RX path will either complete safely or drop.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot\n\nUpdate chip data using dev_get_drvdata(dev->parent) to fix\nNULL pointer deref in acp_i2s_set_tdm_slot.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()\n\nA NULL pointer dereference can occur in skb_dequeue() when processing a\nQCA firmware crash dump on WCN7851 (0489:e0f3).\n\n[ 93.672166] Bluetooth: hci0: ACL memdump size(589824)\n\n[ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]\n[ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80\n\nThe issue stems from handle_dump_pkt_qca() returning 0 even when a dump\npacket is successfully processed. This is because it incorrectly\nforwards the return value of hci_devcd_init() (which returns 0 on\nsuccess). As a result, the caller (btusb_recv_acl_qca() or\nbtusb_recv_evt_qca()) assumes the packet was not handled and passes it\nto hci_recv_frame(), leading to premature kfree() of the skb.\n\nLater, hci_devcd_rx() attempts to dequeue the same skb from the dump\nqueue, resulting in a NULL pointer dereference.\n\nFix this by:\n1. Making handle_dump_pkt_qca() return 0 on success and negative errno\n on failure, consistent with kernel conventions.\n2. Splitting dump packet detection into separate functions for ACL\n and event packets for better structure and readability.\n\nThis ensures dump packets are properly identified and consumed, avoiding\ndouble handling and preventing NULL pointer access.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll\n\nUse spin_lock_irqsave and spin_unlock_irqrestore instead of spin_lock\nand spin_unlock in mtk_star_emac driver to avoid spinlock recursion\noccurrence that can happen when enabling the DMA interrupts again in\nrx/tx poll.\n\n```\nBUG: spinlock recursion on CPU#0, swapper/0/0\n lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0,\n .owner_cpu: 0\nCPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted\n 6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT\nHardware name: MediaTek MT8365 Open Platform EVK (DT)\nCall trace:\n show_stack+0x18/0x24 (C)\n dump_stack_lvl+0x60/0x80\n dump_stack+0x18/0x24\n spin_dump+0x78/0x88\n do_raw_spin_lock+0x11c/0x120\n _raw_spin_lock+0x20/0x2c\n mtk_star_handle_irq+0xc0/0x22c [mtk_star_emac]\n __handle_irq_event_percpu+0x48/0x140\n handle_irq_event+0x4c/0xb0\n handle_fasteoi_irq+0xa0/0x1bc\n handle_irq_desc+0x34/0x58\n generic_handle_domain_irq+0x1c/0x28\n gic_handle_irq+0x4c/0x120\n do_interrupt_handler+0x50/0x84\n el1_interrupt+0x34/0x68\n el1h_64_irq_handler+0x18/0x24\n el1h_64_irq+0x6c/0x70\n regmap_mmio_read32le+0xc/0x20 (P)\n _regmap_bus_reg_read+0x6c/0xac\n _regmap_read+0x60/0xdc\n regmap_read+0x4c/0x80\n mtk_star_rx_poll+0x2f4/0x39c [mtk_star_emac]\n __napi_poll+0x38/0x188\n net_rx_action+0x164/0x2c0\n handle_softirqs+0x100/0x244\n __do_softirq+0x14/0x20\n ____do_softirq+0x10/0x20\n call_on_irq_stack+0x24/0x64\n do_softirq_own_stack+0x1c/0x40\n __irq_exit_rcu+0xd4/0x10c\n irq_exit_rcu+0x10/0x1c\n el1_interrupt+0x38/0x68\n el1h_64_irq_handler+0x18/0x24\n el1h_64_irq+0x6c/0x70\n cpuidle_enter_state+0xac/0x320 (P)\n cpuidle_enter+0x38/0x50\n do_idle+0x1e4/0x260\n cpu_startup_entry+0x34/0x3c\n rest_init+0xdc/0xe0\n console_on_rootfs+0x0/0x6c\n __primary_switched+0x88/0x90\n```

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: drr: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard's report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc's enqueue callback reentrant.\nIn the case of drr, there won't be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether the\nclass was already added to the active_list (cl_is_active) before adding\nto the list to cover for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: ets: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard's report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc's enqueue callback reentrant.\nIn the case of ets, there won't be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether\nthe class was already added to the active_list (cl_is_active) before\ndoing the addition to cater for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: qfq: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard's report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc's enqueue callback reentrant.\nIn the case of qfq, there won't be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nThis patch checks whether the class was already added to the agg->active\nlist (cl_is_active) before doing the addition to cater for the reentrant\ncase.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix out-of-bound memcpy() during ethtool -w\n\nWhen retrieving the FW coredump using ethtool, it can sometimes cause\nmemory corruption:\n\nBUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nCorrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):\n__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nethtool_get_dump_data+0xdc/0x1a0\n__dev_ethtool+0xa1e/0x1af0\ndev_ethtool+0xa8/0x170\ndev_ioctl+0x1b5/0x580\nsock_do_ioctl+0xab/0xf0\nsock_ioctl+0x1ce/0x2e0\n__x64_sys_ioctl+0x87/0xc0\ndo_syscall_64+0x5c/0xf0\nentry_SYSCALL_64_after_hwframe+0x78/0x80\n\n...\n\nThis happens when copying the coredump segment list in\nbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.\nThe info->dest_buf buffer is allocated based on the number of coredump\nsegments returned by the FW. The segment list is then DMA'ed by\nthe FW and the length of the DMA is returned by FW. The driver then\ncopies this DMA'ed segment list to info->dest_buf.\n\nIn some cases, this DMA length may exceed the info->dest_buf length\nand cause the above BUG condition. Fix it by capping the copy\nlength to not exceed the length of info->dest_buf. The extra\nDMA data contains no useful information.\n\nThis code path is shared for the HWRM_DBG_COREDUMP_LIST and the\nHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different\nfor these 2 FW commands. To simplify the logic, we need to move\nthe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE\nup, so that the new check to cap the copy length will work for both\ncommands.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan743x: Fix memleak issue when GSO enabled\n\nAlways map the `skb` to the LS descriptor. Previously skb was\nmapped to EXT descriptor when the number of fragments is zero with\nGSO enabled. Mapping the skb to EXT descriptor prevents it from\nbeing freed, leading to a memory leak

In the Linux kernel, the following vulnerability has been resolved:\n\nmm, slab: clean up slab->obj_exts always\n\nWhen memory allocation profiling is disabled at runtime or due to an\nerror, shutdown_mem_profiling() is called: slab->obj_exts which\npreviously allocated remains.\nIt won't be cleared by unaccount_slab() because of\nmem_alloc_profiling_enabled() not true. It's incorrect, slab->obj_exts\nshould always be cleaned up in unaccount_slab() to avoid following error:\n\n[...]BUG: Bad page state in process...\n..\n[...]page dumped because: page still charged to cgroup\n\n[andriy.shevchenko@linux.intel.com: fold need_slab_obj_ext() into its only user]

In the Linux kernel, the following vulnerability has been resolved:\n\nublk: fix race between io_uring_cmd_complete_in_task and ublk_cancel_cmd\n\nublk_cancel_cmd() calls io_uring_cmd_done() to complete uring_cmd, but\nwe may have scheduled task work via io_uring_cmd_complete_in_task() for\ndispatching request, then kernel crash can be triggered.\n\nFix it by not trying to canceling the command if ublk block request is\nstarted.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix the inode leak in btrfs_iget()\n\n[BUG]\nThere is a bug report that a syzbot reproducer can lead to the following\nbusy inode at unmount time:\n\n BTRFS info (device loop1): last unmount of filesystem 1680000e-3c1e-4c46-84b6-56bd3909af50\n VFS: Busy inodes after unmount of loop1 (btrfs)\n ------------[ cut here ]------------\n kernel BUG at fs/super.c:650!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 0 UID: 0 PID: 48168 Comm: syz-executor Not tainted 6.15.0-rc2-00471-g119009db2674 #2 PREEMPT(full)\n Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:generic_shutdown_super+0x2e9/0x390 fs/super.c:650\n Call Trace:\n \n kill_anon_super+0x3a/0x60 fs/super.c:1237\n btrfs_kill_super+0x3b/0x50 fs/btrfs/super.c:2099\n deactivate_locked_super+0xbe/0x1a0 fs/super.c:473\n deactivate_super fs/super.c:506 [inline]\n deactivate_super+0xe2/0x100 fs/super.c:502\n cleanup_mnt+0x21f/0x440 fs/namespace.c:1435\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:114 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x269/0x290 kernel/entry/common.c:218\n do_syscall_64+0xd4/0x250 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \n\n[CAUSE]\nWhen btrfs_alloc_path() failed, btrfs_iget() directly returned without\nreleasing the inode already allocated by btrfs_iget_locked().\n\nThis results the above busy inode and trigger the kernel BUG.\n\n[FIX]\nFix it by calling iget_failed() if btrfs_alloc_path() failed.\n\nIf we hit error inside btrfs_read_locked_inode(), it will properly call\niget_failed(), so nothing to worry about.\n\nAlthough the iget_failed() cleanup inside btrfs_read_locked_inode() is a\nbreak of the normal error handling scheme, let's fix the obvious bug\nand backport first, then rework the error handling later.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu: Fix two issues in iommu_copy_struct_from_user()\n\nIn the review for iommu_copy_struct_to_user() helper, Matt pointed out that\na NULL pointer should be rejected prior to dereferencing it:\nhttps://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com\n\nAnd Alok pointed out a typo at the same time:\nhttps://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com\n\nSince both issues were copied from iommu_copy_struct_from_user(), fix them\nfirst in the current header.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc64/ftrace: fix module loading without patchable function entries\n\nget_stubs_size assumes that there must always be at least one patchable\nfunction entry, which is not always the case (modules that export data\nbut no code), otherwise it returns -ENOEXEC and thus the section header\nsh_size is set to that value. During module_memory_alloc() the size is\npassed to execmem_alloc() after being page-aligned and thus set to zero\nwhich will cause it to fail the allocation (and thus module loading) as\n__vmalloc_node_range() checks for zero-sized allocs and returns null:\n\n[ 115.466896] module_64: cast_common: doesn't contain __patchable_function_entries.\n[ 115.469189] ------------[ cut here ]------------\n[ 115.469496] WARNING: CPU: 0 PID: 274 at mm/vmalloc.c:3778 __vmalloc_node_range_noprof+0x8b4/0x8f0\n...\n[ 115.478574] ---[ end trace 0000000000000000 ]---\n[ 115.479545] execmem: unable to allocate memory\n\nFix this by removing the check completely, since it is anyway not\nhelpful to propagate this as an error upwards.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: plfxlc: Remove erroneous assert in plfxlc_mac_release\n\nplfxlc_mac_release() asserts that mac->lock is held. This assertion is\nincorrect, because even if it was possible, it would not be the valid\nbehaviour. The function is used when probe fails or after the device is\ndisconnected. In both cases mac->lock can not be held as the driver is\nnot working with the device at the moment. All functions that use mac->lock\nunlock it just after it was held. There is also no need to hold mac->lock\nfor plfxlc_mac_release() itself, as mac data is not affected, except for\nmac->flags, which is modified atomically.\n\nThis bug leads to the following warning:\n================================================================\nWARNING: CPU: 0 PID: 127 at drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0\nModules linked in:\nCPU: 0 PID: 127 Comm: kworker/0:2 Not tainted 6.1.124-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:plfxlc_mac_release+0x7d/0xa0 drivers/net/wireless/purelifi/plfxlc/mac.c:106\nCall Trace:\n \n probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694\n usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396\n really_probe+0x2ab/0xcb0 drivers/base/dd.c:639\n __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785\n driver_probe_device+0x50/0x420 drivers/base/dd.c:815\n __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943\n bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429\n __device_attach+0x359/0x570 drivers/base/dd.c:1015\n bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489\n device_add+0xb48/0xfd0 drivers/base/core.c:3696\n usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165\n usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238\n usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293\n really_probe+0x2ab/0xcb0 drivers/base/dd.c:639\n __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785\n driver_probe_device+0x50/0x420 drivers/base/dd.c:815\n __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943\n bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429\n __device_attach+0x359/0x570 drivers/base/dd.c:1015\n bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489\n device_add+0xb48/0xfd0 drivers/base/core.c:3696\n usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620\n hub_port_connect drivers/usb/core/hub.c:5477 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5617 [inline]\n port_event drivers/usb/core/hub.c:5773 [inline]\n hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855\n process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292\n worker_thread+0xa47/0x1200 kernel/workqueue.c:2439\n kthread+0x28d/0x320 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295\n \n================================================================\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spi-mem: Add fix to avoid divide error\n\nFor some SPI flash memory operations, dummy bytes are not mandatory. For\nexample, in Winbond SPINAND flash memory devices, the `write_cache` and\n`update_cache` operation variants have zero dummy bytes. Calculating the\nduration for SPI memory operations with zero dummy bytes causes\na divide error when `ncycles` is calculated in the\nspi_mem_calc_op_duration().\n\nAdd changes to skip the 'ncylcles' calculation for zero dummy bytes.\n\nFollowing divide error is fixed by this change:\n\n Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI\n...\n\n ? do_trap+0xdb/0x100\n ? do_error_trap+0x75/0xb0\n ? spi_mem_calc_op_duration+0x56/0xb0\n ? exc_divide_error+0x3b/0x70\n ? spi_mem_calc_op_duration+0x56/0xb0\n ? asm_exc_divide_error+0x1b/0x20\n ? spi_mem_calc_op_duration+0x56/0xb0\n ? spinand_select_op_variant+0xee/0x190 [spinand]\n spinand_match_and_init+0x13e/0x1a0 [spinand]\n spinand_manufacturer_match+0x6e/0xa0 [spinand]\n spinand_probe+0x357/0x7f0 [spinand]\n ? kernfs_activate+0x87/0xd0\n spi_mem_probe+0x7a/0xb0\n spi_probe+0x7d/0x130

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: use sock_gen_put() when sk_state is TCP_TIME_WAIT\n\nIt is possible for a pointer of type struct inet_timewait_sock to be\nreturned from the functions __inet_lookup_established() and\n__inet6_lookup_established(). This can cause a crash when the\nreturned pointer is of type struct inet_timewait_sock and\nsock_put() is called on it. The following is a crash call stack that\nshows sk->sk_wmem_alloc being accessed in sk_free() during the call to\nsock_put() on a struct inet_timewait_sock pointer. To avoid this issue,\nuse sock_gen_put() instead of sock_put() when sk->sk_state\nis TCP_TIME_WAIT.\n\nmrdump.ko ipanic() + 120\nvmlinux notifier_call_chain(nr_to_call=-1, nr_calls=0) + 132\nvmlinux atomic_notifier_call_chain(val=0) + 56\nvmlinux panic() + 344\nvmlinux add_taint() + 164\nvmlinux end_report() + 136\nvmlinux kasan_report(size=0) + 236\nvmlinux report_tag_fault() + 16\nvmlinux do_tag_recovery() + 16\nvmlinux __do_kernel_fault() + 88\nvmlinux do_bad_area() + 28\nvmlinux do_tag_check_fault() + 60\nvmlinux do_mem_abort() + 80\nvmlinux el1_abort() + 56\nvmlinux el1h_64_sync_handler() + 124\nvmlinux > 0xFFFFFFC080011294()\nvmlinux __lse_atomic_fetch_add_release(v=0xF2FFFF82A896087C)\nvmlinux __lse_atomic_fetch_sub_release(v=0xF2FFFF82A896087C)\nvmlinux arch_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)\n+ 8\nvmlinux raw_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)\n+ 8\nvmlinux atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8\nvmlinux __refcount_sub_and_test(i=1, r=0xF2FFFF82A896087C,\noldp=0) + 8\nvmlinux __refcount_dec_and_test(r=0xF2FFFF82A896087C, oldp=0) + 8\nvmlinux refcount_dec_and_test(r=0xF2FFFF82A896087C) + 8\nvmlinux sk_free(sk=0xF2FFFF82A8960700) + 28\nvmlinux sock_put() + 48\nvmlinux tcp6_check_fraglist_gro() + 236\nvmlinux tcp6_gro_receive() + 624\nvmlinux ipv6_gro_receive() + 912\nvmlinux dev_gro_receive() + 1116\nvmlinux napi_gro_receive() + 196\nccmni.ko ccmni_rx_callback() + 208\nccmni.ko ccmni_queue_recv_skb() + 388\nccci_dpmaif.ko dpmaif_rxq_push_thread() + 1088\nvmlinux kthread() + 268\nvmlinux 0xFFFFFFC08001F30C()

In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: BPF: Fix off-by-one error in build_prologue()\n\nVincent reported that running BPF progs with tailcalls on LoongArch\ncauses kernel hard lockup. Debugging the issues shows that the JITed\nimage missing a jirl instruction at the end of the epilogue.\n\nThere are two passes in JIT compiling, the first pass set the flags and\nthe second pass generates JIT code based on those flags. With BPF progs\nmixing bpf2bpf and tailcalls, build_prologue() generates N insns in the\nfirst pass and then generates N+1 insns in the second pass. This makes\nepilogue_offset off by one and we will jump to some unexpected insn and\ncause lockup. Fix this by inserting a nop insn.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc\n\nAs described in Gerrard's report [1], we have a UAF case when an hfsc class\nhas a netem child qdisc. The crux of the issue is that hfsc is assuming\nthat checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted\nthe class in the vttree or eltree (which is not true for the netem\nduplicate case).\n\nThis patch checks the n_active class variable to make sure that the code\nwon't insert the class in the vttree or eltree twice, catering for the\nreentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: ops: Consistently treat platform_max as control value\n\nThis reverts commit 9bdd10d57a88 ("ASoC: ops: Shift tested values in\nsnd_soc_put_volsw() by +min"), and makes some additional related\nupdates.\n\nThere are two ways the platform_max could be interpreted; the maximum\nregister value, or the maximum value the control can be set to. The\npatch moved from treating the value as a control value to a register\none. When the patch was applied it was technically correct as\nsnd_soc_limit_volume() also used the register interpretation. However,\neven then most of the other usages treated platform_max as a\ncontrol value, and snd_soc_limit_volume() has since been updated to\nalso do so in commit fb9ad24485087 ("ASoC: ops: add correct range\ncheck for limiting volume"). That patch however, missed updating\nsnd_soc_put_volsw() back to the control interpretation, and fixing\nsnd_soc_info_volsw_range(). The control interpretation makes more\nsense as limiting is typically done from the machine driver, so it is\nappropriate to use the customer facing representation rather than the\ninternal codec representation. Update all the code to consistently use\nthis interpretation of platform_max.\n\nFinally, also add some comments to the soc_mixer_control struct to\nhopefully avoid further patches switching between the two approaches.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table()\n\nAdd NULL check for mlx5_get_flow_namespace() returns in\nmlx5_create_inner_ttc_table() and mlx5_create_ttc_table() to prevent\nNULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\npds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result\n\nIf the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command\nthe driver might at the least print garbage and at the worst\ncrash when the user runs the "devlink dev info" devlink command.\n\nThis happens because the stack variable fw_list is not 0\ninitialized which results in fw_list.num_fw_slots being a\ngarbage value from the stack. Then the driver tries to access\nfw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end\nof the array.\n\nFix this by initializing the fw_list and by not failing\ncompletely if the devcmd fails because other useful information\nis printed via devlink dev info even if the devcmd fails.

In the Linux kernel, the following vulnerability has been resolved:\n\npds_core: make wait_context part of q_info\n\nMake the wait_context a full part of the q_info struct rather\nthan a stack variable that goes away after pdsc_adminq_post()\nis done so that the context is still available after the wait\nloop has given up.\n\nThere was a case where a slow development firmware caused\nthe adminq request to time out, but then later the FW finally\nfinished the request and sent the interrupt. The handler tried\nto complete_all() the completion context that had been created\non the stack in pdsc_adminq_post() but no longer existed.\nThis caused bad pointer usage, kernel crashes, and much wailing\nand gnashing of teeth.

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Reset IRTE to host control if *new* route isn't postable\n\nRestore an IRTE back to host control (remapped or posted MSI mode) if the\n*new* GSI route prevents posting the IRQ directly to a vCPU, regardless of\nthe GSI routing type. Updating the IRTE if and only if the new GSI is an\nMSI results in KVM leaving an IRTE posting to a vCPU.\n\nThe dangling IRTE can result in interrupts being incorrectly delivered to\nthe guest, and in the worst case scenario can result in use-after-free,\ne.g. if the VM is torn down, but the underlying host IRQ isn't freed.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix deadlock between rcu_tasks_trace and event_mutex.\n\nFix the following deadlock:\nCPU A\n_free_event()\n perf_kprobe_destroy()\n mutex_lock(&event_mutex)\n perf_trace_event_unreg()\n synchronize_rcu_tasks_trace()\n\nThere are several paths where _free_event() grabs event_mutex\nand calls sync_rcu_tasks_trace. Above is one such case.\n\nCPU B\nbpf_prog_test_run_syscall()\n rcu_read_lock_trace()\n bpf_prog_run_pin_on_cpu()\n bpf_prog_load()\n bpf_tracing_func_proto()\n trace_set_clr_event()\n mutex_lock(&event_mutex)\n\nDelegate trace_set_clr_event() to workqueue to avoid\nsuch lock dependency.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/sclp: Add check for get_zeroed_page()\n\nAdd check for the return value of get_zeroed_page() in\nsclp_console_init() to prevent null pointer dereference.\nFurthermore, to solve the memory leak caused by the loop\nallocation, add a free helper to do the free job.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Fix isochronous Ring Underrun/Overrun event handling\n\nThe TRB pointer of these events points at enqueue at the time of error\noccurrence on xHCI 1.1+ HCs or it's NULL on older ones. By the time we\nare handling the event, a new TD may be queued at this ring position.\n\nI can trigger this race by rising interrupt moderation to increase IRQ\nhandling delay. Similar delay may occur naturally due to system load.\n\nIf this ever happens after a Missed Service Error, missed TDs will be\nskipped and the new TD processed as if it matched the event. It could\nbe given back prematurely, risking data loss or buffer UAF by the xHC.\n\nDon't complete TDs on xrun events and don't warn if queued TDs don't\nmatch the event's TRB pointer, which can be NULL or a link/no-op TRB.\nDon't warn if there are no queued TDs at all.\n\nNow that it's safe, also handle xrun events if the skip flag is clear.\nThis ensures completion of any TD stuck in 'error mid TD' state right\nbefore the xrun event, which could happen if a driver submits a finite\nnumber of URBs to a buggy HC and then an error occurs on the last TD.

In the Linux kernel, the following vulnerability has been resolved:\n\num: work around sched_yield not yielding in time-travel mode\n\nsched_yield by a userspace may not actually cause scheduling in\ntime-travel mode as no time has passed. In the case seen it appears to\nbe a badly implemented userspace spinlock in ASAN. Unfortunately, with\ntime-travel it causes an extreme slowdown or even deadlock depending on\nthe kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS).\n\nWork around it by accounting time to the process whenever it executes a\nsched_yield syscall.

In the Linux kernel, the following vulnerability has been resolved:\n\n9p/net: fix improper handling of bogus negative read/write replies\n\nIn p9_client_write() and p9_client_read_once(), if the server\nincorrectly replies with success but a negative write/read count then we\nwould consider written (negative) <= rsize (positive) because both\nvariables were signed.\n\nMake variables unsigned to avoid this problem.\n\nThe reproducer linked below now fails with the following error instead\nof a null pointer deref:\n9pnet: bogus RWRITE count (4294967295 > 3)

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix WARN_ON(!ctx) in __free_event() for partial init\n\nMove the get_ctx(child_ctx) call and the child_event->ctx assignment to\noccur immediately after the child event is allocated. Ensure that\nchild_event->ctx is non-NULL before any subsequent error path within\ninherit_event calls free_event(), satisfying the assumptions of the\ncleanup code.\n\nDetails:\n\nThere's no clear Fixes tag, because this bug is a side-effect of\nmultiple interacting commits over time (up to 15 years old), not\na single regression.\n\nThe code initially incremented refcount then assigned context\nimmediately after the child_event was created. Later, an early\nvalidity check for child_event was added before the\nrefcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was\nadded, assuming event->ctx is valid if the pmu_ctx is valid.\nThe problem is that the WARN_ON_ONCE() could trigger after the initial\ncheck passed but before child_event->ctx was assigned, violating its\nprecondition. The solution is to assign child_event->ctx right after\nits initial validation. This ensures the context exists for any\nsubsequent checks or cleanup routines, resolving the WARN_ON_ONCE().\n\nTo resolve it, defer the refcount update and child_event->ctx assignment\ndirectly after child_event->pmu_ctx is set but before checking if the\nparent event is orphaned. The cleanup routine depends on\nevent->pmu_ctx being non-NULL before it verifies event->ctx is\nnon-NULL. This also maintains the author's original intent of passing\nin child_ctx to find_get_pmu_context before its refcount/assignment.\n\n[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]

In the Linux kernel, the following vulnerability has been resolved:\n\niommu: Clear iommu-dma ops on cleanup\n\nIf iommu_device_register() encounters an error, it can end up tearing\ndown already-configured groups and default domains, however this\ncurrently still leaves devices hooked up to iommu-dma (and even\nhistorically the behaviour in this area was at best inconsistent across\narchitectures/drivers...) Although in the case that an IOMMU is present\nwhose driver has failed to probe, users cannot necessarily expect DMA to\nwork anyway, it's still arguable that we should do our best to put\nthings back as if the IOMMU driver was never there at all, and certainly\nthe potential for crashing in iommu-dma itself is undesirable. Make sure\nwe clean up the dev->dma_iommu flag along with everything else.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Only create /proc/fs/netfs with CONFIG_PROC_FS\n\nWhen testing a special config:\n\nCONFIG_NETFS_SUPPORTS=y\nCONFIG_PROC_FS=n\n\nThe system crashes with something like:\n\n[ 3.766197] ------------[ cut here ]------------\n[ 3.766484] kernel BUG at mm/mempool.c:560!\n[ 3.766789] Oops: invalid opcode: 0000 [#1] SMP NOPTI\n[ 3.767123] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W\n[ 3.767777] Tainted: [W]=WARN\n[ 3.767968] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n[ 3.768523] RIP: 0010:mempool_alloc_slab.cold+0x17/0x19\n[ 3.768847] Code: 50 fe ff 58 5b 5d 41 5c 41 5d 41 5e 41 5f e9 93 95 13 00\n[ 3.769977] RSP: 0018:ffffc90000013998 EFLAGS: 00010286\n[ 3.770315] RAX: 000000000000002f RBX: ffff888100ba8640 RCX: 0000000000000000\n[ 3.770749] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 00000000ffffffff\n[ 3.771217] RBP: 0000000000092880 R08: 0000000000000000 R09: ffffc90000013828\n[ 3.771664] R10: 0000000000000001 R11: 00000000ffffffea R12: 0000000000092cc0\n[ 3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40\n[ 3.772554] FS: 0000000000000000(0000) GS:ffff8881b5f3c000(0000) knlGS:0000000000000000\n[ 3.773061] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.773443] CR2: ffffffff830901b4 CR3: 0000000004296001 CR4: 0000000000770ef0\n[ 3.773884] PKRU: 55555554\n[ 3.774058] Call Trace:\n[ 3.774232] \n[ 3.774371] mempool_alloc_noprof+0x6a/0x190\n[ 3.774649] ? _printk+0x57/0x80\n[ 3.774862] netfs_alloc_request+0x85/0x2ce\n[ 3.775147] netfs_readahead+0x28/0x170\n[ 3.775395] read_pages+0x6c/0x350\n[ 3.775623] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 3.775928] page_cache_ra_unbounded+0x1bd/0x2a0\n[ 3.776247] filemap_get_pages+0x139/0x970\n[ 3.776510] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 3.776820] filemap_read+0xf9/0x580\n[ 3.777054] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 3.777368] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 3.777674] ? find_held_lock+0x32/0x90\n[ 3.777929] ? netfs_start_io_read+0x19/0x70\n[ 3.778221] ? netfs_start_io_read+0x19/0x70\n[ 3.778489] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 3.778800] ? lock_acquired+0x1e6/0x450\n[ 3.779054] ? srso_alias_return_thunk+0x5/0xfbef5\n[ 3.779379] netfs_buffered_read_iter+0x57/0x80\n[ 3.779670] __kernel_read+0x158/0x2c0\n[ 3.779927] bprm_execve+0x300/0x7a0\n[ 3.780185] kernel_execve+0x10c/0x140\n[ 3.780423] ? __pfx_kernel_init+0x10/0x10\n[ 3.780690] kernel_init+0xd5/0x150\n[ 3.780910] ret_from_fork+0x2d/0x50\n[ 3.781156] ? __pfx_kernel_init+0x10/0x10\n[ 3.781414] ret_from_fork_asm+0x1a/0x30\n[ 3.781677] \n[ 3.781823] Modules linked in:\n[ 3.782065] ---[ end trace 0000000000000000 ]---\n\nThis is caused by the following error path in netfs_init():\n\n if (!proc_mkdir("fs/netfs", NULL))\n goto error_proc;\n\nFix this by adding ifdef in netfs_main(), so that /proc/fs/netfs is only\ncreated with CONFIG_PROC_FS.

In the Linux kernel, the following vulnerability has been resolved:\n\nigc: fix PTM cycle trigger logic\n\nWriting to clear the PTM status 'valid' bit while the PTM cycle is\ntriggered results in unreliable PTM operation. To fix this, clear the\nPTM 'trigger' and status after each PTM transaction.\n\nThe issue can be reproduced with the following:\n\n$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m\n\nNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way to\nquickly reproduce the issue.\n\nPHC2SYS exits with:\n\n"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction\n fails\n\nThis patch also fixes a hang in igc_probe() when loading the igc\ndriver in the kdump kernel on systems supporting PTM.\n\nThe igc driver running in the base kernel enables PTM trigger in\nigc_probe(). Therefore the driver is always in PTM trigger mode,\nexcept in brief periods when manually triggering a PTM cycle.\n\nWhen a crash occurs, the NIC is reset while PTM trigger is enabled.\nDue to a hardware problem, the NIC is subsequently in a bad busmaster\nstate and doesn't handle register reads/writes. When running\nigc_probe() in the kdump kernel, the first register access to a NIC\nregister hangs driver probing and ultimately breaks kdump.\n\nWith this patch, igc has PTM trigger disabled most of the time,\nand the trigger is only enabled for very brief (10 - 100 us) periods\nwhen manually triggering a PTM cycle. Chances that a crash occurs\nduring a PTM trigger are not 0, but extremely reduced.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ngbe: fix memory leak in ngbe_probe() error path\n\nWhen ngbe_sw_init() is called, memory is allocated for wx->rss_key\nin wx_init_rss_key(). However, in ngbe_probe() function, the subsequent\nerror paths after ngbe_sw_init() don't free the rss_key. Fix that by\nfreeing it in error path along with wx->mac_table.\n\nAlso change the label to which execution jumps when ngbe_sw_init()\nfails, because otherwise, it could lead to a double free for rss_key,\nwhen the mac_table allocation fails in wx_sw_init().

In the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: fix missing ring index trim on error path\n\nCommit under Fixes converted tx_prod to be free running but missed\nmasking it on the Tx error path. This crashes on error conditions,\nfor example when DMA mapping fails.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: txgbe: fix memory leak in txgbe_probe() error path\n\nWhen txgbe_sw_init() is called, memory is allocated for wx->rss_key\nin wx_init_rss_key(). However, in txgbe_probe() function, the subsequent\nerror paths after txgbe_sw_init() don't free the rss_key. Fix that by\nfreeing it in error path along with wx->mac_table.\n\nAlso change the label to which execution jumps when txgbe_sw_init()\nfails, because otherwise, it could lead to a double free for rss_key,\nwhen the mac_table allocation fails in wx_sw_init().

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: decrease sc_count directly if fail to queue dl_recall\n\nA deadlock warning occurred when invoking nfs4_put_stid following a failed\ndl_recall queue operation:\n T1 T2\n nfs4_laundromat\n nfs4_get_client_reaplist\n nfs4_anylock_blockers\n__break_lease\n spin_lock // ctx->flc_lock\n spin_lock // clp->cl_lock\n nfs4_lockowner_has_blockers\n locks_owner_has_blockers\n spin_lock // flctx->flc_lock\n nfsd_break_deleg_cb\n nfsd_break_one_deleg\n nfs4_put_stid\n refcount_dec_and_lock\n spin_lock // clp->cl_lock\n\nWhen a file is opened, an nfs4_delegation is allocated with sc_count\ninitialized to 1, and the file_lease holds a reference to the delegation.\nThe file_lease is then associated with the file through kernel_setlease.\n\nThe disassociation is performed in nfsd4_delegreturn via the following\ncall chain:\nnfsd4_delegreturn --> destroy_delegation --> destroy_unhashed_deleg -->\nnfs4_unlock_deleg_lease --> kernel_setlease --> generic_delete_lease\nThe corresponding sc_count reference will be released after this\ndisassociation.\n\nSince nfsd_break_one_deleg executes while holding the flc_lock, the\ndisassociation process becomes blocked when attempting to acquire flc_lock\nin generic_delete_lease. This means:\n1) sc_count in nfsd_break_one_deleg will not be decremented to 0;\n2) The nfs4_put_stid called by nfsd_break_one_deleg will not attempt to\nacquire cl_lock;\n3) Consequently, no deadlock condition is created.\n\nGiven that sc_count in nfsd_break_one_deleg remains non-zero, we can\nsafely perform refcount_dec on sc_count directly. This approach\neffectively avoids triggering deadlock warnings.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: prevent hang on link training fail\n\n[Why]\nWhen link training fails, the phy clock will be disabled. However, in\nenable_streams, it is assumed that link training succeeded and the\nmux selects the phy clock, causing a hang when a register write is made.\n\n[How]\nWhen enable_stream is hit, check if link training failed. If it did, fall\nback to the ref clock to avoid a hang and keep the system in a recoverable\nstate.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Use local fence in error path of xe_migrate_clear\n\nThe intent of the error path in xe_migrate_clear is to wait on locally\ngenerated fence and then return. The code is waiting on m->fence which\ncould be the local fence but this is only stable under the job mutex\nleading to a possible UAF. Fix code to wait on local fence.\n\n(cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74)

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/userptr: fix notifier vs folio deadlock\n\nUser is reporting what smells like notifier vs folio deadlock, where\nmigrate_pages_batch() on core kernel side is holding folio lock(s) and\nthen interacting with the mappings of it, however those mappings are\ntied to some userptr, which means calling into the notifier callback and\ngrabbing the notifier lock. With perfect timing it looks possible that\nthe pages we pulled from the hmm fault can get sniped by\nmigrate_pages_batch() at the same time that we are holding the notifier\nlock to mark the pages as accessed/dirty, but at this point we also want\nto grab the folio locks(s) to mark them as dirty, but if they are\ncontended from notifier/migrate_pages_batch side then we deadlock since\nfolio lock won't be dropped until we drop the notifier lock.\n\nFortunately the mark_page_accessed/dirty is not really needed in the\nfirst place it seems and should have already been done by hmm fault, so\njust remove it.\n\n(cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Silence oversized kvmalloc() warning\n\nsyzkaller triggered an oversized kvmalloc() warning.\nSilence it by adding __GFP_NOWARN.\n\nsyzkaller log:\n WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180\n CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__kvmalloc_node_noprof+0x175/0x180\n RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246\n RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b\n RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002\n RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000\n R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000\n R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000\n FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \n ib_umem_odp_get+0x1f6/0x390\n mlx5_ib_reg_user_mr+0x1e8/0x450\n ib_uverbs_reg_mr+0x28b/0x440\n ib_uverbs_write+0x7d3/0xa30\n vfs_write+0x1ac/0x6c0\n ksys_write+0x134/0x170\n ? __sanitizer_cov_trace_pc+0x1c/0x50\n do_syscall_64+0x50/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:\n\nmlxbf-bootctl: use sysfs_emit_at() in secure_boot_fuse_state_show()\n\nA warning is seen when running the latest kernel on a BlueField SOC:\n[251.512704] ------------[ cut here ]------------\n[251.512711] invalid sysfs_emit: buf:0000000003aa32ae\n[251.512720] WARNING: CPU: 1 PID: 705264 at fs/sysfs/file.c:767 sysfs_emit+0xac/0xc8\n\nThe warning is triggered because the mlxbf-bootctl driver invokes\n"sysfs_emit()" with a buffer pointer that is not aligned to the\nstart of the page. The driver should instead use "sysfs_emit_at()"\nto support non-zero offsets into the destination buffer.