This issue was addressed with improved checks. This issue is fixed in iOS 18.7.2 and iPadOS 18.7.2. Processing maliciously crafted web content may lead to an unexpected process crash.

This issue was addressed with improved checks This issue is fixed in Safari 26.1, visionOS 26.1, watchOS 26.1, iOS 26.1 and iPadOS 26.1, tvOS 26.1. Processing maliciously crafted web content may lead to an unexpected process crash.

This issue was addressed through improved state management. This issue is fixed in Safari 26.1, visionOS 26.1, watchOS 26.1, iOS 26.1 and iPadOS 26.1, tvOS 26.1. Processing maliciously crafted web content may lead to an unexpected process crash.

This issue was addressed through improved state management. This issue is fixed in iOS 26.1 and iPadOS 26.1, tvOS 26.1, Safari 26.1, visionOS 26.1. Processing maliciously crafted web content may lead to an unexpected process crash.

The issue was addressed with improved memory handling. This issue is fixed in Safari 26.1, visionOS 26.1, watchOS 26.1, iOS 26.1 and iPadOS 26.1, tvOS 26.1. Processing maliciously crafted web content may lead to an unexpected process crash.

The issue was addressed with improved memory handling. This issue is fixed in Safari 26, tvOS 26, watchOS 26, iOS 26 and iPadOS 26, visionOS 26. Processing maliciously crafted web content may lead to memory corruption.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_complete\n\nThere is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due to\nmemcpy from badly declared on-stack flexible array.\n\nAnother crash is in set_mesh_complete() due to double list_del via\nmgmt_pending_valid + mgmt_pending_remove.\n\nUse DEFINE_FLEX to declare the flexible array right, and don't memcpy\noutside bounds.\n\nAs mgmt_pending_valid removes the cmd from list, use mgmt_pending_free,\nand also report status on error.

No description is available for this CVE.

Multiple issues were addressed by disabling array allocation sinking. This issue is fixed in iOS 26.1 and iPadOS 26.1, Safari 26.1, visionOS 26.1. Processing maliciously crafted web content may lead to an unexpected process crash.

Kafka dissector crash in Wireshark 4.6.0 and 4.4.0 to 4.4.10 allows denial of service

7-Zip ZIP File Parsing Directory Traversal Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of 7-Zip. Interaction with this product is required to exploit this vulnerability but attack vectors may vary depending on the implementation.\n\nThe specific flaw exists within the handling of symbolic links in ZIP files. Crafted data in a ZIP file can cause the process to traverse to unintended directories. An attacker can leverage this vulnerability to execute code in the context of a service account. Was ZDI-CAN-26753.

A flaw was found in libvirt. External inactive snapshots for shut-down VMs are incorrectly created as world-readable, making it possible for unprivileged users to inspect the guest OS contents. This results in an information disclosure vulnerability.

A flaw was found in FFmpeg’s ALS audio decoder, where it does not properly check for memory allocation failures. This can cause the application to crash when processing certain malformed audio files. While it does not lead to data theft or system control, it can be used to disrupt services and cause a denial of service.

An issue was discovered in 5.1 before 5.1.14, 4.2 before 4.2.26, and 5.2 before 5.2.8.\nThe methods `QuerySet.filter()`, `QuerySet.exclude()`, and `QuerySet.get()`, and the class `Q()`, are subject to SQL injection when using a suitably crafted dictionary, with dictionary expansion, as the `_connector` argument.\nEarlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.\nDjango would like to thank cyberstan for reporting this issue.

An issue was discovered in 5.1 before 5.1.14, 4.2 before 4.2.26, and 5.2 before 5.2.8.\nNFKC normalization in Python is slow on Windows. As a consequence, `django.http.HttpResponseRedirect`, `django.http.HttpResponsePermanentRedirect`, and the shortcut `django.shortcuts.redirect` were subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters.\nEarlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.\nDjango would like to thank Seokchan Yoon for reporting this issue.

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, there is a use-after-free in PyObject_StealAttrString of pyOpenEXR_old.cpp. The legacy adapter defines PyObject_StealAttrString that calls PyObject_GetAttrString to obtain a new reference, immediately decrefs it, and returns the pointer. Callers then pass this dangling pointer to APIs like PyLong_AsLong/PyFloat_AsDouble, resulting in a use-after-free. This is invoked in multiple places (e.g., reading PixelType.v, Box2i, V2f, etc.) Versions 3.2.5, 3.3.6, and 3.4.3 fix the issue.

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.2.0 through 3.2.4, 3.3.0 through 3.3.5, and 3.4.0 through 3.4.2, a memory safety bug in the legacy OpenEXR Python adapter (the deprecated OpenEXR.InputFile wrapper) allow crashes and likely code execution when opening attacker-controlled EXR files or when passing crafted Python objects. Integer overflow and unchecked allocation in InputFile.channel() and InputFile.channels() can lead to heap overflow (32 bit) or a NULL deref (64 bit). Versions 3.2.5, 3.3.6, and 3.4.3 contain a patch for the issue.

OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.0 through 3.3.5 and 3.4.0 through 3.4.2, while fuzzing `openexr_exrcheck_fuzzer`, Valgrind reports a conditional branch depending on uninitialized data inside `generic_unpack`. This indicates a use of uninitialized memory. The issue can result in undefined behavior and/or a potential crash/denial of service. Versions 3.3.6 and 3.4.3 fix the issue.

h11 is a Python implementation of HTTP/1.1. Prior to version 0.16.0, a leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions. This issue has been patched in version 0.16.0. Since exploitation requires the combination of buggy h11 with a buggy (reverse) proxy, fixing either component is sufficient to mitigate this issue.

Memory safety bugs present in Firefox 144 and Thunderbird 144. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 145.

Sandbox escape due to incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox < 145.

Incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox < 145.

Sandbox escape due to incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox < 145.

Incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox < 145.

Incorrect boundary conditions in the Graphics: WebGPU component. This vulnerability affects Firefox < 145.

containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode.

If kdcproxy receives a request for a realm which does not have server addresses defined in its configuration, by default, it will query SRV records in the DNS zone matching the requested realm name. This creates a server-side request forgery vulnerability, since an attacker could send a request for a realm matching a DNS zone where they created SRV records pointing to arbitrary ports and hostnames (which may resolve to loopback or internal IP addresses). This vulnerability can be exploited to probe internal network topology and firewall rules, perform port scanning, and exfiltrate data. Deployments where\nthe "use_dns" setting is explicitly set to false are not affected.

In the Linux kernel, the following vulnerability has been resolved:\nmedia: iris: fix module removal if firmware download failed\nFix remove if firmware failed to load:\nqcom-iris aa00000.video-codec: Direct firmware load for qcom/vpu/vpu33_p4.mbn failed with error -2\nqcom-iris aa00000.video-codec: firmware download failed\nqcom-iris aa00000.video-codec: core init failed\nthen:\n$ echo aa00000.video-codec > /sys/bus/platform/drivers/qcom-iris/unbind\nTriggers:\ngenpd genpd:1:aa00000.video-codec: Runtime PM usage count underflow!\n------------[ cut here ]------------\nvideo_cc_mvs0_clk already disabled\nWARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#1: sh/542\n\npc : clk_core_disable+0xa4/0xac\nlr : clk_core_disable+0xa4/0xac\n\nCall trace:\nclk_core_disable+0xa4/0xac (P)\nclk_disable+0x30/0x4c\niris_disable_unprepare_clock+0x20/0x48 [qcom_iris]\niris_vpu_power_off_hw+0x48/0x58 [qcom_iris]\niris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris]\niris_vpu_power_off+0x34/0x84 [qcom_iris]\niris_core_deinit+0x44/0xc8 [qcom_iris]\niris_remove+0x20/0x48 [qcom_iris]\nplatform_remove+0x20/0x30\ndevice_remove+0x4c/0x80\n\n---[ end trace 0000000000000000 ]---\n------------[ cut here ]------------\nvideo_cc_mvs0_clk already unprepared\nWARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#2: sh/542\n\npc : clk_core_unprepare+0xf0/0x110\nlr : clk_core_unprepare+0xf0/0x110\n\nCall trace:\nclk_core_unprepare+0xf0/0x110 (P)\nclk_unprepare+0x2c/0x44\niris_disable_unprepare_clock+0x28/0x48 [qcom_iris]\niris_vpu_power_off_hw+0x48/0x58 [qcom_iris]\niris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris]\niris_vpu_power_off+0x34/0x84 [qcom_iris]\niris_core_deinit+0x44/0xc8 [qcom_iris]\niris_remove+0x20/0x48 [qcom_iris]\nplatform_remove+0x20/0x30\ndevice_remove+0x4c/0x80\n\n---[ end trace 0000000000000000 ]---\ngenpd genpd:0:aa00000.video-codec: Runtime PM usage count underflow!\n------------[ cut here ]------------\ngcc_video_axi0_clk already disabled\nWARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#4: sh/542\n\npc : clk_core_disable+0xa4/0xac\nlr : clk_core_disable+0xa4/0xac\n\nCall trace:\nclk_core_disable+0xa4/0xac (P)\nclk_disable+0x30/0x4c\niris_disable_unprepare_clock+0x20/0x48 [qcom_iris]\niris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris]\niris_vpu_power_off+0x48/0x84 [qcom_iris]\niris_core_deinit+0x44/0xc8 [qcom_iris]\niris_remove+0x20/0x48 [qcom_iris]\nplatform_remove+0x20/0x30\ndevice_remove+0x4c/0x80\n\n------------[ cut here ]------------\ngcc_video_axi0_clk already unprepared\nWARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#4: sh/542\n\npc : clk_core_unprepare+0xf0/0x110\nlr : clk_core_unprepare+0xf0/0x110\n\nCall trace:\nclk_core_unprepare+0xf0/0x110 (P)\nclk_unprepare+0x2c/0x44\niris_disable_unprepare_clock+0x28/0x48 [qcom_iris]\niris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris]\niris_vpu_power_off+0x48/0x84 [qcom_iris]\niris_core_deinit+0x44/0xc8 [qcom_iris]\niris_remove+0x20/0x48 [qcom_iris]\nplatform_remove+0x20/0x30\ndevice_remove+0x4c/0x80\n\n---[ end trace 0000000000000000 ]---\nSkip deinit if initialization never succeeded.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\nmount: handle NULL values in mnt_ns_release()\nWhen calling in listmount() mnt_ns_release() may be passed a NULL\npointer. Handle that case gracefully.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/amdkfd: Fix kfd process ref leaking when userptr unmapping\nkfd_lookup_process_by_pid hold the kfd process reference to ensure it\ndoesn't get destroyed while sending the segfault event to user space.\nCalling kfd_lookup_process_by_pid as function parameter leaks the kfd\nprocess refcount and miss the NULL pointer check if app process is\nalready destroyed.

In the Linux kernel, the following vulnerability has been resolved:\nnet: usb: lan78xx: Fix lost EEPROM read timeout error(-ETIMEDOUT) in lan78xx_read_raw_eeprom\nSyzbot reported read of uninitialized variable BUG with following call stack.\nlan78xx 8-1:1.0 (unnamed net_device) (uninitialized): EEPROM read operation timeout\n=====================================================\nBUG: KMSAN: uninit-value in lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline]\nBUG: KMSAN: uninit-value in lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]\nBUG: KMSAN: uninit-value in lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241\nlan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline]\nlan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]\nlan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241\nlan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766\nlan78xx_probe+0x225c/0x3310 drivers/net/usb/lan78xx.c:4707\nLocal variable sig.i.i created at:\nlan78xx_read_eeprom drivers/net/usb/lan78xx.c:1092 [inline]\nlan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline]\nlan78xx_reset+0x77e/0x2cd0 drivers/net/usb/lan78xx.c:3241\nlan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766\nThe function lan78xx_read_raw_eeprom failed to properly propagate EEPROM\nread timeout errors (-ETIMEDOUT). In the fallthrough path, it first\nattempted to restore the pin configuration for LED outputs and then\nreturned only the status of that restore operation, discarding the\noriginal timeout error.\nAs a result, callers could mistakenly treat the data buffer as valid\neven though the EEPROM read had actually timed out with no data or partial\ndata.\nTo fix this, handle errors in restoring the LED pin configuration separately.\nIf the restore succeeds, return any prior EEPROM timeout error correctly\nto the caller.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\nbpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}\nCilium has a BPF egress gateway feature which forces outgoing K8s Pod\ntraffic to pass through dedicated egress gateways which then SNAT the\ntraffic in order to interact with stable IPs outside the cluster.\nThe traffic is directed to the gateway via vxlan tunnel in collect md\nmode. A recent BPF change utilized the bpf_redirect_neigh() helper to\nforward packets after the arrival and decap on vxlan, which turned out\nover time that the kmalloc-256 slab usage in kernel was ever-increasing.\nThe issue was that vxlan allocates the metadata_dst object and attaches\nit through a fake dst entry to the skb. The latter was never released\nthough given bpf_redirect_neigh() was merely setting the new dst entry\nvia skb_dst_set() without dropping an existing one first.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP\n\nWhen running as an SNP or TDX guest under KVM, force the legacy PCI hole,\ni.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC\nvia a forced variable MTRR range.\n\nIn most KVM-based setups, legacy devices such as the HPET and TPM are\nenumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, and\noptionally a SystemMemory descriptor for an OperationRegion, e.g. if the\ndevice needs to be accessed via a Control Method.\n\nIf a SystemMemory entry is present, then the kernel's ACPI driver will\nauto-ioremap the region so that it can be accessed at will. However, the\nACPI spec doesn't provide a way to enumerate the memory type of\nSystemMemory regions, i.e. there's no way to tell software that a region\nmust be mapped as UC vs. WB, etc. As a result, Linux's ACPI driver always\nmaps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.\n\nThe dedicated device drivers however, e.g. the HPET driver and TPM driver,\nwant to map their associated memory as UC or WC, as accessing PCI devices\nusing WB is unsupported.\n\nOn bare metal and non-CoCO, the conflicting requirements "work" as firmware\nconfigures the PCI hole (and other device memory) to be UC in the MTRRs.\nSo even though the ACPI mappings request WB, they are forced to UC- in the\nkernel's tracking due to the kernel properly handling the MTRR overrides,\nand thus are compatible with the drivers' requested WC/UC-.\n\nWith force WB MTRRs on SNP and TDX guests, the ACPI mappings get their\nrequested WB if the ACPI mappings are established before the dedicated\ndriver code attempts to initialize the device. E.g. if acpi_init()\nruns before the corresponding device driver is probed, ACPI's WB mapping\nwill "win", and result in the driver's ioremap() failing because the\nexisting WB mapping isn't compatible with the requested WC/UC-.\n\nE.g. when a TPM is emulated by the hypervisor (ignoring the security\nimplications of relying on what is allegedly an untrusted entity to store\nmeasurements), the TPM driver will request UC and fail:\n\n [ 1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0\n [ 1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12\n\nNote, the '0x2' and '0x0' values refer to "enum page_cache_mode", not x86's\nmemtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).\nE.g. tracing mapping requests for TPM TIS yields:\n\n Mapping TPM TIS with req_type = 0\n WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460\n Modules linked in:\n CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY\n Tainted: [W]=WARN\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025\n RIP: 0010:memtype_reserve+0x2ab/0x460\n __ioremap_caller+0x16d/0x3d0\n ioremap_cache+0x17/0x30\n x86_acpi_os_ioremap+0xe/0x20\n acpi_os_map_iomem+0x1f3/0x240\n acpi_os_map_memory+0xe/0x20\n acpi_ex_system_memory_space_handler+0x273/0x440\n acpi_ev_address_space_dispatch+0x176/0x4c0\n acpi_ex_access_region+0x2ad/0x530\n acpi_ex_field_datum_io+0xa2/0x4f0\n acpi_ex_extract_from_field+0x296/0x3e0\n acpi_ex_read_data_from_field+0xd1/0x460\n acpi_ex_resolve_node_to_value+0x2ee/0x530\n acpi_ex_resolve_to_value+0x1f2/0x540\n acpi_ds_evaluate_name_path+0x11b/0x190\n acpi_ds_exec_end_op+0x456/0x960\n acpi_ps_parse_loop+0x27a/0xa50\n acpi_ps_parse_aml+0x226/0x600\n acpi_ps_execute_method+0x172/0x3e0\n acpi_ns_evaluate+0x175/0x5f0\n acpi_evaluate_object+0x213/0x490\n acpi_evaluate_integer+0x6d/0x140\n acpi_bus_get_status+0x93/0x150\n acpi_add_single_object+0x43a/0x7c0\n acpi_bus_check_add+0x149/0x3a0\n acpi_bus_check_add_1+0x16/0x30\n acpi_ns_walk_namespace+0x22c/0x360\n acpi_walk_namespace+0x15c/0x170\n acpi_bus_scan+0x1dd/0x200\n acpi_scan_init+0xe5/0x2b0\n acpi_init+0x264/0x5b0\n do_one_i\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nmailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop\nThe cleanup loop was starting at the wrong array index, causing\nout-of-bounds access.\nStart the loop at the correct index for zero-indexed arrays to prevent\naccessing memory beyond the allocated array bounds.

In the Linux kernel, the following vulnerability has been resolved:\naccel/qaic: Fix bootlog initialization ordering\nAs soon as we queue MHI buffers to receive the bootlog from the device,\nwe could be receiving data. Therefore all the resources needed to\nprocess that data need to be setup prior to queuing the buffers.\nWe currently initialize some of the resources after queuing the buffers\nwhich creates a race between the probe() and any data that comes back\nfrom the device. If the uninitialized resources are accessed, we could\nsee page faults.\nFix the init ordering to close the race.

In the Linux kernel, the following vulnerability has been resolved:\ntls: wait for pending async decryptions if tls_strp_msg_hold fails\nAsync decryption calls tls_strp_msg_hold to create a clone of the\ninput skb to hold references to the memory it uses. If we fail to\nallocate that clone, proceeding with async decryption can lead to\nvarious issues (UAF on the skb, writing into userspace memory after\nthe recv() call has returned).\nIn this case, wait for all pending decryption requests.

In the Linux kernel, the following vulnerability has been resolved:\nidpf: cleanup remaining SKBs in PTP flows\nWhen the driver requests Tx timestamp value, one of the first steps is\nto clone SKB using skb_get. It increases the reference counter for that\nSKB to prevent unexpected freeing by another component.\nHowever, there may be a case where the index is requested, SKB is\nassigned and never consumed by PTP flows - for example due to reset during\nrunning PTP apps.\nAdd a check in release timestamping function to verify if the SKB\nassigned to Tx timestamp latch was freed, and release remaining SKBs.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Fix SMP ordering in switch_mm_irqs_off()\n\nStephen noted that it is possible to not have an smp_mb() between\nthe loaded_mm store and the tlb_gen load in switch_mm(), meaning the\nordering against flush_tlb_mm_range() goes out the window, and it\nbecomes possible for switch_mm() to not observe a recent tlb_gen\nupdate and fail to flush the TLBs.\n\n[ dhansen: merge conflict fixed by Ingo ]

In the Linux kernel, the following vulnerability has been resolved:\naccel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()\nCurrently, if find_and_map_user_pages() takes a DMA xfer request from the\nuser with a length field set to 0, or in a rare case, the host receives\nQAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_size\nis equal to the requested transaction size, the function will return 0\nbefore allocating an sgt or setting the fields of the dma_xfer struct.\nIn that case, encode_addr_size_pairs() will try to access the sgt which\nwill lead to a general protection fault.\nReturn an EINVAL in case the user provides a zero-sized ALP, or the device\nrequests continuation after all of the bytes have been transferred.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/xe/guc: Check GuC running state before deregistering exec queue\nIn normal operation, a registered exec queue is disabled and\nderegistered through the GuC, and freed only after the GuC confirms\ncompletion. However, if the driver is forced to unbind while the exec\nqueue is still running, the user may call exec_destroy() after the GuC\nhas already been stopped and CT communication disabled.\nIn this case, the driver cannot receive a response from the GuC,\npreventing proper cleanup of exec queue resources. Fix this by directly\nreleasing the resources when GuC is not running.\nHere is the failure dmesg log:\n"\n[ 468.089581] ---[ end trace 0000000000000000 ]---\n[ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535)\n[ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535\n[ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1\n[ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1)\n[ 468.092716] ------------[ cut here ]------------\n[ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe]\n"\nv2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled().\nAs CT may go down and come back during VF migration.\n(cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)

In the Linux kernel, the following vulnerability has been resolved:\nsched/deadline: Stop dl_server before CPU goes offline\nIBM CI tool reported kernel warning[1] when running a CPU removal\noperation through drmgr[2]. i.e "drmgr -c cpu -r -q 1"\nWARNING: CPU: 0 PID: 0 at kernel/sched/cpudeadline.c:219 cpudl_set+0x58/0x170\nNIP [c0000000002b6ed8] cpudl_set+0x58/0x170\nLR [c0000000002b7cb8] dl_server_timer+0x168/0x2a0\nCall Trace:\n[c000000002c2f8c0] init_stack+0x78c0/0x8000 (unreliable)\n[c0000000002b7cb8] dl_server_timer+0x168/0x2a0\n[c00000000034df84] __hrtimer_run_queues+0x1a4/0x390\n[c00000000034f624] hrtimer_interrupt+0x124/0x300\n[c00000000002a230] timer_interrupt+0x140/0x320\nGit bisects to: commit 4ae8d9aa9f9d ("sched/deadline: Fix dl_server getting stuck")\nThis happens since:\n- dl_server hrtimer gets enqueued close to cpu offline, when\nkthread_park enqueues a fair task.\n- CPU goes offline and drmgr removes it from cpu_present_mask.\n- hrtimer fires and warning is hit.\nFix it by stopping the dl_server before CPU is marked dead.\n[1]: https://lore.kernel.org/all/8218e149-7718-4432-9312-f97297c352b9@linux.ibm.com/\n[2]: https://github.com/ibm-power-utilities/powerpc-utils/tree/next/src/drmgr\n[sshegde: wrote the changelog and tested it]

In the Linux kernel, the following vulnerability has been resolved:\nASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails\ndevm_kasprintf() may return NULL on memory allocation failure,\nbut the debug message prints cpus->dai_name before checking it.\nMove the dev_dbg() call after the NULL check to prevent potential\nNULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\nmailbox: zynqmp-ipi: Fix SGI cleanup on unbind\nThe driver incorrectly determines SGI vs SPI interrupts by checking IRQ\nnumber < 16, which fails with dynamic IRQ allocation. During unbind,\nthis causes improper SGI cleanup leading to kernel crash.\nAdd explicit irq_type field to pdata for reliable identification of SGI\ninterrupts (type-2) and only clean up SGI resources when appropriate.

In the Linux kernel, the following vulnerability has been resolved:\nxen/events: Return -EEXIST for bound VIRQs\nChange find_virq() to return -EEXIST when a VIRQ is bound to a\ndifferent CPU than the one passed in. With that, remove the BUG_ON()\nfrom bind_virq_to_irq() to propogate the error upwards.\nSome VIRQs are per-cpu, but others are per-domain or global. Those must\nbe bound to CPU0 and can then migrate elsewhere. The lookup for\nper-domain and global will probably fail when migrated off CPU 0,\nespecially when the current CPU is tracked. This now returns -EEXIST\ninstead of BUG_ON().\nA second call to bind a per-domain or global VIRQ is not expected, but\nmake it non-fatal to avoid trying to look up the irq, since we don't\nknow which per_cpu(virq_to_irq) it will be in.

In the Linux kernel, the following vulnerability has been resolved:\nxsk: Harden userspace-supplied xdp_desc validation\nTurned out certain clearly invalid values passed in xdp_desc from\nuserspace can pass xp_{,un}aligned_validate_desc() and then lead\nto UBs or just invalid frames to be queued for xmit.\ndesc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len\ncan cause positive integer overflow and wraparound, the same way low\nenough desc->addr with a non-zero pool->tx_metadata_len can cause\nnegative integer overflow. Both scenarios can then pass the\nvalidation successfully.\nThis doesn't happen with valid XSk applications, but can be used\nto perform attacks.\nAlways promote desc->len to ``u64`` first to exclude positive\noverflows of it. Use explicit check_{add,sub}_overflow() when\nvalidating desc->addr (which is ``u64`` already).\nbloat-o-meter reports a little growth of the code size:\nadd/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)\nFunction old new delta\nxskq_cons_peek_desc 299 330 +31\nxsk_tx_peek_release_desc_batch 973 1002 +29\nxsk_generic_xmit 3148 3132 -16\nbut hopefully this doesn't hurt the performance much.

In the Linux kernel, the following vulnerability has been resolved:\nipv6: use RCU in ip6_output()\nUse RCU in ip6_output() in order to use dst_dev_rcu() to prevent\npossible UAF.\nWe can remove rcu_read_lock()/rcu_read_unlock() pairs\nfrom ip6_finish_output2().

In the Linux kernel, the following vulnerability has been resolved:\nEDAC/i10nm: Skip DIMM enumeration on a disabled memory controller\nWhen loading the i10nm_edac driver on some Intel Granite Rapids servers,\na call trace may appear as follows:\nUBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16\nshift exponent -66 is negative\n...\n__ubsan_handle_shift_out_of_bounds+0x1e3/0x390\nskx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]\ni10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]\nskx_register_mci+0x159/0x220 [skx_edac_common]\ni10nm_init+0xcb0/0x1ff0 [i10nm_edac]\n...\nThis occurs because some BIOS may disable a memory controller if there\naren't any memory DIMMs populated on this memory controller. The DIMMMTR\nregister of this disabled memory controller contains the invalid value\n~0, resulting in the call trace above.\nFix this call trace by skipping DIMM enumeration on a disabled memory\ncontroller.

In the Linux kernel, the following vulnerability has been resolved:\nPM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()\nThe drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which\nwould lead to a error pointer dereference. Use IS_ERR_OR_NULL() to check\nthat the pointer is valid.

In the Linux kernel, the following vulnerability has been resolved:\niommu/vt-d: debugfs: Fix legacy mode page table dump logic\nIn legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR\nmaybe uninitialized or zero in that case and may cause oops like:\nOops: general protection fault, probably for non-canonical address\n0xf00087d3f000f000: 0000 [#1] SMP NOPTI\nCPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014\nRIP: 0010:pgtable_walk_level+0x98/0x150\nRSP: 0018:ffffc90000f279c0 EFLAGS: 00010206\nRAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e\nRDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000\nRBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002\nR10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000\nR13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98\nFS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0\nPKRU: 55555554\nCall Trace:\n\npgtable_walk_level+0x88/0x150\ndomain_translation_struct_show.isra.0+0x2d9/0x300\ndev_domain_translation_struct_show+0x20/0x40\nseq_read_iter+0x12d/0x490\n...\nAvoid walking the page table if TT is not 00b or 01b.

In the Linux kernel, the following vulnerability has been resolved:\nASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping\nWhen an invalid value is passed via quirk option, currently\nbytcr_rt5640 driver only shows an error message but leaves as is.\nThis may lead to unepxected results like OOB access.\nThis patch corrects the input mapping to the certain default value if\nan invalid value is passed.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/msm: Fix bootup splat with separate_gpu_drm modparam\nThe drm_gem_for_each_gpuvm_bo() call from lookup_vma() accesses\ndrm_gem_obj.gpuva.list, which is not initialized when the drm driver\ndoes not support DRIVER_GEM_GPUVA feature. Enable it for msm_kms\ndrm driver to fix the splat seen when msm.separate_gpu_drm=1 modparam\nis set:\n[ 9.506020] Unable to handle kernel paging request at virtual address fffffffffffffff0\n[ 9.523160] Mem abort info:\n[ 9.523161] ESR = 0x0000000096000006\n[ 9.523163] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 9.523165] SET = 0, FnV = 0\n[ 9.523166] EA = 0, S1PTW = 0\n[ 9.523167] FSC = 0x06: level 2 translation fault\n[ 9.523169] Data abort info:\n[ 9.523170] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 9.523171] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 9.523172] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 9.523174] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000ad370f000\n[ 9.523176] [fffffffffffffff0] pgd=0000000000000000, p4d=0000000ad4787403, pud=0000000ad4788403, pmd=0000000000000000\n[ 9.523184] Internal error: Oops: 0000000096000006 [#1] SMP\n[ 9.592968] CPU: 9 UID: 0 PID: 448 Comm: (udev-worker) Not tainted 6.17.0-rc4-assorted-fix-00005-g0e9bb53a2282-dirty #3 PREEMPT\n[ 9.592970] Hardware name: Qualcomm CRD, BIOS 6.0.240718.BOOT.MXF.2.4-00515-HAMOA-1 07/18/2024\n[ 9.592971] pstate: a1400005 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 9.592973] pc : lookup_vma+0x28/0xe0 [msm]\n[ 9.592996] lr : get_vma_locked+0x2c/0x128 [msm]\n[ 9.763632] sp : ffff800082dab460\n[ 9.763666] Call trace:\n[ 9.763668] lookup_vma+0x28/0xe0 [msm] (P)\n[ 9.763688] get_vma_locked+0x2c/0x128 [msm]\n[ 9.763706] msm_gem_get_and_pin_iova_range+0x68/0x11c [msm]\n[ 9.763723] msm_gem_get_and_pin_iova+0x18/0x24 [msm]\n[ 9.763740] msm_fbdev_driver_fbdev_probe+0xd0/0x258 [msm]\n[ 9.763760] __drm_fb_helper_initial_config_and_unlock+0x288/0x528 [drm_kms_helper]\n[ 9.763771] drm_fb_helper_initial_config+0x44/0x54 [drm_kms_helper]\n[ 9.763779] drm_fbdev_client_hotplug+0x84/0xd4 [drm_client_lib]\n[ 9.763782] drm_client_register+0x58/0x9c [drm]\n[ 9.763806] drm_fbdev_client_setup+0xe8/0xcf0 [drm_client_lib]\n[ 9.763809] drm_client_setup+0xb4/0xd8 [drm_client_lib]\n[ 9.763811] msm_drm_kms_post_init+0x2c/0x3c [msm]\n[ 9.763830] msm_drm_init+0x1a8/0x22c [msm]\n[ 9.763848] msm_drm_bind+0x30/0x3c [msm]\n[ 9.919273] try_to_bring_up_aggregate_device+0x168/0x1d4\n[ 9.919283] __component_add+0xa4/0x170\n[ 9.919286] component_add+0x14/0x20\n[ 9.919288] msm_dp_display_probe_tail+0x4c/0xac [msm]\n[ 9.919315] msm_dp_auxbus_done_probe+0x14/0x20 [msm]\n[ 9.919335] dp_aux_ep_probe+0x4c/0xf0 [drm_dp_aux_bus]\n[ 9.919341] really_probe+0xbc/0x298\n[ 9.919345] __driver_probe_device+0x78/0x12c\n[ 9.919348] driver_probe_device+0x40/0x160\n[ 9.919350] __driver_attach+0x94/0x19c\n[ 9.919353] bus_for_each_dev+0x74/0xd4\n[ 9.919355] driver_attach+0x24/0x30\n[ 9.919358] bus_add_driver+0xe4/0x208\n[ 9.919360] driver_register+0x60/0x128\n[ 9.919363] __dp_aux_dp_driver_register+0x24/0x30 [drm_dp_aux_bus]\n[ 9.919365] atana33xc20_init+0x20/0x1000 [panel_samsung_atna33xc20]\n[ 9.919370] do_one_initcall+0x6c/0x1b0\n[ 9.919374] do_init_module+0x58/0x234\n[ 9.919377] load_module+0x19cc/0x1bd4\n[ 9.919380] init_module_from_file+0x84/0xc4\n[ 9.919382] __arm64_sys_finit_module+0x1b8/0x2cc\n[ 9.919384] invoke_syscall+0x48/0x110\n[ 9.919389] el0_svc_common.constprop.0+0xc8/0xe8\n[ 9.919393] do_el0_svc+0x20/0x2c\n[ 9.919396] el0_svc+0x34/0xf0\n[ 9.919401] el0t_64_sync_handler+0xa0/0xe4\n[ 9.919403] el0t_64_sync+0x198/0x19c\n[ 9.919407] Code: eb0000bf 54000480 d100a003 aa0303e2 (f8418c44)\n[ 9.919410] ---[ end trace 0000000000000000 ]---\nPatchwork: https://patchwork.freedesktop.org/pa\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nLoongArch: BPF: No support of struct argument in trampoline programs\nThe current implementation does not support struct argument. This causes\na oops when running bpf selftest:\n$ ./test_progs -a tracing_struct\nOops[#1]:\nCPU -1 Unable to handle kernel paging request at virtual address 0000000000000018, era == 9000000085bef268, ra == 90000000844f3938\nrcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\nrcu: 1-...0: (19 ticks this GP) idle=1094/1/0x4000000000000000 softirq=1380/1382 fqs=801\nrcu: (detected by 0, t=5252 jiffies, g=1197, q=52 ncpus=4)\nSending NMI from CPU 0 to CPUs 1:\nrcu: rcu_preempt kthread starved for 2495 jiffies! g1197 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2\nrcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.\nrcu: RCU grace-period kthread stack dump:\ntask:rcu_preempt state:I stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x00000800\nStack : 9000000100423e80 0000000000000402 0000000000000010 90000001003b0680\n9000000085d88000 0000000000000000 0000000000000040 9000000087159350\n9000000085c2b9b0 0000000000000001 900000008704a000 0000000000000005\n00000000ffff355b 00000000ffff355b 0000000000000000 0000000000000004\n9000000085d90510 0000000000000000 0000000000000002 7b5d998f8281e86e\n00000000ffff355c 7b5d998f8281e86e 000000000000003f 9000000087159350\n900000008715bf98 0000000000000005 9000000087036000 900000008704a000\n9000000100407c98 90000001003aff80 900000008715c4c0 9000000085c2b9b0\n00000000ffff355b 9000000085c33d3c 00000000000000b4 0000000000000000\n9000000007002150 00000000ffff355b 9000000084615480 0000000007000002\n...\nCall Trace:\n[<9000000085c2a868>] __schedule+0x410/0x1520\n[<9000000085c2b9ac>] schedule+0x34/0x190\n[<9000000085c33d38>] schedule_timeout+0x98/0x140\n[<90000000845e9120>] rcu_gp_fqs_loop+0x5f8/0x868\n[<90000000845ed538>] rcu_gp_kthread+0x260/0x2e0\n[<900000008454e8a4>] kthread+0x144/0x238\n[<9000000085c26b60>] ret_from_kernel_thread+0x28/0xc8\n[<90000000844f20e4>] ret_from_kernel_thread_asm+0xc/0x88\nrcu: Stack dump where RCU GP kthread last ran:\nSending NMI from CPU 0 to CPUs 2:\nNMI backtrace for cpu 2 skipped: idling at idle_exit+0x0/0x4\nReject it for now.

In the Linux kernel, the following vulnerability has been resolved:\nf2fs: fix to avoid migrating empty section\nIt reports a bug from device w/ zufs:\nF2FS-fs (dm-64): Inconsistent segment (173822) type [1, 0] in SSA and SIT\nF2FS-fs (dm-64): Stopped filesystem due to reason: 4\nThread AThread B\n- f2fs_expand_inode_data\n- f2fs_allocate_pinning_section\n- f2fs_gc_range\n- do_garbage_collect w/ segno #x\n- writepage\n- f2fs_allocate_data_block\n- new_curseg\n- allocate segno #x\nThe root cause is: fallocate on pinning file may race w/ block allocation\nas above, result in do_garbage_collect() from fallocate() may migrate\nsegment which is just allocated by a log, the log will update segment type\nin its in-memory structure, however GC will get segment type from on-disk\nSSA block, once segment type changes by log, we can detect such\ninconsistency, then shutdown filesystem.\nIn this case, on-disk SSA shows type of segno #173822 is 1 (SUM_TYPE_NODE),\nhowever segno #173822 was just allocated as data type segment, so in-memory\nSIT shows type of segno #173822 is 0 (SUM_TYPE_DATA).\nChange as below to fix this issue:\n- check whether current section is empty before gc\n- add sanity checks on do_garbage_collect() to avoid any race case, result\nin migrating segment used by log.\n- btw, it fixes misc issue in printed logs: "SSA and SIT" -> "SIT and SSA".

In the Linux kernel, the following vulnerability has been resolved:\ndrm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions\nThe function dc_stream_set_cursor_attributes() currently dereferences\nthe `stream` pointer and nested members `stream->ctx->dc->current_state`\nwithout checking for NULL.\nAll callers of these functions, such as in\n`dcn30_apply_idle_power_optimizations()` and\n`amdgpu_dm_plane_handle_cursor_update()`, already perform NULL checks\nbefore calling these functions.\nFixes below:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:336 dc_stream_program_cursor_attributes()\nerror: we previously assumed 'stream' could be null (see line 334)\ndrivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c\n327 bool dc_stream_program_cursor_attributes(\n328 struct dc_stream_state *stream,\n329 const struct dc_cursor_attributes *attributes)\n330 {\n331 struct dc *dc;\n332 bool reset_idle_optimizations = false;\n333\n334 dc = stream ? stream->ctx->dc : NULL;\n^^^^^^\nThe old code assumed stream could be NULL.\n335\n--> 336 if (dc_stream_set_cursor_attributes(stream, attributes)) {\n^^^^^^\nThe refactor added an unchecked dereference.\ndrivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c\n313 bool dc_stream_set_cursor_attributes(\n314 struct dc_stream_state *stream,\n315 const struct dc_cursor_attributes *attributes)\n316 {\n317 bool result = false;\n318\n319 if (dc_stream_check_cursor_attributes(stream, stream->ctx->dc->current_state, attributes)) {\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here.\nThis function used to check for if stream as NULL and return false at\nthe start. Probably we should add that back.

In the Linux kernel, the following vulnerability has been resolved:\nblk-throttle: fix access race during throttle policy activation\nOn repeated cold boots we occasionally hit a NULL pointer crash in\nblk_should_throtl() when throttling is consulted before the throttle\npolicy is fully enabled for the queue. Checking only q->td != NULL is\ninsufficient during early initialization, so blkg_to_pd() for the\nthrottle policy can still return NULL and blkg_to_tg() becomes NULL,\nwhich later gets dereferenced.\nUnable to handle kernel NULL pointer dereference\nat virtual address 0000000000000156\n...\npc : submit_bio_noacct+0x14c/0x4c8\nlr : submit_bio_noacct+0x48/0x4c8\nsp : ffff800087f0b690\nx29: ffff800087f0b690 x28: 0000000000005f90 x27: ffff00068af393c0\nx26: 0000000000080000 x25: 000000000002fbc0 x24: ffff000684ddcc70\nx23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000\nx20: 0000000000080000 x19: ffff000684ddcd08 x18: ffffffffffffffff\nx17: 0000000000000000 x16: ffff80008132a550 x15: 0000ffff98020fff\nx14: 0000000000000000 x13: 1fffe000d11d7021 x12: ffff000688eb810c\nx11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60\nx8 : 00000a6fb8a86e85 x7 : 000000000000111e x6 : 0000000000000002\nx5 : 0000000000000246 x4 : 0000000000015cff x3 : 0000000000394500\nx2 : ffff000682e35e40 x1 : 0000000000364940 x0 : 000000000000001a\nCall trace:\nsubmit_bio_noacct+0x14c/0x4c8\nverity_map+0x178/0x2c8\n__map_bio+0x228/0x250\ndm_submit_bio+0x1c4/0x678\n__submit_bio+0x170/0x230\nsubmit_bio_noacct_nocheck+0x16c/0x388\nsubmit_bio_noacct+0x16c/0x4c8\nsubmit_bio+0xb4/0x210\nf2fs_submit_read_bio+0x4c/0xf0\nf2fs_mpage_readpages+0x3b0/0x5f0\nf2fs_readahead+0x90/0xe8\nTighten blk_throtl_activated() to also require that the throttle policy\nbit is set on the queue:\nreturn q->td != NULL &&\ntest_bit(blkcg_policy_throtl.plid, q->blkcg_pols);\nThis prevents blk_should_throtl() from accessing throttle group state\nuntil policy data has been attached to blkgs.

In the Linux kernel, the following vulnerability has been resolved:\nPCI/pwrctrl: Fix double cleanup on devm_add_action_or_reset() failure\nWhen devm_add_action_or_reset() fails, it calls the passed cleanup\nfunction. Hence the caller must not repeat that cleanup.\nReplace the "goto err_regulator_free" by the actual freeing, as there\nwill never be a need again for a second user of this label.

In the Linux kernel, the following vulnerability has been resolved:\nnvdimm: ndtest: Return -ENOMEM if devm_kcalloc() fails in ndtest_probe()\ndevm_kcalloc() may fail. ndtest_probe() allocates three DMA address\narrays (dcr_dma, label_dma, dimm_dma) and later unconditionally uses\nthem in ndtest_nvdimm_init(), which can lead to a NULL pointer\ndereference under low-memory conditions.\nCheck all three allocations and return -ENOMEM if any allocation fails,\njumping to the common error path. Do not emit an extra error message\nsince the allocator already warns on allocation failure.

In the Linux kernel, the following vulnerability has been resolved:\nbpf: dont report verifier bug for missing bpf_scc_visit on speculative path\nSyzbot generated a program that triggers a verifier_bug() call in\nmaybe_exit_scc(). maybe_exit_scc() assumes that, when called for a\nstate with insn_idx in some SCC, there should be an instance of struct\nbpf_scc_visit allocated for that SCC. Turns out the assumption does\nnot hold for speculative execution paths. See example in the next\npatch.\nmaybe_scc_exit() is called from update_branch_counts() for states that\nreach branch count of zero, meaning that path exploration for a\nparticular path is finished. Path exploration can finish in one of\nthree ways:\na. Verification error is found. In this case, update_branch_counts()\nis called only for non-speculative paths.\nb. Top level BPF_EXIT is reached. Such instructions are never a part of\nan SCC, so compute_scc_callchain() in maybe_scc_exit() will return\nfalse, and maybe_scc_exit() will return early.\nc. A checkpoint is reached and matched. Checkpoints are created by\nis_state_visited(), which calls maybe_enter_scc(), which allocates\nbpf_scc_visit instances for checkpoints within SCCs.\nHence, for non-speculative symbolic execution paths, the assumption\nstill holds: if maybe_scc_exit() is called for a state within an SCC,\nbpf_scc_visit instance must exist.\nThis patch removes the verifier_bug() call for speculative paths.

In the Linux kernel, the following vulnerability has been resolved:\nALSA: pcm: Disable bottom softirqs as part of spin_lock_irq() on PREEMPT_RT\nsnd_pcm_group_lock_irq() acquires a spinlock_t and disables interrupts\nvia spin_lock_irq(). This also implicitly disables the handling of\nsoftirqs such as TIMER_SOFTIRQ.\nOn PREEMPT_RT softirqs are preemptible and spin_lock_irq() does not\ndisable them. That means a timer can be invoked during spin_lock_irq()\non the same CPU. Due to synchronisations reasons local_bh_disable() has\na per-CPU lock named softirq_ctrl.lock which synchronizes individual\nsoftirq against each other.\nsyz-bot managed to trigger a lockdep report where softirq_ctrl.lock is\nacquired in hrtimer_cancel() in addition to hrtimer_run_softirq(). This\nis a possible deadlock.\nThe softirq_ctrl.lock can not be made part of spin_lock_irq() as this\nwould lead to too much synchronisation against individual threads on the\nsystem. To avoid the possible deadlock, softirqs must be manually\ndisabled before the lock is acquired.\nDisable softirqs before the lock is acquired on PREEMPT_RT.

In the Linux kernel, the following vulnerability has been resolved:\nBluetooth: ISO: Fix possible UAF on iso_conn_free\nThis attempt to fix similar issue to sco_conn_free where if the\nconn->sk is not set to NULL may lead to UAF on iso_conn_free.

In the Linux kernel, the following vulnerability has been resolved:\nnet: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\nsyzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb.\nThis is the sequence of events that leads to the warning:\nrtl8150_start_xmit() {\nnetif_stop_queue();\nusb_submit_urb(dev->tx_urb);\n}\nrtl8150_set_multicast() {\nnetif_stop_queue();\nnetif_wake_queue();<-- wakes up TX queue before URB is done\n}\nrtl8150_start_xmit() {\nnetif_stop_queue();\nusb_submit_urb(dev->tx_urb);<-- double submission\n}\nrtl8150_set_multicast being the ndo_set_rx_mode callback should not be\ncalling netif_stop_queue and notif_start_queue as these handle\nTX queue synchronization.\nThe net core function dev_set_rx_mode handles the synchronization\nfor rtl8150_set_multicast making it safe to remove these locks.

In the Linux kernel, the following vulnerability has been resolved:\nf2fs: fix to avoid NULL pointer dereference in f2fs_check_quota_consistency()\nsyzbot reported a f2fs bug as below:\nOops: gen[ 107.736417][ T5848] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 UID: 0 PID: 5848 Comm: syz-executor263 Tainted: G W 6.17.0-rc1-syzkaller-00014-g0e39a731820a #0 PREEMPT_{RT,(full)}\nRIP: 0010:strcmp+0x3c/0xc0 lib/string.c:284\nCall Trace:\n\nf2fs_check_quota_consistency fs/f2fs/super.c:1188 [inline]\nf2fs_check_opt_consistency+0x1378/0x2c10 fs/f2fs/super.c:1436\n__f2fs_remount fs/f2fs/super.c:2653 [inline]\nf2fs_reconfigure+0x482/0x1770 fs/f2fs/super.c:5297\nreconfigure_super+0x224/0x890 fs/super.c:1077\ndo_remount fs/namespace.c:3314 [inline]\npath_mount+0xd18/0xfe0 fs/namespace.c:4112\ndo_mount fs/namespace.c:4133 [inline]\n__do_sys_mount fs/namespace.c:4344 [inline]\n__se_sys_mount+0x317/0x410 fs/namespace.c:4321\ndo_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\ndo_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\nentry_SYSCALL_64_after_hwframe+0x77/0x7f\nThe direct reason is f2fs_check_quota_consistency() may suffer null-ptr-deref\nissue in strcmp().\nThe bug can be reproduced w/ below scripts:\nmkfs.f2fs -f /dev/vdb\nmount -t f2fs -o usrquota /dev/vdb /mnt/f2fs\nquotacheck -uc /mnt/f2fs/\numount /mnt/f2fs\nmount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs\nmount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs\numount /mnt/f2fs\nSo, before old_qname and new_qname comparison, we need to check whether\nthey are all valid pointers, fix it.

In the Linux kernel, the following vulnerability has been resolved:\ncrypto: hisilicon/qm - request reserved interrupt for virtual function\nThe device interrupt vector 3 is an error interrupt for\nphysical function and a reserved interrupt for virtual function.\nHowever, the driver has not registered the reserved interrupt for\nvirtual function. When allocating interrupts, the number of interrupts\nis allocated based on powers of two, which includes this interrupt.\nWhen the system enables GICv4 and the virtual function passthrough\nto the virtual machine, releasing the interrupt in the driver\ntriggers a warning.\nThe WARNING report is:\nWARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4\nTherefore, register a reserved interrupt for VF and set the\nIRQF_NO_AUTOEN flag to avoid that warning.

In the Linux kernel, the following vulnerability has been resolved:\nipv6: use RCU in ip6_xmit()\nUse RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent\npossible UAF.

In the Linux kernel, the following vulnerability has been resolved:\nmptcp: Use __sk_dst_get() and dst_dev_rcu() in mptcp_active_enable().\nmptcp_active_enable() is called from subflow_finish_connect(),\nwhich is icsk->icsk_af_ops->sk_rx_dst_set() and it's not always\nunder RCU.\nUsing sk_dst_get(sk)->dev could trigger UAF.\nLet's use __sk_dst_get() and dst_dev_rcu().

In the Linux kernel, the following vulnerability has been resolved:\nASoC: Intel: sof_sdw: Prevent jump to NULL add_sidecar callback\nIn create_sdw_dailink() check that sof_end->codec_info->add_sidecar\nis not NULL before calling it.\nThe original code assumed that if include_sidecar is true, the codec\non that link has an add_sidecar callback. But there could be other\ncodecs on the same link that do not have an add_sidecar callback.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: ath12k: Fix peer lookup in ath12k_dp_mon_rx_deliver_msdu()\nIn ath12k_dp_mon_rx_deliver_msdu(), peer lookup fails because\nrxcb->peer_id is not updated with a valid value. This is expected\nin monitor mode, where RX frames bypass the regular RX\ndescriptor path that typically sets rxcb->peer_id.\nAs a result, the peer is NULL, and link_id and link_valid fields\nin the RX status are not populated. This leads to a WARN_ON in\nmac80211 when it receives data frame from an associated station\nwith invalid link_id.\nFix this potential issue by using ppduinfo->peer_id, which holds\nthe correct peer id for the received frame. This ensures that the\npeer is correctly found and the associated link metadata is updated\naccordingly.\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\nscsi: ufs: core: Fix data race in CPU latency PM QoS request handling\nThe cpu_latency_qos_add/remove/update_request interfaces lack internal\nsynchronization by design, requiring the caller to ensure thread safety.\nThe current implementation relies on the 'pm_qos_enabled' flag, which is\ninsufficient to prevent concurrent access and cannot serve as a proper\nsynchronization mechanism. This has led to data races and list\ncorruption issues.\nA typical race condition call trace is:\n[Thread A]\nufshcd_pm_qos_exit()\n--> cpu_latency_qos_remove_request()\n--> cpu_latency_qos_apply();\n--> pm_qos_update_target()\n--> plist_del <--(1) delete plist node\n--> memset(req, 0, sizeof(*req));\n--> hba->pm_qos_enabled = false;\n[Thread B]\nufshcd_devfreq_target\n--> ufshcd_devfreq_scale\n--> ufshcd_scale_clks\n--> ufshcd_pm_qos_update <--(2) pm_qos_enabled is true\n--> cpu_latency_qos_update_request\n--> pm_qos_update_target\n--> plist_del <--(3) plist node use-after-free\nIntroduces a dedicated mutex to serialize PM QoS operations, preventing\ndata races and ensuring safe access to PM QoS resources, including sysfs\ninterface reads.

In the Linux kernel, the following vulnerability has been resolved:\nsparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC\nThe referenced commit introduced exception handlers on user-space memory\nreferences in copy_from_user and copy_to_user. These handlers return from\nthe respective function and calculate the remaining bytes left to copy\nusing the current register contents. This commit fixes a couple of bad\ncalculations. This will fix the return value of copy_from_user and\ncopy_to_user in the faulting case. The behaviour of memcpy stays unchanged.

In the Linux kernel, the following vulnerability has been resolved:\n\nsparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III\n\nAnthony Yznaga tracked down that a BUG_ON in ext4 code with large folios\nenabled resulted from copy_from_user() returning impossibly large values\ngreater than the size to be copied. This lead to __copy_from_iter()\nreturning impossible values instead of the actual number of bytes it was\nable to copy.\n\nThe BUG_ON has been reported in\nhttps://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.de\n\nThe referenced commit introduced exception handlers on user-space memory\nreferences in copy_from_user and copy_to_user. These handlers return from\nthe respective function and calculate the remaining bytes left to copy\nusing the current register contents. The exception handlers expect that\n%o2 has already been masked during the bulk copy loop, but the masking was\nperformed after that loop. This will fix the return value of copy_from_user\nand copy_to_user in the faulting case. The behaviour of memcpy stays\nunchanged.

In the Linux kernel, the following vulnerability has been resolved:\nperf/x86/intel: Fix IA32_PMC_x_CFG_B MSRs access error\nWhen running perf_fuzzer on PTL, sometimes the below "unchecked MSR\naccess error" is seen when accessing IA32_PMC_x_CFG_B MSRs.\n[ 55.611268] unchecked MSR access error: WRMSR to 0x1986 (tried to write 0x0000000200000001) at rIP: 0xffffffffac564b28 (native_write_msr+0x8/0x30)\n[ 55.611280] Call Trace:\n[ 55.611282] \n[ 55.611284] ? intel_pmu_config_acr+0x87/0x160\n[ 55.611289] intel_pmu_enable_acr+0x6d/0x80\n[ 55.611291] intel_pmu_enable_event+0xce/0x460\n[ 55.611293] x86_pmu_start+0x78/0xb0\n[ 55.611297] x86_pmu_enable+0x218/0x3a0\n[ 55.611300] ? x86_pmu_enable+0x121/0x3a0\n[ 55.611302] perf_pmu_enable+0x40/0x50\n[ 55.611307] ctx_resched+0x19d/0x220\n[ 55.611309] __perf_install_in_context+0x284/0x2f0\n[ 55.611311] ? __pfx_remote_function+0x10/0x10\n[ 55.611314] remote_function+0x52/0x70\n[ 55.611317] ? __pfx_remote_function+0x10/0x10\n[ 55.611319] generic_exec_single+0x84/0x150\n[ 55.611323] smp_call_function_single+0xc5/0x1a0\n[ 55.611326] ? __pfx_remote_function+0x10/0x10\n[ 55.611329] perf_install_in_context+0xd1/0x1e0\n[ 55.611331] ? __pfx___perf_install_in_context+0x10/0x10\n[ 55.611333] __do_sys_perf_event_open+0xa76/0x1040\n[ 55.611336] __x64_sys_perf_event_open+0x26/0x30\n[ 55.611337] x64_sys_call+0x1d8e/0x20c0\n[ 55.611339] do_syscall_64+0x4f/0x120\n[ 55.611343] entry_SYSCALL_64_after_hwframe+0x76/0x7e\nOn PTL, GP counter 0 and 1 doesn't support auto counter reload feature,\nthus it would trigger a #GP when trying to write 1 on bit 0 of CFG_B MSR\nwhich requires to enable auto counter reload on GP counter 0.\nThe root cause of causing this issue is the check for auto counter\nreload (ACR) counter mask from user space is incorrect in\nintel_pmu_acr_late_setup() helper. It leads to an invalid ACR counter\nmask from user space could be set into hw.config1 and then written into\nCFG_B MSRs and trigger the MSR access warning.\ne.g., User may create a perf event with ACR counter mask (config2=0xcb),\nand there is only 1 event created, so "cpuc->n_events" is 1.\nThe correct check condition should be "i + idx >= cpuc->n_events"\ninstead of "i + idx > cpuc->n_events" (it looks a typo). Otherwise,\nthe counter mask would traverse twice and an invalid "cpuc->assign[1]"\nbit (bit 0) is set into hw.config1 and cause MSR accessing error.\nBesides, also check if the ACR counter mask corresponding events are\nACR events. If not, filter out these counter mask. If a event is not a\nACR event, it could be scheduled to an HW counter which doesn't support\nACR. It's invalid to add their counter index in ACR counter mask.\nFurthermore, remove the WARN_ON_ONCE() since it's easily triggered as\nuser could set any invalid ACR counter mask and the warning message\ncould mislead users.

In the Linux kernel, the following vulnerability has been resolved:\nASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping\nWhen an invalid value is passed via quirk option, currently\nbytcr_rt5640 driver just ignores and leaves as is, which may lead to\nunepxected results like OOB access.\nThis patch adds the sanity check and corrects the input mapping to the\ncertain default value if an invalid value is passed.

In the Linux kernel, the following vulnerability has been resolved:\nscsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod\nSince commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when\ndevice is gone") UBSAN reports:\nUBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17\nindex 28 is out of range for type 'pm8001_phy [16]'\non rmmod when using an expander.\nFor a direct attached device, attached_phy contains the local phy id.\nFor a device behind an expander, attached_phy contains the remote phy\nid, not the local phy id.\nI.e. while pm8001_ha will have pm8001_ha->chip->n_phy local phys, for a\ndevice behind an expander, attached_phy can be much larger than\npm8001_ha->chip->n_phy (depending on the amount of phys of the\nexpander).\nE.g. on my system pm8001_ha has 8 phys with phy ids 0-7. One of the\nports has an expander connected. The expander has 31 phys with phy ids\n0-30.\nThe pm8001_ha->phy array only contains the phys of the HBA. It does not\ncontain the phys of the expander. Thus, it is wrong to use attached_phy\nto index the pm8001_ha->phy array for a device behind an expander.\nThus, we can only clear phy_attached for devices that are directly\nattached.

In the Linux kernel, the following vulnerability has been resolved:\nmisc: pci_endpoint_test: Fix array underflow in pci_endpoint_test_ioctl()\nCommit eefb83790a0d ("misc: pci_endpoint_test: Add doorbell test case")\nadded NO_BAR (-1) to the pci_barno enum which, in practical terms,\nchanges the enum from an unsigned int to a signed int. If the user\npasses a negative number in pci_endpoint_test_ioctl() then it results in\nan array underflow in pci_endpoint_test_bar().

In the Linux kernel, the following vulnerability has been resolved:\nremoteproc: qcom: pas: Shutdown lite ADSP DTB on X1E\nThe ADSP firmware on X1E has separate firmware binaries for the main\nfirmware and the DTB. The same applies for the "lite" firmware loaded by\nthe boot firmware.\nWhen preparing to load the new ADSP firmware we shutdown the lite_pas_id\nfor the main firmware, but we don't shutdown the corresponding lite pas_id\nfor the DTB. The fact that we're leaving it "running" forever becomes\nobvious if you try to reuse (or just access) the memory region used by the\n"lite" firmware: The &adsp_boot_mem is accessible, but accessing the\n&adsp_boot_dtb_mem results in a crash.\nWe don't support reusing the memory regions currently, but nevertheless we\nshould not keep part of the lite firmware running. Fix this by adding the\nlite_dtb_pas_id and shutting it down as well.\nWe don't have a way to detect if the lite firmware is actually running yet,\nso ignore the return status of qcom_scm_pas_shutdown() for now. This was\nalready the case before, the assignment to "ret" is not used anywhere.

In the Linux kernel, the following vulnerability has been resolved:\n\nsparc: fix accurate exception reporting in copy_{from_to}_user for Niagara\n\nThe referenced commit introduced exception handlers on user-space memory\nreferences in copy_from_user and copy_to_user. These handlers return from\nthe respective function and calculate the remaining bytes left to copy\nusing the current register contents. This commit fixes a couple of bad\ncalculations and a broken epilogue in the exception handlers. This will\nprevent crashes and ensure correct return values of copy_from_user and\ncopy_to_user in the faulting case. The behaviour of memcpy stays unchanged.

Integer wraparound in multiple PostgreSQL libpq client library functions allows an application input provider or network peer to cause libpq to undersize an allocation and write out-of-bounds by hundreds of megabytes. This results in a segmentation fault for the application using libpq. Versions before PostgreSQL 18.1, 17.7, 16.11, 15.15, 14.20, and 13.23 are affected.

A flaw was discovered in libvirt in the XML file processing. More specifically, the parsing of user provided XML files was performed before the ACL checks. A malicious user with limited permissions could exploit this flaw by submitting a specially crafted XML file, causing libvirt to allocate too much memory on the host. The excessive memory consumption could lead to a libvirt process crash on the host, resulting in a denial-of-service condition.

Ceph is a distributed object, block, and file storage platform. In versions up to and including 19.2.3, using the argument `x-amz-copy-source` to put an object and specifying an empty string as its content leads to the RGW daemon crashing, resulting in a DoS attack. As of time of publication, no known patched versions exist.

JIT miscompilation in the JavaScript Engine: JIT component. This vulnerability affects Firefox < 145.

Use-after-free in the WebRTC: Audio/Video component. This vulnerability affects Firefox < 145 and Firefox ESR < 140.5.

Same-origin policy bypass in the DOM: Workers component. This vulnerability affects Firefox < 145 and Firefox ESR < 140.5.

Mitigation bypass in the DOM: Security component. This vulnerability affects Firefox < 145 and Firefox ESR < 140.5.

Same-origin policy bypass in the DOM: Notifications component. This vulnerability affects Firefox < 145 and Firefox ESR < 140.5.

Incorrect boundary conditions in the JavaScript: WebAssembly component. This vulnerability affects Firefox < 145 and Firefox ESR < 140.5.

Spoofing issue in Firefox. This vulnerability affects Firefox < 145, Firefox ESR < 140.5, and Firefox ESR < 115.30.

Use-after-free in the Audio/Video component. This vulnerability affects Firefox < 145, Firefox ESR < 140.5, and Firefox ESR < 115.30.

Mitigation bypass in the DOM: Core & HTML component. This vulnerability affects Firefox < 145, Firefox ESR < 140.5, and Firefox ESR < 115.30.

Race condition in the Graphics component. This vulnerability affects Firefox < 145, Firefox ESR < 140.5, and Firefox ESR < 115.30.

Starlette is a lightweight ASGI framework/toolkit. Prior to 0.49.1 , an unauthenticated attacker can send a crafted HTTP Range header that triggers quadratic-time processing in Starlette's FileResponse Range parsing/merging logic. This enables CPU exhaustion per request, causing denial‑of‑service for endpoints serving files (e.g., StaticFiles or any use of FileResponse). This vulnerability is fixed in 0.49.1.

cJSON 1.5.0 through 1.7.18 allows out-of-bounds access via the decode_array_index_from_pointer function in cJSON_Utils.c, allowing remote attackers to bypass array bounds checking and access restricted data via malformed JSON pointer strings containing alphanumeric characters.