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:\n\nnet: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM\n\nWhen performing Generic Segmentation Offload (GSO) on an IPv6 packet that\ncontains extension headers, the kernel incorrectly requests checksum offload\nif the egress device only advertises NETIF_F_IPV6_CSUM feature, which has\na strict contract: it supports checksum offload only for plain TCP or UDP\nover IPv6 and explicitly does not support packets with extension headers.\nThe current GSO logic violates this contract by failing to disable the feature\nfor packets with extension headers, such as those used in GREoIPv6 tunnels.\n\nThis violation results in the device being asked to perform an operation\nit cannot support, leading to a `skb_warn_bad_offload` warning and a collapse\nof network throughput. While device TSO/USO is correctly bypassed in favor\nof software GSO for these packets, the GSO stack must be explicitly told not\nto request checksum offload.\n\nMask NETIF_F_IPV6_CSUM, NETIF_F_TSO6 and NETIF_F_GSO_UDP_L4\nin gso_features_check if the IPv6 header contains extension headers to compute\nchecksum in software.\n\nThe exception is a BIG TCP extension, which, as stated in commit\n68e068cabd2c6c53 ("net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets"):\n"The feature is only enabled on devices that support BIG TCP TSO.\nThe header is only present for PF_PACKET taps like tcpdump,\nand not transmitted by physical devices."\n\nkernel log output (truncated):\nWARNING: CPU: 1 PID: 5273 at net/core/dev.c:3535 skb_warn_bad_offload+0x81/0x140\n...\nCall Trace:\n \n skb_checksum_help+0x12a/0x1f0\n validate_xmit_skb+0x1a3/0x2d0\n validate_xmit_skb_list+0x4f/0x80\n sch_direct_xmit+0x1a2/0x380\n __dev_xmit_skb+0x242/0x670\n __dev_queue_xmit+0x3fc/0x7f0\n ip6_finish_output2+0x25e/0x5d0\n ip6_finish_output+0x1fc/0x3f0\n ip6_tnl_xmit+0x608/0xc00 [ip6_tunnel]\n ip6gre_tunnel_xmit+0x1c0/0x390 [ip6_gre]\n dev_hard_start_xmit+0x63/0x1c0\n __dev_queue_xmit+0x6d0/0x7f0\n ip6_finish_output2+0x214/0x5d0\n ip6_finish_output+0x1fc/0x3f0\n ip6_xmit+0x2ca/0x6f0\n ip6_finish_output+0x1fc/0x3f0\n ip6_xmit+0x2ca/0x6f0\n inet6_csk_xmit+0xeb/0x150\n __tcp_transmit_skb+0x555/0xa80\n tcp_write_xmit+0x32a/0xe90\n tcp_sendmsg_locked+0x437/0x1110\n tcp_sendmsg+0x2f/0x50\n...\nskb linear: 00000000: e4 3d 1a 7d ec 30 e4 3d 1a 7e 5d 90 86 dd 60 0e\nskb linear: 00000010: 00 0a 1b 34 3c 40 20 11 00 00 00 00 00 00 00 00\nskb linear: 00000020: 00 00 00 00 00 12 20 11 00 00 00 00 00 00 00 00\nskb linear: 00000030: 00 00 00 00 00 11 2f 00 04 01 04 01 01 00 00 00\nskb linear: 00000040: 86 dd 60 0e 00 0a 1b 00 06 40 20 23 00 00 00 00\nskb linear: 00000050: 00 00 00 00 00 00 00 00 00 12 20 23 00 00 00 00\nskb linear: 00000060: 00 00 00 00 00 00 00 00 00 11 bf 96 14 51 13 f9\nskb linear: 00000070: ae 27 a0 a8 2b e3 80 18 00 40 5b 6f 00 00 01 01\nskb linear: 00000080: 08 0a 42 d4 50 d5 4b 70 f8 1a

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.

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:\n\nrcutorture: Fix rcutorture_one_extend_check() splat in RT kernels\n\nFor built with CONFIG_PREEMPT_RT=y kernels, running rcutorture\ntests resulted in the following splat:\n\n[ 68.797425] rcutorture_one_extend_check during change: Current 0x1 To add 0x1 To remove 0x0 preempt_count() 0x0\n[ 68.797533] WARNING: CPU: 2 PID: 512 at kernel/rcu/rcutorture.c:1993 rcutorture_one_extend_check+0x419/0x560 [rcutorture]\n[ 68.797601] Call Trace:\n[ 68.797602] \n[ 68.797619] ? lockdep_softirqs_off+0xa5/0x160\n[ 68.797631] rcutorture_one_extend+0x18e/0xcc0 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[ 68.797646] ? local_clock+0x19/0x40\n[ 68.797659] rcu_torture_one_read+0xf0/0x280 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[ 68.797678] ? __pfx_rcu_torture_one_read+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[ 68.797804] ? __pfx_rcu_torture_timer+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[ 68.797815] rcu-torture: rcu_torture_reader task started\n[ 68.797824] rcu-torture: Creating rcu_torture_reader task\n[ 68.797824] rcu_torture_reader+0x238/0x580 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[ 68.797836] ? kvm_sched_clock_read+0x15/0x30\n\nDisable BH does not change the SOFTIRQ corresponding bits in\npreempt_count() for RT kernels, this commit therefore use\nsoftirq_count() to check the if BH is disabled.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

A heap-buffer-overflow write exists in jpeg2000dec FFmpeg which allows an attacker to potentially gain remote code execution or cause denial of service via the channel definition cdef atom of JPEG2000.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "fs/ntfs3: Replace inode_trylock with inode_lock"\n\nThis reverts commit 69505fe98f198ee813898cbcaf6770949636430b.\n\nInitially, conditional lock acquisition was removed to fix an xfstest bug\nthat was observed during internal testing. The deadlock reported by syzbot\nis resolved by reintroducing conditional acquisition. The xfstest bug no\nlonger occurs on kernel version 6.16-rc1 during internal testing. I\nassume that changes in other modules may have contributed to this.

In the Linux kernel, the following vulnerability has been resolved:\n\nteam: replace team lock with rtnl lock\n\nsyszbot reports various ordering issues for lower instance locks and\nteam lock. Switch to using rtnl lock for protecting team device,\nsimilar to bonding. Based on the patch by Tetsuo Handa.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Fix dereferencing uninitialized error pointer\n\nFix below smatch warnings:\ndrivers/crypto/ccp/sev-dev.c:1312 __sev_platform_init_locked()\nerror: we previously assumed 'error' could be null

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: fix potential buffer overflow in setup_clusters()\n\nIn setup_swap_map(), we only ensure badpages are in range (0, last_page]. \nAs maxpages might be < last_page, setup_clusters() will encounter a buffer\noverflow when a badpage is >= maxpages.\n\nOnly call inc_cluster_info_page() for badpage which is < maxpages to fix\nthe issue.

No description is available for this CVE.

A flaw was found in the Udisks daemon, where it allows unprivileged users to create loop devices using the D-BUS system. This is achieved via the loop device handler, which handles requests sent through the D-BUS interface. As two of the parameters of this handle, it receives the file descriptor list and index specifying the file where the loop device should be backed. The function itself validates the index value to ensure it isn't bigger than the maximum value allowed. However, it fails to validate the lower bound, allowing the index parameter to be a negative value. Under these circumstances, an attacker can cause the UDisks daemon to crash or perform a local privilege escalation by gaining access to files owned by privileged users.

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:\n\nnet: hibmcge: fix the division by zero issue\n\nWhen the network port is down, the queue is released, and ring->len is 0.\nIn debugfs, hbg_get_queue_used_num() will be called,\nwhich may lead to a division by zero issue.\n\nThis patch adds a check, if ring->len is 0,\nhbg_get_queue_used_num() directly returns 0.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Make dma-fences compliant with the safe access rules\n\nXe can free some of the data pointed to by the dma-fences it exports. Most\nnotably the timeline name can get freed if userspace closes the associated\nsubmit queue. At the same time the fence could have been exported to a\nthird party (for example a sync_fence fd) which will then cause an use-\nafter-free on subsequent access.\n\nTo make this safe we need to make the driver compliant with the newly\ndocumented dma-fence rules. Driver has to ensure a RCU grace period\nbetween signalling a fence and freeing any data pointed to by said fence.\n\nFor the timeline name we simply make the queue be freed via kfree_rcu and\nfor the shared lock associated with multiple queues we add a RCU grace\nperiod before freeing the per GT structure holding the lock.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Don't crash in stack_top() for tasks without ABI or vDSO\n\nNot all tasks have an ABI associated or vDSO mapped,\nfor example kthreads never do.\nIf such a task ever ends up calling stack_top(), it will derefence the\nNULL ABI pointer and crash.\n\nThis can for example happen when using kunit:\n\n mips_stack_top+0x28/0xc0\n arch_pick_mmap_layout+0x190/0x220\n kunit_vm_mmap_init+0xf8/0x138\n __kunit_add_resource+0x40/0xa8\n kunit_vm_mmap+0x88/0xd8\n usercopy_test_init+0xb8/0x240\n kunit_try_run_case+0x5c/0x1a8\n kunit_generic_run_threadfn_adapter+0x28/0x50\n kthread+0x118/0x240\n ret_from_kernel_thread+0x14/0x1c\n\nOnly dereference the ABI point if it is set.\n\nThe GIC page is also included as it is specific to the vDSO.\nAlso move the randomization adjustment into the same conditional.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/migrate: prevent infinite recursion\n\nIf the buf + offset is not aligned to XE_CAHELINE_BYTES we fallback to\nusing a bounce buffer. However the bounce buffer here is allocated on\nthe stack, and the only alignment requirement here is that it's\nnaturally aligned to u8, and not XE_CACHELINE_BYTES. If the bounce\nbuffer is also misaligned we then recurse back into the function again,\nhowever the new bounce buffer might also not be aligned, and might never\nbe until we eventually blow through the stack, as we keep recursing.\n\nInstead of using the stack use kmalloc, which should respect the\npower-of-two alignment request here. Fixes a kernel panic when\ntriggering this path through eudebug.\n\nv2 (Stuart):\n - Add build bug check for power-of-two restriction\n - s/EINVAL/ENOMEM/\n\n(cherry picked from commit 38b34e928a08ba594c4bbf7118aa3aadacd62fff)

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nuserfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entry\n\nWhen UFFDIO_MOVE encounters a migration PMD entry, it proceeds with\nobtaining a folio and accessing it even though the entry is swp_entry_t. \nAdd the missing check and let split_huge_pmd() handle migration entries. \nWhile at it also remove unnecessary folio check.\n\n[surenb@google.com: remove extra folio check, per David]

In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix vmalloc out-of-bounds write in fast_imageblit\n\nThis issue triggers when a userspace program does an ioctl\nFBIOPUT_CON2FBMAP by passing console number and frame buffer number.\nIdeally this maps console to frame buffer and updates the screen if\nconsole is visible.\n\nAs part of mapping it has to do resize of console according to frame\nbuffer info. if this resize fails and returns from vc_do_resize() and\ncontinues further. At this point console and new frame buffer are mapped\nand sets display vars. Despite failure still it continue to proceed\nupdating the screen at later stages where vc_data is related to previous\nframe buffer and frame buffer info and display vars are mapped to new\nframe buffer and eventully leading to out-of-bounds write in\nfast_imageblit(). This bheviour is excepted only when fg_console is\nequal to requested console which is a visible console and updates screen\nwith invalid struct references in fbcon_putcs().

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()\n\nThe buffer length check before calling uvc_parse_format() only ensured\nthat the buffer has at least 3 bytes (buflen > 2), buf the function\naccesses buffer[3], requiring at least 4 bytes.\n\nThis can lead to an out-of-bounds read if the buffer has exactly 3 bytes.\n\nFix it by checking that the buffer has at least 4 bytes in\nuvc_parse_format().

No description is available for this CVE.

A vulnerability was found in GNU Binutils 2.44 and classified as problematic. This issue affects the function process_debug_info of the file binutils/dwarf.c of the component DWARF Section Handler. The manipulation leads to memory leak. Attacking locally is a requirement. The identifier of the patch is e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4. It is recommended to apply a patch to fix this issue.

Memory safety bugs present in Firefox 140 and Thunderbird 140. 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 < 141 and Thunderbird < 141.

Setting a nameless cookie with an equals sign in the value shadowed other cookies. Even if the nameless cookie was set over HTTP and the shadowed cookie included the `Secure` attribute. This vulnerability affects Firefox < 141, Firefox ESR < 140.1, Thunderbird < 141, and Thunderbird < 140.1.

Thunderbird cached CORS preflight responses across IP address changes. This allowed circumventing CORS with DNS rebinding. This vulnerability affects Firefox < 141, Firefox ESR < 140.1, Thunderbird < 141, and Thunderbird < 140.1.

OpenJPEG is an open-source JPEG 2000 codec. In OpenJPEG from 2.5.1 through 2.5.3, a call to opj_jp2_read_header may lead to OOB heap memory write when the data stream p_stream is too short and p_image is not initialized.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start()\nPreserve the error code if iwl_setup_deferred_work() fails. The current\ncode returns ERR_PTR(0) (which is NULL) on this path. I believe the\nmissing error code potentially leads to a use after free involving\ndebugfs.

Memory safety bugs present in Firefox 141 and Thunderbird 141. 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 < 142 and Thunderbird < 142.

Memory safety bugs present in Firefox ESR 115.26, Firefox ESR 128.13, Thunderbird ESR 128.13, Firefox ESR 140.1, Thunderbird ESR 140.1, Firefox 141 and Thunderbird 141. 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 < 142, Firefox ESR < 115.27, Firefox ESR < 128.14, Firefox ESR < 140.2, Thunderbird < 142, Thunderbird < 128.14, and Thunderbird < 140.2.

Memory safety bugs present in Firefox ESR 140.1, Thunderbird ESR 140.1, Firefox 141 and Thunderbird 141. 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 < 142, Firefox ESR < 140.2, Thunderbird < 142, and Thunderbird < 140.2.

Spoofing issue in the Address Bar component. This vulnerability affects Firefox < 142 and Firefox ESR < 140.2.

'Denial-of-service due to out-of-memory in the Graphics: WebRender component.' This vulnerability affects Firefox < 142, Firefox ESR < 140.2, Thunderbird < 142, and Thunderbird < 140.2.

Uninitialized memory in the JavaScript Engine component. This vulnerability affects Firefox < 142, Firefox ESR < 128.14, Firefox ESR < 140.2, Thunderbird < 142, Thunderbird < 128.14, and Thunderbird < 140.2.

'Same-origin policy bypass in the Graphics: Canvas2D component.' This vulnerability affects Firefox < 142, Firefox ESR < 115.27, Firefox ESR < 128.14, Firefox ESR < 140.2, Thunderbird < 142, Thunderbird < 128.14, and Thunderbird < 140.2.

An attacker was able to perform memory corruption in the GMP process which processes encrypted media. This process is also heavily sandboxed, but represents slightly different privileges from the content process. This vulnerability affects Firefox < 142, Firefox ESR < 115.27, Firefox ESR < 128.14, Firefox ESR < 140.2, Thunderbird < 142, Thunderbird < 128.14, and Thunderbird < 140.2.

In Eclipse Jetty, versions <=9.4.57, <=10.0.25, <=11.0.25, <=12.0.21, <=12.1.0.alpha2, an HTTP/2 client may trigger the server to send RST_STREAM frames, for example by sending frames that are malformed or that should not be sent in a particular stream state, therefore forcing the server to consume resources such as CPU and memory.\n\n\nFor example, a client can open a stream and then send WINDOW_UPDATE frames with window size increment of 0, which is illegal.\nPer specification https://www.rfc-editor.org/rfc/rfc9113.html#name-window_update , the server should send a RST_STREAM frame.\nThe client can now open another stream and send another bad WINDOW_UPDATE, therefore causing the server to consume more resources than necessary, as this case does not exceed the max number of concurrent streams, yet the client is able to create an enormous amount of streams in a short period of time.\n\n\nThe attack can be performed with other conditions (for example, a DATA frame for a closed stream) that cause the server to send a RST_STREAM frame.\n\n\n\nLinks:\n\n\n\n * https://github.com/jetty/jetty.project/security/advisories/GHSA-mmxm-8w33-wc4h

In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: state: initialize state_ptrs earlier in xfrm_state_find\n\nIn case of preemption, xfrm_state_look_at will find a different\npcpu_id and look up states for that other CPU. If we matched a state\nfor CPU2 in the state_cache while the lookup started on CPU1, we will\njump to "found", but the "best" state that we got will be ignored and\nwe will enter the "acquire" block. This block uses state_ptrs, which\nisn't initialized at this point.\n\nLet's initialize state_ptrs just after taking rcu_read_lock. This will\nalso prevent a possible misuse in the future, if someone adjusts this\nfunction.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "drm/prime: Use dma_buf from GEM object instance"\n\nThis reverts commit f83a9b8c7fd0557b0c50784bfdc1bbe9140c9bf8.\n\nThe dma_buf field in struct drm_gem_object is not stable over the\nobject instance's lifetime. The field becomes NULL when user space\nreleases the final GEM handle on the buffer object. This resulted\nin a NULL-pointer deref.\n\nWorkarounds in commit 5307dce878d4 ("drm/gem: Acquire references on\nGEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer:\nAcquire internal references on GEM handles") only solved the problem\npartially. They especially don't work for buffer objects without a DRM\nframebuffer associated.\n\nHence, this revert to going back to using .import_attach->dmabuf.\n\nv3:\n- cc stable

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "drm/gem-framebuffer: Use dma_buf from GEM object instance"\n\nThis reverts commit cce16fcd7446dcff7480cd9d2b6417075ed81065.\n\nThe dma_buf field in struct drm_gem_object is not stable over the\nobject instance's lifetime. The field becomes NULL when user space\nreleases the final GEM handle on the buffer object. This resulted\nin a NULL-pointer deref.\n\nWorkarounds in commit 5307dce878d4 ("drm/gem: Acquire references on\nGEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer:\nAcquire internal references on GEM handles") only solved the problem\npartially. They especially don't work for buffer objects without a DRM\nframebuffer associated.\n\nHence, this revert to going back to using .import_attach->dmabuf.\n\nv3:\n- cc stable

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "drm/gem-dma: Use dma_buf from GEM object instance"\n\nThis reverts commit e8afa1557f4f963c9a511bd2c6074a941c308685.\n\nThe dma_buf field in struct drm_gem_object is not stable over the\nobject instance's lifetime. The field becomes NULL when user space\nreleases the final GEM handle on the buffer object. This resulted\nin a NULL-pointer deref.\n\nWorkarounds in commit 5307dce878d4 ("drm/gem: Acquire references on\nGEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer:\nAcquire internal references on GEM handles") only solved the problem\npartially. They especially don't work for buffer objects without a DRM\nframebuffer associated.\n\nHence, this revert to going back to using .import_attach->dmabuf.\n\nv3:\n- cc stable

In the Linux kernel, the following vulnerability has been resolved:\n\narm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()\n\n`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change\nto different stacks along with the Shadow Call Stack if it is enabled.\nThose two stack changes cannot be done atomically and both functions\ncan be interrupted by SErrors or Debug Exceptions which, though unlikely,\nis very much broken : if interrupted, we can end up with mismatched stacks\nand Shadow Call Stack leading to clobbered stacks.\n\nIn `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,\nbut x18 stills points to the old task's SCS. When the interrupt handler\ntries to save the task's SCS pointer, it will save the old task\nSCS pointer (x18) into the new task struct (pointed to by SP_EL0),\nclobbering it.\n\nIn `call_on_irq_stack()`, it can happen when switching from the task stack\nto the IRQ stack and when switching back. In both cases, we can be\ninterrupted when the SCS pointer points to the IRQ SCS, but SP points to\nthe task stack. The nested interrupt handler pushes its return addresses\non the IRQ SCS. It then detects that SP points to the task stack,\ncalls `call_on_irq_stack()` and clobbers the task SCS pointer with\nthe IRQ SCS pointer, which it will also use !\n\nThis leads to tasks returning to addresses on the wrong SCS,\nor even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK\nor FPAC if enabled.\n\nThis is possible on a default config, but unlikely.\nHowever, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and\ninstead the GIC is responsible for filtering what interrupts the CPU\nshould receive based on priority.\nGiven the goal of emulating NMIs, pseudo-NMIs can be received by the CPU\neven in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*\nfrequently depending on the system configuration and workload, leading\nto unpredictable kernel panics.\n\nCompletely mask DAIF in `cpu_switch_to()` and restore it when returning.\nDo the same in `call_on_irq_stack()`, but restore and mask around\nthe branch.\nMask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency\nof behaviour between all configurations.\n\nIntroduce and use an assembly macro for saving and masking DAIF,\nas the existing one saves but only masks IF.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "drm/gem-shmem: Use dma_buf from GEM object instance"\n\nThis reverts commit 1a148af06000e545e714fe3210af3d77ff903c11.\n\nThe dma_buf field in struct drm_gem_object is not stable over the\nobject instance's lifetime. The field becomes NULL when user space\nreleases the final GEM handle on the buffer object. This resulted\nin a NULL-pointer deref.\n\nWorkarounds in commit 5307dce878d4 ("drm/gem: Acquire references on\nGEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer:\nAcquire internal references on GEM handles") only solved the problem\npartially. They especially don't work for buffer objects without a DRM\nframebuffer associated.\n\nHence, this revert to going back to using .import_attach->dmabuf.\n\nv3:\n- cc stable

In the Linux kernel, the following vulnerability has been resolved:\n\niio: fix potential out-of-bound write\n\nThe buffer is set to 20 characters. If a caller write more characters,\ncount is truncated to the max available space in "simple_write_to_buffer".\nTo protect from OoB access, check that the input size fit into buffer and\nadd a zero terminator after copy to the end of the copied data.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365_dai_set_priv\n\nGiven mt8365_dai_set_priv allocate priv_size space to copy priv_data which\nmeans we should pass mt8365_i2s_priv[i] or "struct mtk_afe_i2s_priv"\ninstead of afe_priv which has the size of "struct mt8365_afe_private".\n\nOtherwise the KASAN complains about.\n\n[ 59.389765] BUG: KASAN: global-out-of-bounds in mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]\n...\n[ 59.394789] Call trace:\n[ 59.395167] dump_backtrace+0xa0/0x128\n[ 59.395733] show_stack+0x20/0x38\n[ 59.396238] dump_stack_lvl+0xe8/0x148\n[ 59.396806] print_report+0x37c/0x5e0\n[ 59.397358] kasan_report+0xac/0xf8\n[ 59.397885] kasan_check_range+0xe8/0x190\n[ 59.398485] asan_memcpy+0x3c/0x98\n[ 59.399022] mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]\n[ 59.399928] mt8365_dai_i2s_register+0x1e8/0x2b0 [snd_soc_mt8365_pcm]\n[ 59.400893] mt8365_afe_pcm_dev_probe+0x4d0/0xdf0 [snd_soc_mt8365_pcm]\n[ 59.401873] platform_probe+0xcc/0x228\n[ 59.402442] really_probe+0x340/0x9e8\n[ 59.402992] driver_probe_device+0x16c/0x3f8\n[ 59.403638] driver_probe_device+0x64/0x1d8\n[ 59.404256] driver_attach+0x1dc/0x4c8\n[ 59.404840] bus_for_each_dev+0x100/0x190\n[ 59.405442] driver_attach+0x44/0x68\n[ 59.405980] bus_add_driver+0x23c/0x500\n[ 59.406550] driver_register+0xf8/0x3d0\n[ 59.407122] platform_driver_register+0x68/0x98\n[ 59.407810] mt8365_afe_pcm_driver_init+0x2c/0xff8 [snd_soc_mt8365_pcm]

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: alienware-wmi-wmax: Fix `dmi_system_id` array\n\nAdd missing empty member to `awcc_dmi_table`.

In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails\n\nHave nvmet_req_init() and req->execute() complete failed commands.\n\nDescription of the problem:\nnvmet_req_init() calls __nvmet_req_complete() internally upon failure,\ne.g., unsupported opcode, which calls the "queue_response" callback,\nthis results in nvmet_pci_epf_queue_response() being called, which will\ncall nvmet_pci_epf_complete_iod() if data_len is 0 or if dma_dir is\ndifferent from DMA_TO_DEVICE. This results in a double completion as\nnvmet_pci_epf_exec_iod_work() also calls nvmet_pci_epf_complete_iod()\nwhen nvmet_req_init() fails.\n\nSteps to reproduce:\nOn the host send a command with an unsupported opcode with nvme-cli,\nFor example the admin command "security receive"\n$ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096\n\nThis triggers a double completion as nvmet_req_init() fails and\nnvmet_pci_epf_queue_response() is called, here iod->dma_dir is still\nin the default state of "DMA_NONE" as set by default in\nnvmet_pci_epf_alloc_iod(), so nvmet_pci_epf_complete_iod() is called.\nBecause nvmet_req_init() failed nvmet_pci_epf_complete_iod() is also\ncalled in nvmet_pci_epf_exec_iod_work() leading to a double completion.\nThis not only sends two completions to the host but also corrupts the\nstate of the PCI NVMe target leading to kernel oops.\n\nThis patch lets nvmet_req_init() and req->execute() complete all failed\ncommands, and removes the double completion case in\nnvmet_pci_epf_exec_iod_work() therefore fixing the edge cases where\ndouble completions occurred.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: mcc: prevent shift wrapping in rtw89_core_mlsr_switch()\n\nThe "link_id" value comes from the user via debugfs. If it's larger\nthan BITS_PER_LONG then that would result in shift wrapping and\npotentially an out of bounds access later. In fact, we can limit it\nto IEEE80211_MLD_MAX_NUM_LINKS (15).\n\nFortunately, only root can write to debugfs files so the security\nimpact is minimal.

In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: canaan: k230: add NULL check in DT parse\n\nAdd a NULL check for the return value of of_get_property() when\nretrieving the "pinmux" property in the group parser. This avoids\na potential NULL pointer dereference if the property is missing\nfrom the device tree node.\n\nAlso fix a typo ("sintenel") in the device ID match table comment,\ncorrecting it to "sentinel".

In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: canaan: k230: Fix order of DT parse and pinctrl register\n\nMove DT parse before pinctrl register. This ensures that device tree\nparsing is done before calling devm_pinctrl_register() to prevent using\nuninitialized pin resources.

In the Linux kernel, the following vulnerability has been resolved:\n\nlandlock: Fix warning from KUnit tests\n\nget_id_range() expects a positive value as first argument but\nget_random_u8() can return 0. Fix this by clamping it.\n\nValidated by running the test in a for loop for 1000 times.\n\nNote that MAX() is wrong as it is only supposed to be used for\nconstants, but max() is good here.\n\n [..] ok 9 test_range2_rand1\n [..] ok 10 test_range2_rand2\n [..] ok 11 test_range2_rand15\n [..] ------------[ cut here ]------------\n [..] WARNING: CPU: 6 PID: 104 at security/landlock/id.c:99 test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1))\n [..] Modules linked in:\n [..] CPU: 6 UID: 0 PID: 104 Comm: kunit_try_catch Tainted: G N 6.16.0-rc1-dev-00001-g314a2f98b65f #1 PREEMPT(undef)\n [..] Tainted: [N]=TEST\n [..] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n [..] RIP: 0010:test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1))\n [..] Code: 49 c7 c0 10 70 30 82 4c 89 ff 48 c7 c6 a0 63 1e 83 49 c7 45 a0 e0 63 1e 83 e8 3f 95 17 00 e9 1f ff ff ff 0f 0b e9 df fd ff ff <0f> 0b ba 01 00 00 00 e9 68 fe ff ff 49 89 45 a8 49 8d 4d a0 45 31\n\n [..] RSP: 0000:ffff888104eb7c78 EFLAGS: 00010246\n [..] RAX: 0000000000000000 RBX: 000000000870822c RCX: 0000000000000000\n ^^^^^^^^^^^^^^^^\n [..]\n [..] Call Trace:\n [..]\n [..] ---[ end trace 0000000000000000 ]---\n [..] ok 12 test_range2_rand16\n [..] # landlock_id: pass:12 fail:0 skip:0 total:12\n [..] # Totals: pass:12 fail:0 skip:0 total:12\n [..] ok 1 landlock_id\n\n[mic: Minor cosmetic improvements]

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: sar: drop lockdep assertion in rtw89_set_sar_from_acpi\n\nThe following assertion is triggered on the rtw89 driver startup. It\nlooks meaningless to hold wiphy lock on the early init stage so drop the\nassertion.\n\n WARNING: CPU: 7 PID: 629 at drivers/net/wireless/realtek/rtw89/sar.c:502 rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]\n CPU: 7 UID: 0 PID: 629 Comm: (udev-worker) Not tainted 6.15.0+ #29 PREEMPT(lazy)\n Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN50WW 09/27/2024\n RIP: 0010:rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]\n Call Trace:\n \n rtw89_sar_init+0x68/0x2c0 [rtw89_core]\n rtw89_core_init+0x188e/0x1e50 [rtw89_core]\n rtw89_pci_probe+0x530/0xb50 [rtw89_pci]\n local_pci_probe+0xd9/0x190\n pci_call_probe+0x183/0x540\n pci_device_probe+0x171/0x2c0\n really_probe+0x1e1/0x890\n __driver_probe_device+0x18c/0x390\n driver_probe_device+0x4a/0x120\n __driver_attach+0x1a0/0x530\n bus_for_each_dev+0x10b/0x190\n bus_add_driver+0x2eb/0x540\n driver_register+0x1a3/0x3a0\n do_one_initcall+0xd5/0x450\n do_init_module+0x2cc/0x8f0\n init_module_from_file+0xe1/0x150\n idempotent_init_module+0x226/0x760\n __x64_sys_finit_module+0xcd/0x150\n do_syscall_64+0x94/0x380\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFound by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix WARN_ON for monitor mode on some devices\n\nOn devices without WANT_MONITOR_VIF (and probably without\nchannel context support) we get a WARN_ON for changing the\nper-link setting of a monitor interface.\n\nSince we already skip AP_VLAN interfaces and MONITOR with\nWANT_MONITOR_VIF and/or NO_VIRTUAL_MONITOR should update\nthe settings, catch this in the link change code instead\nof the warning.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: Fix potential NULL dereference on kmalloc failure\n\nAvoid potential NULL pointer dereference by checking the return value of\nkmalloc and handling allocation failure properly.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: add a retry logic in net6_rt_notify()\n\ninet6_rt_notify() can be called under RCU protection only.\nThis means the route could be changed concurrently\nand rt6_fill_node() could return -EMSGSIZE.\n\nRe-size the skb when this happens and retry, removing\none WARN_ON() that syzbot was able to trigger:\n\nWARNING: CPU: 3 PID: 6291 at net/ipv6/route.c:6342 inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342\nModules linked in:\nCPU: 3 UID: 0 PID: 6291 Comm: syz.0.77 Not tainted 6.16.0-rc7-syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n RIP: 0010:inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342\nCode: fc ff ff e8 6d 52 ea f7 e9 47 fc ff ff 48 8b 7c 24 08 4c 89 04 24 e8 5a 52 ea f7 4c 8b 04 24 e9 94 fd ff ff e8 9c fe 84 f7 90 <0f> 0b 90 e9 bd fd ff ff e8 6e 52 ea f7 e9 bb fb ff ff 48 89 df e8\nRSP: 0018:ffffc900035cf1d8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffc900035cf540 RCX: ffffffff8a36e790\nRDX: ffff88802f7e8000 RSI: ffffffff8a36e9d4 RDI: 0000000000000005\nRBP: ffff88803c230f00 R08: 0000000000000005 R09: 00000000ffffffa6\nR10: 00000000ffffffa6 R11: 0000000000000001 R12: 00000000ffffffa6\nR13: 0000000000000900 R14: ffff888032ea4100 R15: 0000000000000000\nFS: 00007fac7b89a6c0(0000) GS:ffff8880d6a20000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fac7b899f98 CR3: 0000000034b3f000 CR4: 0000000000352ef0\nCall Trace:\n \n ip6_route_mpath_notify+0xde/0x280 net/ipv6/route.c:5356\n ip6_route_multipath_add+0x1181/0x1bd0 net/ipv6/route.c:5536\n inet6_rtm_newroute+0xe4/0x1a0 net/ipv6/route.c:5647\n rtnetlink_rcv_msg+0x95e/0xe90 net/core/rtnetlink.c:6944\n netlink_rcv_skb+0x155/0x420 net/netlink/af_netlink.c:2552\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x58d/0x850 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: spacemit: mark K1 pll1_d8 as critical\n\nThe pll1_d8 clock is enabled by the boot loader, and is ultimately a\nparent for numerous clocks, including those used by APB and AXI buses.\nGuodong Xu discovered that this clock got disabled while responding to\ngetting -EPROBE_DEFER when requesting a reset controller.\n\nThe needed clock (CLK_DMA, along with its parents) had already been\nenabled. To respond to the probe deferral return, the CLK_DMA clock\nwas disabled, and this led to parent clocks also reducing their enable\ncount. When the enable count for pll1_d8 was decremented it became 0,\nwhich caused it to be disabled. This led to a system hang.\n\nMarking that clock critical resolves this by preventing it from being\ndisabled.\n\nDefine a new macro CCU_FACTOR_GATE_DEFINE() to allow clock flags to\nbe supplied for a CCU_FACTOR_GATE clock.

In the Linux kernel, the following vulnerability has been resolved:\n\npinmux: fix race causing mux_owner NULL with active mux_usecount\n\ncommit 5a3e85c3c397 ("pinmux: Use sequential access to access\ndesc->pinmux data") tried to address the issue when two client of the\nsame gpio calls pinctrl_select_state() for the same functionality, was\nresulting in NULL pointer issue while accessing desc->mux_owner.\nHowever, issue was not completely fixed due to the way it was handled\nand it can still result in the same NULL pointer.\n\nThe issue occurs due to the following interleaving:\n\n cpu0 (process A) cpu1 (process B)\n\n pin_request() { pin_free() {\n\n mutex_lock()\n desc->mux_usecount--; //becomes 0\n ..\n mutex_unlock()\n\n mutex_lock(desc->mux)\n desc->mux_usecount++; // becomes 1\n desc->mux_owner = owner;\n mutex_unlock(desc->mux)\n\n mutex_lock(desc->mux)\n desc->mux_owner = NULL;\n mutex_unlock(desc->mux)\n\nThis sequence leads to a state where the pin appears to be in use\n(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can\ncause NULL pointer on next pin_request on the same pin.\n\nEnsure that updates to mux_usecount and mux_owner are performed\natomically under the same lock. Only clear mux_owner when mux_usecount\nreaches zero and no new owner has been assigned.

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: imx95-blk-ctl: Fix synchronous abort\n\nWhen enabling runtime PM for clock suppliers that also belong to a power\ndomain, the following crash is thrown:\nerror: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP\nWorkqueue: events_unbound deferred_probe_work_func\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : clk_mux_get_parent+0x60/0x90\nlr : clk_core_reparent_orphans_nolock+0x58/0xd8\n Call trace:\n clk_mux_get_parent+0x60/0x90\n clk_core_reparent_orphans_nolock+0x58/0xd8\n of_clk_add_hw_provider.part.0+0x90/0x100\n of_clk_add_hw_provider+0x1c/0x38\n imx95_bc_probe+0x2e0/0x3f0\n platform_probe+0x70/0xd8\n\nEnabling runtime PM without explicitly resuming the device caused\nthe power domain cut off after clk_register() is called. As a result,\na crash happens when the clock hardware provider is added and attempts\nto access the BLK_CTL register.\n\nFix this by using devm_pm_runtime_enable() instead of pm_runtime_enable()\nand getting rid of the pm_runtime_disable() in the cleanup path.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb: scarlett2: Fix missing NULL check\n\nscarlett2_input_select_ctl_info() sets up the string arrays allocated\nvia kasprintf(), but it misses NULL checks, which may lead to NULL\ndereference Oops. Let's add the proper NULL check.

In the Linux kernel, the following vulnerability has been resolved:\n\nvdpa/mlx5: Fix release of uninitialized resources on error path\n\nThe commit in the fixes tag made sure that mlx5_vdpa_free()\nis the single entrypoint for removing the vdpa device resources\nadded in mlx5_vdpa_dev_add(), even in the cleanup path of\nmlx5_vdpa_dev_add().\n\nThis means that all functions from mlx5_vdpa_free() should be able to\nhandle uninitialized resources. This was not the case though:\nmlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx()\nwere not able to do so. This caused the splat below when adding\na vdpa device without a MAC address.\n\nThis patch fixes these remaining issues:\n\n- Makes mlx5_vdpa_destroy_mr_resources() return early if called on\n uninitialized resources.\n\n- Moves mlx5_cmd_init_async_ctx() early on during device addition\n because it can't fail. This means that mlx5_cmd_cleanup_async_ctx()\n also can't fail. To mirror this, move the call site of\n mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().\n\nAn additional comment was added in mlx5_vdpa_free() to document\nthe expectations of functions called from this context.\n\nSplat:\n\n mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned?\n ------------[ cut here ]------------\n WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0\n [...]\n Call Trace:\n \n ? __try_to_del_timer_sync+0x61/0x90\n ? __timer_delete_sync+0x2b/0x40\n mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa]\n mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa]\n vdpa_release_dev+0x1e/0x50 [vdpa]\n device_release+0x31/0x90\n kobject_cleanup+0x37/0x130\n mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa]\n vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa]\n genl_family_rcv_msg_doit+0xd8/0x130\n genl_family_rcv_msg+0x14b/0x220\n ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa]\n genl_rcv_msg+0x47/0xa0\n ? __pfx_genl_rcv_msg+0x10/0x10\n netlink_rcv_skb+0x53/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x27b/0x3b0\n netlink_sendmsg+0x1f7/0x430\n __sys_sendto+0x1fa/0x210\n ? ___pte_offset_map+0x17/0x160\n ? next_uptodate_folio+0x85/0x2b0\n ? percpu_counter_add_batch+0x51/0x90\n ? filemap_map_pages+0x515/0x660\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x7b/0x2c0\n ? do_read_fault+0x108/0x220\n ? do_pte_missing+0x14a/0x3e0\n ? __handle_mm_fault+0x321/0x730\n ? count_memcg_events+0x13f/0x180\n ? handle_mm_fault+0x1fb/0x2d0\n ? do_user_addr_fault+0x20c/0x700\n ? syscall_exit_work+0x104/0x140\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f0c25b0feca\n [...]\n ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nmd: make rdev_addable usable for rcu mode\n\nOur testcase trigger panic:\n\nBUG: kernel NULL pointer dereference, address: 00000000000000e0\n...\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94\nPREEMPT(none)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nWorkqueue: md_misc md_start_sync\nRIP: 0010:rdev_addable+0x4d/0xf0\n...\nCall Trace:\n \n md_start_sync+0x329/0x480\n process_one_work+0x226/0x6d0\n worker_thread+0x19e/0x340\n kthread+0x10f/0x250\n ret_from_fork+0x14d/0x180\n ret_from_fork_asm+0x1a/0x30\n \nModules linked in: raid10\nCR2: 00000000000000e0\n---[ end trace 0000000000000000 ]---\nRIP: 0010:rdev_addable+0x4d/0xf0\n\nmd_spares_need_change in md_start_sync will call rdev_addable which\nprotected by rcu_read_lock/rcu_read_unlock. This rcu context will help\nprotect rdev won't be released, but rdev->mddev will be set to NULL\nbefore we call synchronize_rcu in md_kick_rdev_from_array. Fix this by\nusing READ_ONCE and check does rdev->mddev still alive.

In the Linux kernel, the following vulnerability has been resolved:\n\nzloop: fix KASAN use-after-free of tag set\n\nWhen a zoned loop device, or zloop device, is removed, KASAN enabled\nkernel reports "BUG KASAN use-after-free" in blk_mq_free_tag_set(). The\nBUG happens because zloop_ctl_remove() calls put_disk(), which invokes\nzloop_free_disk(). The zloop_free_disk() frees the memory allocated for\nthe zlo pointer. However, after the memory is freed, zloop_ctl_remove()\ncalls blk_mq_free_tag_set(&zlo->tag_set), which accesses the freed zlo.\nHence the KASAN use-after-free.\n\n zloop_ctl_remove()\n put_disk(zlo->disk)\n put_device()\n kobject_put()\n ...\n zloop_free_disk()\n kvfree(zlo)\n blk_mq_free_tag_set(&zlo->tag_set)\n\nTo avoid the BUG, move the call to blk_mq_free_tag_set(&zlo->tag_set)\nfrom zloop_ctl_remove() into zloop_free_disk(). This ensures that\nthe tag_set is freed before the call to kvfree(zlo).

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ti: j721e-csi2rx: fix list_del corruption\n\nIf ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is\nmarked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue.\nThis causes the same buffer to be retried in the next iteration, resulting\nin a double list_del() and eventual list corruption.\n\nFix this by removing the buffer from the queue before calling\nvb2_buffer_done() on error.\n\nThis resolves a crash due to list_del corruption:\n[ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA\n[ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048\n[ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428)\n[ 37.850799] ------------[ cut here ]------------\n[ 37.855424] kernel BUG at lib/list_debug.c:65!\n[ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul\n[ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY\n[ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT)\n[ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114\n[ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114\n[ 37.914059] sp : ffff800080003db0\n[ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000\n[ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122\n[ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0\n[ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a\n[ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720\n[ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea\n[ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568\n[ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff\n[ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000\n[ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d\n[ 37.988832] Call trace:\n[ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P)\n[ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4\n[ 38.001419] udma_vchan_complete+0x1e0/0x344\n[ 38.005705] tasklet_action_common+0x118/0x310\n[ 38.010163] tasklet_action+0x30/0x3c\n[ 38.013832] handle_softirqs+0x10c/0x2e0\n[ 38.017761] __do_softirq+0x14/0x20\n[ 38.021256] ____do_softirq+0x10/0x20\n[ 38.024931] call_on_irq_stack+0x24/0x60\n[ 38.028873] do_softirq_own_stack+0x1c/0x40\n[ 38.033064] __irq_exit_rcu+0x130/0x15c\n[ 38.036909] irq_exit_rcu+0x10/0x20\n[ 38.040403] el1_interrupt+0x38/0x60\n[ 38.043987] el1h_64_irq_handler+0x18/0x24\n[ 38.048091] el1h_64_irq+0x6c/0x70\n[ 38.051501] default_idle_call+0x34/0xe0 (P)\n[ 38.055783] do_idle+0x1f8/0x250\n[ 38.059021] cpu_startup_entry+0x34/0x3c\n[ 38.062951] rest_init+0xb4/0xc0\n[ 38.066186] console_on_rootfs+0x0/0x6c\n[ 38.070031] __primary_switched+0x88/0x90\n[ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000)\n[ 38.080168] ---[ end trace 0000000000000000 ]---\n[ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt\n[ 38.092197] SMP: stopping secondary CPUs\n[ 38.096139] Kernel Offset: disabled\n[ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b\n[ 38.105202] Memory Limit: none\n[ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: Fix kernel crash when hard resetting the GPU\n\nThe GPU hard reset sequence calls pm_runtime_force_suspend() and\npm_runtime_force_resume(), which according to their documentation should\nonly be used during system-wide PM transitions to sleep states.\n\nThe main issue though is that depending on some internal runtime PM\nstate as seen by pm_runtime_force_suspend() (whether the usage count is\n<= 1), pm_runtime_force_resume() might not resume the device unless\nneeded. If that happens, the runtime PM resume callback\npvr_power_device_resume() is not called, the GPU clocks are not\nre-enabled, and the kernel crashes on the next attempt to access GPU\nregisters as part of the power-on sequence.\n\nReplace calls to pm_runtime_force_suspend() and\npm_runtime_force_resume() with direct calls to the driver's runtime PM\ncallbacks, pvr_power_device_suspend() and pvr_power_device_resume(),\nto ensure clocks are re-enabled and avoid the kernel crash.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon: fix divide by zero in damon_get_intervals_score()\n\nThe current implementation allows having zero size regions with no special\nreasons, but damon_get_intervals_score() gets crashed by divide by zero\nwhen the region size is zero.\n\n [ 29.403950] Oops: divide error: 0000 [#1] SMP NOPTI\n\nThis patch fixes the bug, but does not disallow zero size regions to keep\nthe backward compatibility since disallowing zero size regions might be a\nbreaking change for some users.\n\nIn addition, the same crash can happen when intervals_goal.access_bp is\nzero so this should be fixed in stable trees as well.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU/AMD: Disable INVLPGB on Zen2\n\nAMD Cyan Skillfish (Family 17h, Model 47h, Stepping 0h) has an issue\nthat causes system oopses and panics when performing TLB flush using\nINVLPGB.\n\nHowever, the problem is that that machine has misconfigured CPUID and\nshould not report the INVLPGB bit in the first place. So zap the\nkernel's representation of the flag so that nothing gets confused.\n\n [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:\n\nlib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users()\n\nalloc_tag_top_users() attempts to lock alloc_tag_cttype->mod_lock even\nwhen the alloc_tag_cttype is not allocated because:\n\n 1) alloc tagging is disabled because mem profiling is disabled\n (!alloc_tag_cttype)\n 2) alloc tagging is enabled, but not yet initialized (!alloc_tag_cttype)\n 3) alloc tagging is enabled, but failed initialization\n (!alloc_tag_cttype or IS_ERR(alloc_tag_cttype))\n\nIn all cases, alloc_tag_cttype is not allocated, and therefore\nalloc_tag_top_users() should not attempt to acquire the semaphore.\n\nThis leads to a crash on memory allocation failure by attempting to\nacquire a non-existent semaphore:\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df]\n CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G D 6.16.0-rc2 #1 VOLUNTARY\n Tainted: [D]=DIE\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n RIP: 0010:down_read_trylock+0xaa/0x3b0\n Code: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff\n RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016\n RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000\n RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000000000070\n RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1\n R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37\n R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000\n FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0\n Call Trace:\n \n codetag_trylock_module_list+0xd/0x20\n alloc_tag_top_users+0x369/0x4b0\n __show_mem+0x1cd/0x6e0\n warn_alloc+0x2b1/0x390\n __alloc_frozen_pages_noprof+0x12b9/0x21a0\n alloc_pages_mpol+0x135/0x3e0\n alloc_slab_page+0x82/0xe0\n new_slab+0x212/0x240\n ___slab_alloc+0x82a/0xe00\n \n\nAs David Wang points out, this issue became easier to trigger after commit\n780138b12381 ("alloc_tag: check mem_profiling_support in alloc_tag_init").\n\nBefore the commit, the issue occurred only when it failed to allocate and\ninitialize alloc_tag_cttype or if a memory allocation fails before\nalloc_tag_init() is called. After the commit, it can be easily triggered\nwhen memory profiling is compiled but disabled at boot.\n\nTo properly determine whether alloc_tag_init() has been called and its\ndata structures initialized, verify that alloc_tag_cttype is a valid\npointer before acquiring the semaphore. If the variable is NULL or an\nerror value, it has not been properly initialized. In such a case, just\nskip and do not attempt to acquire the semaphore.\n\n[harry.yoo@oracle.com: v3]

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/pf: Clear all LMTT pages on alloc\n\nOur LMEM buffer objects are not cleared by default on alloc\nand during VF provisioning we only setup LMTT PTEs for the\nactually provisioned LMEM range. But beyond that valid range\nwe might leave some stale data that could either point to some\nother VFs allocations or even to the PF pages.\n\nExplicitly clear all new LMTT page to avoid the risk that a\nmalicious VF would try to exploit that gap.\n\nWhile around add asserts to catch any undesired PTE overwrites\nand low-level debug traces to track LMTT PT life-cycle.\n\n(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Use TSC_FACTOR for Secure TSC frequency calculation\n\nWhen using Secure TSC, the GUEST_TSC_FREQ MSR reports a frequency based on\nthe nominal P0 frequency, which deviates slightly (typically ~0.2%) from\nthe actual mean TSC frequency due to clocking parameters.\n\nOver extended VM uptime, this discrepancy accumulates, causing clock skew\nbetween the hypervisor and a SEV-SNP VM, leading to early timer interrupts as\nperceived by the guest.\n\nThe guest kernel relies on the reported nominal frequency for TSC-based\ntimekeeping, while the actual frequency set during SNP_LAUNCH_START may\ndiffer. This mismatch results in inaccurate time calculations, causing the\nguest to perceive hrtimers as firing earlier than expected.\n\nUtilize the TSC_FACTOR from the SEV firmware's secrets page (see "Secrets\nPage Format" in the SNP Firmware ABI Specification) to calculate the mean\nTSC frequency, ensuring accurate timekeeping and mitigating clock skew in\nSEV-SNP VMs.\n\nUse early_ioremap_encrypted() to map the secrets page as\nioremap_encrypted() uses kmalloc() which is not available during early TSC\ninitialization and causes a panic.\n\n [ bp: Drop the silly dummy var:\n https://lore.kernel.org/r/20250630192726.GBaGLlHl84xIopx4Pt@fat_crate.local ]

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: discard erroneous disassoc frames on STA interface\n\nWhen operating in concurrent STA/AP mode with host MLME enabled,\nthe firmware incorrectly sends disassociation frames to the STA\ninterface when clients disconnect from the AP interface.\nThis causes kernel warnings as the STA interface processes\ndisconnect events that don't apply to it:\n\n[ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211]\n[ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us\n[ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT\n[ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT)\n[ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex]\n[ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211]\n[ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211]\n[ 1303.370221] sp : ffff800083053be0\n[ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000\n[ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae\n[ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008\n[ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006\n[ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048\n[ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000\n[ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300\n[ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002\n[ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186\n[ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de\n[ 1303.446221] Call trace:\n[ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P)\n[ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211]\n[ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex]\n[ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex]\n[ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex]\n[ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex]\n[ 1303.483734] process_one_work+0x14c/0x28c\n[ 1303.487845] worker_thread+0x2cc/0x3d4\n[ 1303.491680] kthread+0x12c/0x208\n[ 1303.495014] ret_from_fork+0x10/0x20\n\nAdd validation in the STA receive path to verify that disassoc/deauth\nframes originate from the connected AP. Frames that fail this check\nare discarded early, preventing them from reaching the MLME layer and\ntriggering WARN_ON().\n\nThis filtering logic is similar with that used in the\nieee80211_rx_mgmt_disassoc() function in mac80211, which drops\ndisassoc frames that don't match the current BSSID\n(!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), ensuring\nonly relevant frames are processed.\n\nTested on:\n- 8997 with FW 16.68.1.p197

EDK2 contains a vulnerability in BIOS where an attacker may cause “Protection Mechanism Failure” by local access. Successful exploitation of this vulnerability will lead to arbitrary code execution and impact Confidentiality, Integrity, and Availability.

In the Linux kernel, the following vulnerability has been resolved:\n\ntls: stop recv() if initial process_rx_list gave us non-DATA\n\nIf we have a non-DATA record on the rx_list and another record of the\nsame type still on the queue, we will end up merging them:\n - process_rx_list copies the non-DATA record\n - we start the loop and process the first available record since it's\n of the same type\n - we break out of the loop since the record was not DATA\n\nJust check the record type and jump to the end in case process_rx_list\ndid some work.

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.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nvmci: Prevent the dispatching of uninitialized payloads\n\nThe reproducer executes the host's unlocked_ioctl call in two different\ntasks. When init_context fails, the struct vmci_event_ctx is not fully\ninitialized when executing vmci_datagram_dispatch() to send events to all\nvm contexts. This affects the datagram taken from the datagram queue of\nits context by another task, because the datagram payload is not initialized\naccording to the size payload_size, which causes the kernel data to leak\nto the user space.\n\nBefore dispatching the datagram, and before setting the payload content,\nexplicitly set the payload content to 0 to avoid data leakage caused by\nincomplete payload initialization.