A flaw was found in Git LFS. Running git lfs checkout and git lfs pull in a specially crafted repository, specifically with symbolic or hard links tracked by Git LFS and pointing to files outside the working tree or in a bare repository, can cause Git LFS to write to arbitrary file system locations accessible to the user running these commands.

In the Linux kernel, the following vulnerability has been resolved:\nocteontx2-pf: Fix potential use after free in otx2_tc_add_flow()\nThis code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"\nand then dereferences it on the next line. Two lines later, we take\na mutex so I don't think this is an RCU safe region. Re-order it to do\nthe dereferences before queuing up the free.

In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise __get_user() to probe user read access\n\nBecause of the way read access support is implemented, read access\ninterruptions are only triggered at privilege levels 2 and 3. The\nkernel executes at privilege level 0, so __get_user() never triggers\na read access interruption (code 26). Thus, it is currently possible\nfor user code to access a read protected address via a system call.\n\nFix this by probing read access rights at privilege level 3 (PRIV_USER)\nand setting __gu_err to -EFAULT (-14) if access isn't allowed.\n\nNote the cmpiclr instruction does a 32-bit compare because COND macro\ndoesn't work inside asm.

In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise gateway LWS calls to probe user read access\n\nWe use load and stbys,e instructions to trigger memory reference\ninterruptions without writing to memory. Because of the way read\naccess support is implemented, read access interruptions are only\ntriggered at privilege levels 2 and 3. The kernel and gateway\npage execute at privilege level 0, so this code never triggers\na read access interruption. Thus, it is currently possible for\nuser code to execute a LWS compare and swap operation at an\naddress that is read protected at privilege level 3 (PRIV_USER).\n\nFix this by probing read access rights at privilege level 3 and\nbranching to lws_fault if access isn't allowed.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()\n\nIn the interrupt handler rain_interrupt(), the buffer full check on\nrain->buf_len is performed before acquiring rain->buf_lock. This\ncreates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as\nrain->buf_len is concurrently accessed and modified in the work\nhandler rain_irq_work_handler() under the same lock.\n\nMultiple interrupt invocations can race, with each reading buf_len\nbefore it becomes full and then proceeding. This can lead to both\ninterrupts attempting to write to the buffer, incrementing buf_len\nbeyond its capacity (DATA_SIZE) and causing a buffer overflow.\n\nFix this bug by moving the spin_lock() to before the buffer full\ncheck. This ensures that the check and the subsequent buffer modification\nare performed atomically, preventing the race condition. An corresponding\nspin_unlock() is added to the overflow path to correctly release the\nlock.\n\nThis possible bug was found by an experimental static analysis tool\ndeveloped by our team.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/sclp: Fix SCCB present check\n\nTracing code called by the SCLP interrupt handler contains early exits\nif the SCCB address associated with an interrupt is NULL. This check is\nperformed after physical to virtual address translation.\n\nIf the kernel identity mapping does not start at address zero, the\nresulting virtual address is never zero, so that the NULL checks won't\nwork. Subsequently this may result in incorrect accesses to the first\npage of the identity mapping.\n\nFix this by introducing a function that handles the NULL case before\naddress translation.

In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Also allocate and copy hash for reading of filter files\n\nCurrently the reader of set_ftrace_filter and set_ftrace_notrace just adds\nthe pointer to the global tracer hash to its iterator. Unlike the writer\nthat allocates a copy of the hash, the reader keeps the pointer to the\nfilter hashes. This is problematic because this pointer is static across\nfunction calls that release the locks that can update the global tracer\nhashes. This can cause UAF and similar bugs.\n\nAllocate and copy the hash for reading the filter files like it is done\nfor the writers. This not only fixes UAF bugs, but also makes the code a\nbit simpler as it doesn't have to differentiate when to free the\niterator's hash between writers and readers.

In the Linux kernel, the following vulnerability has been resolved:\n\ntls: fix handling of zero-length records on the rx_list\n\nEach recvmsg() call must process either\n - only contiguous DATA records (any number of them)\n - one non-DATA record\n\nIf the next record has different type than what has already been\nprocessed we break out of the main processing loop. If the record\nhas already been decrypted (which may be the case for TLS 1.3 where\nwe don't know type until decryption) we queue the pending record\nto the rx_list. Next recvmsg() will pick it up from there.\n\nQueuing the skb to rx_list after zero-copy decrypt is not possible,\nsince in that case we decrypted directly to the user space buffer,\nand we don't have an skb to queue (darg.skb points to the ciphertext\nskb for access to metadata like length).\n\nOnly data records are allowed zero-copy, and we break the processing\nloop after each non-data record. So we should never zero-copy and\nthen find out that the record type has changed. The corner case\nwe missed is when the initial record comes from rx_list, and it's\nzero length.

In the Linux kernel, the following vulnerability has been resolved:\n\ngve: prevent ethtool ops after shutdown\n\nA crash can occur if an ethtool operation is invoked\nafter shutdown() is called.\n\nshutdown() is invoked during system shutdown to stop DMA operations\nwithout performing expensive deallocations. It is discouraged to\nunregister the netdev in this path, so the device may still be visible\nto userspace and kernel helpers.\n\nIn gve, shutdown() tears down most internal data structures. If an\nethtool operation is dispatched after shutdown(), it will dereference\nfreed or NULL pointers, leading to a kernel panic. While graceful\nshutdown normally quiesces userspace before invoking the reboot\nsyscall, forced shutdowns (as observed on GCP VMs) can still trigger\nthis path.\n\nFix by calling netif_device_detach() in shutdown().\nThis marks the device as detached so the ethtool ioctl handler\nwill skip dispatching operations to the driver.

A flaw was found in Samba, in the vfs_streams_xattr module, where uninitialized heap memory could be written into alternate data streams. This allows an authenticated user to read residual memory content that may include sensitive data, resulting in an information disclosure vulnerability.

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

In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: fix blk_mq_tags double free while nr_requests grown\n\nIn the case user trigger tags grow by queue sysfs attribute nr_requests,\nhctx->sched_tags will be freed directly and replaced with a new\nallocated tags, see blk_mq_tag_update_depth().\n\nThe problem is that hctx->sched_tags is from elevator->et->tags, while\net->tags is still the freed tags, hence later elevator exit will try to\nfree the tags again, causing kernel panic.\n\nFix this problem by replacing et->tags with new allocated tags as well.\n\nNoted there are still some long term problems that will require some\nrefactor to be fixed thoroughly[1].\n\n[1] https://lore.kernel.org/all/20250815080216.410665-1-yukuai1@huaweicloud.com/

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: check for stable address space before operating on the VMA\n\nIt is possible to hit a zero entry while traversing the vmas in unuse_mm()\ncalled from swapoff path and accessing it causes the OOPS:\n\nUnable to handle kernel NULL pointer dereference at virtual address\n0000000000000446--> Loading the memory from offset 0x40 on the\nXA_ZERO_ENTRY as address.\nMem abort info:\n ESR = 0x0000000096000005\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x05: level 1 translation fault\n\nThe issue is manifested from the below race between the fork() on a\nprocess and swapoff:\nfork(dup_mmap()) swapoff(unuse_mm)\n--------------- -----------------\n1) Identical mtree is built using\n __mt_dup().\n\n2) copy_pte_range()-->\n copy_nonpresent_pte():\n The dst mm is added into the\n mmlist to be visible to the\n swapoff operation.\n\n3) Fatal signal is sent to the parent\nprocess(which is the current during the\nfork) thus skip the duplication of the\nvmas and mark the vma range with\nXA_ZERO_ENTRY as a marker for this process\nthat helps during exit_mmap().\n\n 4) swapoff is tried on the\n 'mm' added to the 'mmlist' as\n part of the 2.\n\n 5) unuse_mm(), that iterates\n through the vma's of this 'mm'\n will hit the non-NULL zero entry\n and operating on this zero entry\n as a vma is resulting into the\n oops.\n\nThe proper fix would be around not exposing this partially-valid tree to\nothers when droping the mmap lock, which is being solved with [1]. A\nsimpler solution would be checking for MMF_UNSTABLE, as it is set if\nmm_struct is not fully initialized in dup_mmap().\n\nThanks to Liam/Lorenzo/David for all the suggestions in fixing this\nissue.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()\n\nIf ab->fw.m3_data points to data, then fw pointer remains null.\nFurther, if m3_mem is not allocated, then fw is dereferenced to be\npassed to ath11k_err function.\n\nReplace fw->size by m3_len.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: Update napi->skb after XDP process\n\nThe syzbot report a UAF issue:\n\n BUG: KASAN: slab-use-after-free in skb_reset_mac_header include/linux/skbuff.h:3150 [inline]\n BUG: KASAN: slab-use-after-free in napi_frags_skb net/core/gro.c:723 [inline]\n BUG: KASAN: slab-use-after-free in napi_gro_frags+0x6e/0x1030 net/core/gro.c:758\n Read of size 8 at addr ffff88802ef22c18 by task syz.0.17/6079\n CPU: 0 UID: 0 PID: 6079 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)\n Call Trace:\n \n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n skb_reset_mac_header include/linux/skbuff.h:3150 [inline]\n napi_frags_skb net/core/gro.c:723 [inline]\n napi_gro_frags+0x6e/0x1030 net/core/gro.c:758\n tun_get_user+0x28cb/0x3e20 drivers/net/tun.c:1920\n tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x5c9/0xb30 fs/read_write.c:686\n ksys_write+0x145/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \n\n Allocated by task 6079:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n unpoison_slab_object mm/kasan/common.c:330 [inline]\n __kasan_mempool_unpoison_object+0xa0/0x170 mm/kasan/common.c:558\n kasan_mempool_unpoison_object include/linux/kasan.h:388 [inline]\n napi_skb_cache_get+0x37b/0x6d0 net/core/skbuff.c:295\n __alloc_skb+0x11e/0x2d0 net/core/skbuff.c:657\n napi_alloc_skb+0x84/0x7d0 net/core/skbuff.c:811\n napi_get_frags+0x69/0x140 net/core/gro.c:673\n tun_napi_alloc_frags drivers/net/tun.c:1404 [inline]\n tun_get_user+0x77c/0x3e20 drivers/net/tun.c:1784\n tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x5c9/0xb30 fs/read_write.c:686\n ksys_write+0x145/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n Freed by task 6079:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576\n poison_slab_object mm/kasan/common.c:243 [inline]\n __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2422 [inline]\n slab_free mm/slub.c:4695 [inline]\n kmem_cache_free+0x18f/0x400 mm/slub.c:4797\n skb_pp_cow_data+0xdd8/0x13e0 net/core/skbuff.c:969\n netif_skb_check_for_xdp net/core/dev.c:5390 [inline]\n netif_receive_generic_xdp net/core/dev.c:5431 [inline]\n do_xdp_generic+0x699/0x11a0 net/core/dev.c:5499\n tun_get_user+0x2523/0x3e20 drivers/net/tun.c:1872\n tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1996\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x5c9/0xb30 fs/read_write.c:686\n ksys_write+0x145/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nAfter commit e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in\ngeneric mode"), the original skb may be freed in skb_pp_cow_data() when\nXDP program was attached, which was allocated in tun_napi_alloc_frags().\nHowever, the napi->skb still point to the original skb, update it after\nXDP process.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Fix UAF in hci_conn_tx_dequeue\n\nThis fixes the following UAF caused by not properly locking hdev when\nprocessing HCI_EV_NUM_COMP_PKTS:\n\nBUG: KASAN: slab-use-after-free in hci_conn_tx_dequeue+0x1be/0x220 net/bluetooth/hci_conn.c:3036\nRead of size 4 at addr ffff8880740f0940 by task kworker/u11:0/54\n\nCPU: 1 UID: 0 PID: 54 Comm: kworker/u11:0 Not tainted 6.16.0-rc7 #3 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014\nWorkqueue: hci1 hci_rx_work\nCall Trace:\n \n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x230 mm/kasan/report.c:480\n kasan_report+0x118/0x150 mm/kasan/report.c:593\n hci_conn_tx_dequeue+0x1be/0x220 net/bluetooth/hci_conn.c:3036\n hci_num_comp_pkts_evt+0x1c8/0xa50 net/bluetooth/hci_event.c:4404\n hci_event_func net/bluetooth/hci_event.c:7477 [inline]\n hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531\n hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x70e/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245\n \n\nAllocated by task 54:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939\n le_conn_complete_evt+0x3d6/0x1220 net/bluetooth/hci_event.c:5628\n hci_le_enh_conn_complete_evt+0x189/0x470 net/bluetooth/hci_event.c:5794\n hci_event_func net/bluetooth/hci_event.c:7474 [inline]\n hci_event_packet+0x78c/0x1200 net/bluetooth/hci_event.c:7531\n hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x70e/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245\n\nFreed by task 9572:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2381 [inline]\n slab_free mm/slub.c:4643 [inline]\n kfree+0x18e/0x440 mm/slub.c:4842\n device_release+0x9c/0x1c0\n kobject_cleanup lib/kobject.c:689 [inline]\n kobject_release lib/kobject.c:720 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x22b/0x480 lib/kobject.c:737\n hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]\n hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173\n hci_abort_conn_sync+0x5d1/0xdf0 net/bluetooth/hci_sync.c:5689\n hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x70e/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix wrong index reference in smb2_compound_op()\n\nIn smb2_compound_op(), the loop that processes each command's response\nuses wrong indices when accessing response bufferes.\n\nThis incorrect indexing leads to improper handling of command results.\nAlso, if incorrectly computed index is greather than or equal to\nMAX_COMPOUND, it can cause out-of-bounds accesses.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/osnoise: Fix slab-out-of-bounds in _parse_integer_limit()\n\nWhen config osnoise cpus by write() syscall, the following KASAN splat may\nbe observed:\n\nBUG: KASAN: slab-out-of-bounds in _parse_integer_limit+0x103/0x130\nRead of size 1 at addr ffff88810121e3a1 by task test/447\nCPU: 1 UID: 0 PID: 447 Comm: test Not tainted 6.17.0-rc6-dirty #288 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n \n dump_stack_lvl+0x55/0x70\n print_report+0xcb/0x610\n kasan_report+0xb8/0xf0\n _parse_integer_limit+0x103/0x130\n bitmap_parselist+0x16d/0x6f0\n osnoise_cpus_write+0x116/0x2d0\n vfs_write+0x21e/0xcc0\n ksys_write+0xee/0x1c0\n do_syscall_64+0xa8/0x2a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \n\nThis issue can be reproduced by below code:\n\nconst char *cpulist = "1";\nint fd=open("/sys/kernel/debug/tracing/osnoise/cpus", O_WRONLY);\nwrite(fd, cpulist, strlen(cpulist));\n\nFunction bitmap_parselist() was called to parse cpulist, it require that\nthe parameter 'buf' must be terminated with a '\\0' or '\\n'. Fix this issue\nby adding a '\\0' to 'buf' in osnoise_cpus_write().

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.

A flaw was found in Samba, in the front-end WINS hook handling: NetBIOS names from registration packets are passed to a shell without proper validation or escaping. Unsanitized NetBIOS name data from WINS registration packets are inserted into a shell command and executed by the Samba Active Directory Domain Controller’s wins hook, allowing an unauthenticated network attacker to achieve remote command execution as the Samba process.

In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: xfrm_alloc_spi shouldn't use 0 as SPI\n\nx->id.spi == 0 means "no SPI assigned", but since commit\n94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states\nand add them to the byspi list with this value.\n\n__xfrm_state_delete doesn't remove those states from the byspi list,\nsince they shouldn't be there, and this shows up as a UAF the next\ntime we go through the byspi list.

It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2.\n\nWhen a STOR chunk is present, a subsequent FOBJ chunk will be saved in ctx->stored_frame. Stored frames can later be referenced by FTCH chunks. For files using subversion < 2, the undecoded frame is stored, and decoded again when the FTCH chunks are parsed. However, in process_frame_obj if the frame has an invalid size, there’s an early return, with a value of 0. \n\nThis causes the code in decode_frame to still store the raw frame buffer into ctx->stored_frame. Leaving ctx->has_dimensions set to false.\n\nA subsequent chunk with type FTCH would call process_ftch and decode that frame obj again, adding to the top/left values and calling process_frame_obj again.\nGiven that we never set ctx->have_dimensions before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx->stored_frame, freeing the previous one. However, the GetByteContext object gb still holds a reference to the old buffer.\n\n\n\n\nFinally, when the code tries to decode the frame, codecs that accept a GetByteContext as a parameter will trigger a use-after-free read when using gb.\n\nGetByteContext is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free and when the object is accessed. However, upon returning to process_ftch, the code restores the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator’s metadata.\n\nThis issue can be triggered just by probing whether a file has the sanm format.\n\n\n\n\n\n\n\nWe recommend upgrading to version 8.0 or beyond.

When decoding an OpenEXR file that uses DWAA or DWAB compression, there's an implicit assumption that the height and width are divisible by 8.\n\nIf the height or width of the image is not divisible by 8, the copy loops at [0] and [1] will continue to write until the next multiple of 8.\n\nThe buffer td->uncompressed_data is allocated in decode_block based on the precise height and width of the image, so the "rounded-up" multiple of 8 in the copy loop can exceed the buffer bounds, and the write block starting at [2] can corrupt following heap memory.\n\n\n\nWe recommend upgrading to version 8.0 or beyond.

When decoding a frame for a SANM file (ANIM v0 variant), the decoded data can be larger than the buffer allocated for it.\n\nFrames encoded with codec 48 can specify their resolution (width x height). A buffer of appropriate size is allocated depending on the resolution.\n\nThis codec can encode the frame contents using a run-length encoding algorithm. There are no checks that the decoded frame fits in the allocated buffer, leading to a heap-buffer-overflow.\n\nprocess_frame_obj initializes the buffers based on the frame resolution:\n\n\n\nWe recommend upgrading to version 8.0 or beyond.

Poppler 24.06.1 through 25.x before 25.04.0 allows stack consumption and a SIGSEGV via deeply nested structures within the metadata (such as GTS_PDFEVersion) of a PDF document, e.g., a regular expression for a long pdfsubver string. This occurs in Dict::lookup, Catalog::getMetadata, and associated functions in PDFDoc, with deep recursion in the regex executor (std::__detail::_Executor).

A reachable assertion in FFmpeg git-master commit N-113007-g8d24a28d06 allows attackers to cause a Denial of Service (DoS) via opening a crafted AAC file.

A flaw was found in the integration of Active Directory and the System Security Services Daemon (SSSD) on Linux systems. In default configurations, SSSD does not enable the Kerberos local authentication plugin (sssd_krb5_localauth_plugin), allowing an attacker with permission to modify certain AD attributes (such as userPrincipalName or samAccountName) to impersonate privileged users. This can result in unauthorized access or privilege escalation on domain-joined Linux hosts.

No description is available for this CVE.

No description is available for this CVE.

A flaw was found in binutils. Processing a specially crafted object file with the ld linker can trigger an out-of-bounds read in the get_link_hash_entry function in the bfd/elflink.c file due to an improper check, causing a crash and resulting in a denial of service.

A flaw was found in binutils. Processing a specially crafted object file with the ld linker can trigger an out-of-bounds write in the bfd_putl64 function in the bfd/libbfd.c file due to an improper check, causing a crash and resulting in a denial of service.

A flaw was found in binutils. Processing a specially crafted object file with the ld linker can trigger an out-of-bounds read in the bfd_elf_gc_record_vtentry function in the bfd/elflink.c file due to a missing sanity check, causing a crash and resulting in a denial of service.

A vulnerability has been found in GNU Binutils 2.45. The affected element is the function elf_swap_shdr in the library bfd/elfcode.h of the component Linker. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9ca499644a21ceb3f946d1c179c38a83be084490. To fix this issue, it is recommended to deploy a patch. The code maintainer replied with "[f]ixed for 2.46".

A flaw has been found in GNU Binutils 2.45. Impacted is the function _bfd_elf_parse_eh_frame of the file bfd/elf-eh-frame.c of the component Linker. Executing manipulation can lead to heap-based buffer overflow. The attack is restricted to local execution. The exploit has been published and may be used. This patch is called ea1a0737c7692737a644af0486b71e4a392cbca8. A patch should be applied to remediate this issue. The code maintainer replied with "[f]ixed for 2.46".

A vulnerability was detected in GNU Binutils 2.45. This issue affects the function dump_dwarf_section of the file binutils/objdump.c. Performing manipulation results in out-of-bounds read. The attack is only possible with local access. The exploit is now public and may be used. The patch is named f87a66db645caf8cc0e6fc87b0c28c78a38af59b. It is suggested to install a patch to address this issue.

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.

Rack is a modular Ruby web server interface. Prior to version 2.2.18, Rack::QueryParser enforces its params_limit only for parameters separated by &, while still splitting on both & and ;. As a result, attackers could use ; separators to bypass the parameter count limit and submit more parameters than intended. Applications or middleware that directly invoke Rack::QueryParser with its default configuration (no explicit delimiter) could be exposed to increased CPU and memory consumption. This can be abused as a limited denial-of-service vector. This issue has been patched in version 2.2.18.

Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free and potentially lead to remote code execution. The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2. To workaround this issue without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.

If the PATH environment variable contains paths which are executables (rather than just directories), passing certain strings to LookPath ("", ".", and ".."), can result in the binaries listed in the PATH being unexpectedly returned.

Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted LUA script to read out-of-bound data or crash the server and subsequent denial of service. The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2. To workaround this issue without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to block a script by restricting both the EVAL and FUNCTION command families.

Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to manipulate different LUA objects and potentially run their own code in the context of another user. The problem exists in all versions of Redis with LUA scripting. This issue is fixed in version 8.2.2. A workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing LUA scripts. This can be done using ACL to block a script by restricting both the EVAL and FUNCTION command families.

Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to cause an integer overflow and potentially lead to remote code execution The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR\n\nA NULL pointer dereference can occur in tcp_ao_finish_connect() during a\nconnect() system call on a socket with a TCP-AO key added and TCP_REPAIR\nenabled.\n\nThe function is called with skb being NULL and attempts to dereference it\non tcp_hdr(skb)->seq without a prior skb validation.\n\nFix this by checking if skb is NULL before dereferencing it.\n\nThe commentary is taken from bpf_skops_established(), which is also called\nin the same flow. Unlike the function being patched,\nbpf_skops_established() validates the skb before dereferencing it.\n\nint main(void){\n struct sockaddr_in sockaddr;\n struct tcp_ao_add tcp_ao;\n int sk;\n int one = 1;\n\n memset(&sockaddr,'\\0',sizeof(sockaddr));\n memset(&tcp_ao,'\\0',sizeof(tcp_ao));\n\n sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);\n\n sockaddr.sin_family = AF_INET;\n\n memcpy(tcp_ao.alg_name,"cmac(aes128)",12);\n memcpy(tcp_ao.key,"ABCDEFGHABCDEFGH",16);\n tcp_ao.keylen = 16;\n\n memcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr));\n\n setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao,\n sizeof(tcp_ao));\n setsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one));\n\n sockaddr.sin_family = AF_INET;\n sockaddr.sin_port = htobe16(123);\n\n inet_aton("127.0.0.1", &sockaddr.sin_addr);\n\n connect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr));\n\nreturn 0;\n}\n\n$ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall\n$ unshare -Urn\n\nBUG: kernel NULL pointer dereference, address: 00000000000000b6\nPGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop\nReference Platform, BIOS 6.00 11/12/2020\nRIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)

In the Linux kernel, the following vulnerability has been resolved:\nice: fix Rx page leak on multi-buffer frames\nThe ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each\nbuffer in the current frame. This function was introduced as part of\nhandling multi-buffer XDP support in the ice driver.\nIt works by iterating over the buffers from first_desc up to 1 plus the\ntotal number of fragments in the frame, cached from before the XDP program\nwas executed.\nIf the hardware posts a descriptor with a size of 0, the logic used in\nice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added\nas fragments in ice_add_xdp_frag. Since the buffer isn't counted as a\nfragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't\ncall ice_put_rx_buf().\nBecause we don't call ice_put_rx_buf(), we don't attempt to re-use the\npage or free it. This leaves a stale page in the ring, as we don't\nincrement next_to_alloc.\nThe ice_reuse_rx_page() assumes that the next_to_alloc has been incremented\nproperly, and that it always points to a buffer with a NULL page. Since\nthis function doesn't check, it will happily recycle a page over the top\nof the next_to_alloc buffer, losing track of the old page.\nNote that this leak only occurs for multi-buffer frames. The\nice_put_rx_mbuf() function always handles at least one buffer, so a\nsingle-buffer frame will always get handled correctly. It is not clear\nprecisely why the hardware hands us descriptors with a size of 0 sometimes,\nbut it happens somewhat regularly with "jumbo frames" used by 9K MTU.\nTo fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on\nall buffers between first_desc and next_to_clean. Borrow the logic of a\nsimilar function in i40e used for this same purpose. Use the same logic\nalso in ice_get_pgcnts().\nInstead of iterating over just the number of fragments, use a loop which\niterates until the current index reaches to the next_to_clean element just\npast the current frame. Unlike i40e, the ice_put_rx_mbuf() function does\ncall ice_put_rx_buf() on the last buffer of the frame indicating the end of\npacket.\nFor non-linear (multi-buffer) frames, we need to take care when adjusting\nthe pagecnt_bias. An XDP program might release fragments from the tail of\nthe frame, in which case that fragment page is already released. Only\nupdate the pagecnt_bias for the first descriptor and fragments still\nremaining post-XDP program. Take care to only access the shared info for\nfragmented buffers, as this avoids a significant cache miss.\nThe xdp_xmit value only needs to be updated if an XDP program is run, and\nonly once per packet. Drop the xdp_xmit pointer argument from\nice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function\ndirectly. This avoids needing to pass the argument and avoids an extra\nbit-wise OR for each buffer in the frame.\nMove the increment of the ntc local variable to ensure its updated *before*\nall calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic\nrequires the index of the element just after the current frame.\nNow that we use an index pointer in the ring to identify the packet, we no\nlonger need to track or cache the number of fragments in the rx_ring.

In the Linux kernel, the following vulnerability has been resolved:\ntls: make sure to abort the stream if headers are bogus\nNormally we wait for the socket to buffer up the whole record\nbefore we service it. If the socket has a tiny buffer, however,\nwe read out the data sooner, to prevent connection stalls.\nMake sure that we abort the connection when we find out late\nthat the record is actually invalid. Retrying the parsing is\nfine in itself but since we copy some more data each time\nbefore we parse we can overflow the allocated skb space.\nConstructing a scenario in which we're under pressure without\nenough data in the socket to parse the length upfront is quite\nhard. syzbot figured out a way to do this by serving us the header\nin small OOB sends, and then filling in the recvbuf with a large\nnormal send.\nMake sure that tls_rx_msg_size() aborts strp, if we reach\nan invalid record there's really no way to recover.

In the Linux kernel, the following vulnerability has been resolved:\nzram: fix slot write race condition\nParallel concurrent writes to the same zram index result in leaked\nzsmalloc handles. Schematically we can have something like this:\nCPU0 CPU1\nzram_slot_lock()\nzs_free(handle)\nzram_slot_lock()\nzram_slot_lock()\nzs_free(handle)\nzram_slot_lock()\ncompresscompress\nhandle = zs_malloc()handle = zs_malloc()\nzram_slot_lock\nzram_set_handle(handle)\nzram_slot_lock\nzram_slot_lock\nzram_set_handle(handle)\nzram_slot_lock\nEither CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done\ntoo early. In fact, we need to reset zram entry right before we set its\nnew handle, all under the same slot lock scope.

In the Linux kernel, the following vulnerability has been resolved:\niommu/s390: Fix memory corruption when using identity domain\nzpci_get_iommu_ctrs() returns counter information to be reported as part\nof device statistics; these counters are stored as part of the s390_domain.\nThe problem, however, is that the identity domain is not backed by an\ns390_domain and so the conversion via to_s390_domain() yields a bad address\nthat is zero'd initially and read on-demand later via a sysfs read.\nThese counters aren't necessary for the identity domain; just return NULL\nin this case.\nThis issue was discovered via KASAN with reports that look like:\nBUG: KASAN: global-out-of-bounds in zpci_fmb_enable_device\nwhen using the identity domain for a device on s390.

In the Linux kernel, the following vulnerability has been resolved:\ncrypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked()\nWhen\n9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown")\nmoved the error messages dumping so that they don't need to be issued by\nthe callers, it missed the case where __sev_firmware_shutdown() calls\n__sev_platform_shutdown_locked() with a NULL argument which leads to\na NULL ptr deref on the shutdown path, during suspend to disk:\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary)\nHardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022\nRIP: 0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp]\nThat rIP is:\n00000000000006fd <__sev_platform_shutdown_locked.cold>:\n6fd: 8b 13 mov (%rbx),%edx\n6ff: 48 8b 7d 00 mov 0x0(%rbp),%rdi\n703: 89 c1 mov %eax,%ecx\nCode: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e\nRSP: 0018:ffffc90005467d00 EFLAGS: 00010282\nRAX: 00000000ffffff92 RBX: 0000000000000000 RCX: 0000000000000000\n^^^^^^^^^^^^^^^^\nand %rbx is nice and clean.\nCall Trace:\n\n__sev_firmware_shutdown.isra.0\nsev_dev_destroy\npsp_dev_destroy\nsp_destroy\npci_device_shutdown\ndevice_shutdown\nkernel_power_off\nhibernate.cold\nstate_store\nkernfs_fop_write_iter\nvfs_write\nksys_write\ndo_syscall_64\nentry_SYSCALL_64_after_hwframe\nPass in a pointer to the function-local error var in the caller.\nWith that addressed, suspending the ccp shows the error properly at\nleast:\nccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP\nccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110\nSEV-SNP: Leaking PFN range 0x146800-0x146a00\nSEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00]\n...\nccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0\nACPI: PM: Preparing to enter system sleep state S5\nkvm: exiting hardware virtualization\nreboot: Power down\nBtw, this driver is crying to be cleaned up to pass in a proper I/O\nstruct which can be used to store information between the different\nfunctions, otherwise stuff like that will happen in the future again.

In the Linux kernel, the following vulnerability has been resolved:\nASoC: codec: sma1307: Fix memory corruption in sma1307_setting_loaded()\nThe sma1307->set.header_size is how many integers are in the header\n(there are 8 of them) but instead of allocating space of 8 integers\nwe allocate 8 bytes. This leads to memory corruption when we copy data\nit on the next line:\nmemcpy(sma1307->set.header, data,\nsma1307->set.header_size * sizeof(int));\nAlso since we're immediately copying over the memory in ->set.header,\nthere is no need to zero it in the allocator. Use devm_kmalloc_array()\nto allocate the memory instead.

In the Linux kernel, the following vulnerability has been resolved:\ni2c: rtl9300: ensure data length is within supported range\nAdd an explicit check for the xfer length to 'rtl9300_i2c_config_xfer'\nto ensure the data length isn't within the supported range. In\nparticular a data length of 0 is not supported by the hardware and\ncauses unintended or destructive behaviour.\nThis limitation becomes obvious when looking at the register\ndocumentation [1]. 4 bits are reserved for DATA_WIDTH and the value\nof these 4 bits is used as N + 1, allowing a data length range of\n1 <= len <= 16.\nAffected by this is the SMBus Quick Operation which works with a data\nlength of 0. Passing 0 as the length causes an underflow of the value\ndue to:\n(len - 1) & 0xf\nand effectively specifying a transfer length of 16 via the registers.\nThis causes a 16-byte write operation instead of a Quick Write. For\nexample, on SFP modules without write-protected EEPROM this soft-bricks\nthem by overwriting some initial bytes.\nFor completeness, also add a quirk for the zero length.\n[1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2

In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix race condition validating r_parent before applying state\n\nAdd validation to ensure the cached parent directory inode matches the\ndirectory info in MDS replies. This prevents client-side race conditions\nwhere concurrent operations (e.g. rename) cause r_parent to become stale\nbetween request initiation and reply processing, which could lead to\napplying state changes to incorrect directory inodes.\n\n[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to\n move CEPH_CAP_PIN reference when r_parent is updated:\n\n When the parent directory lock is not held, req->r_parent can become\n stale and is updated to point to the correct inode. However, the\n associated CEPH_CAP_PIN reference was not being adjusted. The\n CEPH_CAP_PIN is a reference on an inode that is tracked for\n accounting purposes. Moving this pin is important to keep the\n accounting balanced. When the pin was not moved from the old parent\n to the new one, it created two problems: The reference on the old,\n stale parent was never released, causing a reference leak.\n A reference for the new parent was never acquired, creating the risk\n of a reference underflow later in ceph_mdsc_release_request(). This\n patch corrects the logic by releasing the pin from the old parent and\n acquiring it for the new parent when r_parent is switched. This\n ensures reference accounting stays balanced. ]

In the Linux kernel, the following vulnerability has been resolved:\ngenetlink: fix genl_bind() invoking bind() after -EPERM\nPer family bind/unbind callbacks were introduced to allow families\nto track multicast group consumer presence, e.g. to start or stop\nproducing events depending on listeners.\nHowever, in genl_bind() the bind() callback was invoked even if\ncapability checks failed and ret was set to -EPERM. This means that\ncallbacks could run on behalf of unauthorized callers while the\nsyscall still returned failure to user space.\nFix this by only invoking bind() after "if (ret) break;" check\ni.e. after permission checks have succeeded.

In the Linux kernel, the following vulnerability has been resolved:\nerofs: fix invalid algorithm for encoded extents\nThe current algorithm sanity checks do not properly apply to new\nencoded extents.\nUnify the algorithm check with Z_EROFS_COMPRESSION(_RUNTIME)_MAX\nand ensure consistency with sbi->available_compr_algs.

In the Linux kernel, the following vulnerability has been resolved:\nixgbe: fix incorrect map used in eee linkmode\nincorrectly used ixgbe_lp_map in loops intended to populate the\nsupported and advertised EEE linkmode bitmaps based on ixgbe_ls_map.\nThis results in incorrect bit setting and potential out-of-bounds\naccess, since ixgbe_lp_map and ixgbe_ls_map have different sizes\nand purposes.\nixgbe_lp_map[i] -> ixgbe_ls_map[i]\nUse ixgbe_ls_map for supported and advertised linkmodes, and keep\nixgbe_lp_map usage only for link partner (lp_advertised) mapping.

In the Linux kernel, the following vulnerability has been resolved:\nspi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback\nIn commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem\noperation frequency switches") the logic for checking the viability of\nop->max_freq in mchp_coreqspi_setup_clock() was copied into\nmchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid\nwhen this function is called during probe but is instead zero.\nAccordingly, baud_rate_val is calculated to be INT_MAX due to division\nby zero, causing probe of the attached memory device to fail.\nSeemingly spi-microchip-core-qspi was the only driver that had such a\nmodification made to its supports_op callback when the per_op_freq\ncapability was added, so just remove it to restore prior functionality.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mt76: mt7996: add missing check for rx wcid entries\nNon-station wcid entries must not be passed to the rx functions.\nIn case of the global wcid entry, it could even lead to corruption in the wcid\narray due to pointer being casted to struct mt7996_sta_link using container_of.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mt76: fix linked list corruption\nNever leave scheduled wcid entries on the temporary on-stack list

In the Linux kernel, the following vulnerability has been resolved:\nbpf: Fix out-of-bounds dynptr write in bpf_crypto_crypt\nStanislav reported that in bpf_crypto_crypt() the destination dynptr's\nsize is not validated to be at least as large as the source dynptr's\nsize before calling into the crypto backend with 'len = src_len'. This\ncan result in an OOB write when the destination is smaller than the\nsource.\nConcretely, in mentioned function, psrc and pdst are both linear\nbuffers fetched from each dynptr:\npsrc = __bpf_dynptr_data(src, src_len);\n[...]\npdst = __bpf_dynptr_data_rw(dst, dst_len);\n[...]\nerr = decrypt ?\nctx->type->decrypt(ctx->tfm, psrc, pdst, src_len, piv) :\nctx->type->encrypt(ctx->tfm, psrc, pdst, src_len, piv);\nThe crypto backend expects pdst to be large enough with a src_len length\nthat can be written. Add an additional src_len > dst_len check and bail\nout if it's the case. Note that these kfuncs are accessible under root\nprivileges only.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfs/localio: restore creds before releasing pageio data\n\nOtherwise if the nfsd filecache code releases the nfsd_file\nimmediately, it can trigger the BUG_ON(cred == current->cred) in\n__put_cred() when it puts the nfsd_file->nf_file->f-cred.

In the Linux kernel, the following vulnerability has been resolved:\nnet: dev_ioctl: take ops lock in hwtstamp lower paths\nndo hwtstamp callbacks are expected to run under the per-device ops\nlock. Make the lower get/set paths consistent with the rest of ndo\ninvocations.\nKernel log:\nWARNING: CPU: 13 PID: 51364 at ./include/net/netdev_lock.h:70 __netdev_update_features+0x4bd/0xe60\n...\nRIP: 0010:__netdev_update_features+0x4bd/0xe60\n...\nCall Trace:\n\nnetdev_update_features+0x1f/0x60\nmlx5_hwtstamp_set+0x181/0x290 [mlx5_core]\nmlx5e_hwtstamp_set+0x19/0x30 [mlx5_core]\ndev_set_hwtstamp_phylib+0x9f/0x220\ndev_set_hwtstamp_phylib+0x9f/0x220\ndev_set_hwtstamp+0x13d/0x240\ndev_ioctl+0x12f/0x4b0\nsock_ioctl+0x171/0x370\n__x64_sys_ioctl+0x3f7/0x900\n? __sys_setsockopt+0x69/0xb0\ndo_syscall_64+0x6f/0x2e0\nentry_SYSCALL_64_after_hwframe+0x4b/0x53\n...\n\n....\n---[ end trace 0000000000000000 ]---\nNote that the mlx5_hwtstamp_set and mlx5e_hwtstamp_set functions shown\nin the trace come from an in progress patch converting the legacy ioctl\nto ndo_hwtstamp_get/set and are not present in mainline.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/amd/display: remove oem i2c adapter on finish\nFixes a bug where unbinding of the GPU would leave the oem i2c adapter\nregistered resulting in a null pointer dereference when applications try\nto access the invalid device.\n(cherry picked from commit 89923fb7ead4fdd37b78dd49962d9bb5892403e6)

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phylink: add lock for serializing concurrent pl->phydev writes with resolver\n\nCurrently phylink_resolve() protects itself against concurrent\nphylink_bringup_phy() or phylink_disconnect_phy() calls which modify\npl->phydev by relying on pl->state_mutex.\n\nThe problem is that in phylink_resolve(), pl->state_mutex is in a lock\ninversion state with pl->phydev->lock. So pl->phydev->lock needs to be\nacquired prior to pl->state_mutex. But that requires dereferencing\npl->phydev in the first place, and without pl->state_mutex, that is\nracy.\n\nHence the reason for the extra lock. Currently it is redundant, but it\nwill serve a functional purpose once mutex_lock(&phy->lock) will be\nmoved outside of the mutex_lock(&pl->state_mutex) section.\n\nAnother alternative considered would have been to let phylink_resolve()\nacquire the rtnl_mutex, which is also held when phylink_bringup_phy()\nand phylink_disconnect_phy() are called. But since phylink_disconnect_phy()\nruns under rtnl_lock(), it would deadlock with phylink_resolve() when\ncalling flush_work(&pl->resolve). Additionally, it would have been\nundesirable because it would have unnecessarily blocked many other call\npaths as well in the entire kernel, so the smaller-scoped lock was\npreferred.

In the Linux kernel, the following vulnerability has been resolved:\narm64: kexec: initialize kexec_buf struct in load_other_segments()\nPatch series "kexec: Fix invalid field access".\nThe kexec_buf structure was previously declared without initialization. \ncommit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")\nadded a field that is always read but not consistently populated by all\narchitectures. This un-initialized field will contain garbage.\nThis is also triggering a UBSAN warning when the uninitialized data was\naccessed:\n------------[ cut here ]------------\nUBSAN: invalid-load in ./include/linux/kexec.h:210:10\nload of value 252 is not a valid value for type '_Bool'\nZero-initializing kexec_buf at declaration ensures all fields are cleanly\nset, preventing future instances of uninitialized memory being used.\nAn initial fix was already landed for arm64[0], and this patchset fixes\nthe problem on the remaining arm64 code and on riscv, as raised by Mark.\nDiscussions about this problem could be found at[1][2].\nThis patch (of 3):\nThe kexec_buf structure was previously declared without initialization.\ncommit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")\nadded a field that is always read but not consistently populated by all\narchitectures. This un-initialized field will contain garbage.\nThis is also triggering a UBSAN warning when the uninitialized data was\naccessed:\n------------[ cut here ]------------\nUBSAN: invalid-load in ./include/linux/kexec.h:210:10\nload of value 252 is not a valid value for type '_Bool'\nZero-initializing kexec_buf at declaration ensures all fields are\ncleanly set, preventing future instances of uninitialized memory being\nused.

In the Linux kernel, the following vulnerability has been resolved:\nof_numa: fix uninitialized memory nodes causing kernel panic\nWhen there are memory-only nodes (nodes without CPUs), these nodes are not\nproperly initialized, causing kernel panic during boot.\nof_numa_init\nof_numa_parse_cpu_nodes\nnode_set(nid, numa_nodes_parsed);\nof_numa_parse_memory_nodes\nIn of_numa_parse_cpu_nodes, numa_nodes_parsed gets updated only for nodes\ncontaining CPUs. Memory-only nodes should have been updated in\nof_numa_parse_memory_nodes, but they weren't.\nSubsequently, when free_area_init() attempts to access NODE_DATA() for\nthese uninitialized memory nodes, the kernel panics due to NULL pointer\ndereference.\nThis can be reproduced on ARM64 QEMU with 1 CPU and 2 memory nodes:\nqemu-system-aarch64 \\\n-cpu host -nographic \\\n-m 4G -smp 1 \\\n-machine virt,accel=kvm,gic-version=3,iommu=smmuv3 \\\n-object memory-backend-ram,size=2G,id=mem0 \\\n-object memory-backend-ram,size=2G,id=mem1 \\\n-numa node,nodeid=0,memdev=mem0 \\\n-numa node,nodeid=1,memdev=mem1 \\\n-kernel $IMAGE \\\n-hda $DISK \\\n-append "console=ttyAMA0 root=/dev/vda rw earlycon"\n[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x481fd010]\n[ 0.000000] Linux version 6.17.0-rc1-00001-gabb4b3daf18c-dirty (yintirui@local) (gcc (GCC) 12.3.1, GNU ld (GNU Binutils) 2.41) #52 SMP PREEMPT Mon Aug 18 09:49:40 CST 2025\n[ 0.000000] KASLR enabled\n[ 0.000000] random: crng init done\n[ 0.000000] Machine model: linux,dummy-virt\n[ 0.000000] efi: UEFI not found.\n[ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options '')\n[ 0.000000] printk: legacy bootconsole [pl11] enabled\n[ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT\n[ 0.000000] NODE_DATA(0) allocated [mem 0xbfffd9c0-0xbfffffff]\n[ 0.000000] node 1 must be removed before remove section 23\n[ 0.000000] Zone ranges:\n[ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff]\n[ 0.000000] DMA32 empty\n[ 0.000000] Normal [mem 0x0000000100000000-0x000000013fffffff]\n[ 0.000000] Movable zone start for each node\n[ 0.000000] Early memory node ranges\n[ 0.000000] node 0: [mem 0x0000000040000000-0x00000000bfffffff]\n[ 0.000000] node 1: [mem 0x00000000c0000000-0x000000013fffffff]\n[ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff]\n[ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0\n[ 0.000000] Mem abort info:\n[ 0.000000] ESR = 0x0000000096000004\n[ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 0.000000] SET = 0, FnV = 0\n[ 0.000000] EA = 0, S1PTW = 0\n[ 0.000000] FSC = 0x04: level 0 translation fault\n[ 0.000000] Data abort info:\n[ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 0.000000] [00000000000000a0] user address but active_mm is swapper\n[ 0.000000] Internal error: Oops: 0000000096000004 [#1] SMP\n[ 0.000000] Modules linked in:\n[ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc1-00001-g760c6dabf762-dirty #54 PREEMPT\n[ 0.000000] Hardware name: linux,dummy-virt (DT)\n[ 0.000000] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 0.000000] pc : free_area_init+0x50c/0xf9c\n[ 0.000000] lr : free_area_init+0x5c0/0xf9c\n[ 0.000000] sp : ffffa02ca0f33c00\n[ 0.000000] x29: ffffa02ca0f33cb0 x28: 0000000000000000 x27: 0000000000000000\n[ 0.000000] x26: 4ec4ec4ec4ec4ec5 x25: 00000000000c0000 x24: 00000000000c0000\n[ 0.000000] x23: 0000000000040000 x22: 0000000000000000 x21: ffffa02ca0f3b368\n[ 0.000000] x20: ffffa02ca14c7b98 x19: 0000000000000000 x18: 0000000000000002\n[ 0.000000] x17: 000000000000cacc x16: 0000000000000001 x15: 0000000000000001\n[ 0.000000] x14: 0000000080000000 x13: 0000000000000018 x12: 0000000000000002\n[ 0.0\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nnet_sched: gen_estimator: fix est_timer() vs CONFIG_PREEMPT_RT=y\nsyzbot reported a WARNING in est_timer() [1]\nProblem here is that with CONFIG_PREEMPT_RT=y, timer callbacks\ncan be preempted.\nAdopt preempt_disable_nested()/preempt_enable_nested() to fix this.\n[1]\nWARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 __seqprop_assert include/linux/seqlock.h:221 [inline]\nWARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93\nModules linked in:\nCPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #0 PREEMPT_{RT,(full)}\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:__seqprop_assert include/linux/seqlock.h:221 [inline]\nRIP: 0010:est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93\nCall Trace:\n\ncall_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747\nexpire_timers kernel/time/timer.c:1798 [inline]\n__run_timers kernel/time/timer.c:2372 [inline]\n__run_timer_base+0x648/0x970 kernel/time/timer.c:2384\nrun_timer_base kernel/time/timer.c:2393 [inline]\nrun_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403\nhandle_softirqs+0x22c/0x710 kernel/softirq.c:579\n__do_softirq kernel/softirq.c:613 [inline]\nrun_ktimerd+0xcf/0x190 kernel/softirq.c:1043\nsmpboot_thread_fn+0x53f/0xa60 kernel/smpboot.c:160\nkthread+0x70e/0x8a0 kernel/kthread.c:463\nret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\nret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n

In the Linux kernel, the following vulnerability has been resolved:\nmm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE\nWith CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using\nkmap_local_page(), which requires unmapping in Last-In-First-Out order.\nThe current code maps dst_pte first, then src_pte, but unmaps them in the\nsame order (dst_pte, src_pte), violating the LIFO requirement. This\ncauses the warning in kunmap_local_indexed():\nWARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c\naddr \\!= __fix_to_virt(FIX_KMAP_BEGIN + idx)\nFix this by reversing the unmap order to respect LIFO ordering.\nThis issue follows the same pattern as similar fixes:\n- commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order")\n- commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfs_rename")\nBoth of which addressed the same fundamental requirement that kmap_local\noperations must follow LIFO ordering.

In the Linux kernel, the following vulnerability has been resolved:\ne1000e: fix heap overflow in e1000_set_eeprom\nFix a possible heap overflow in e1000_set_eeprom function by adding\ninput validation for the requested length of the change in the EEPROM.\nIn addition, change the variable type from int to size_t for better\ncode practices and rearrange declarations to RCT.

In the Linux kernel, the following vulnerability has been resolved:\nnet: xilinx: axienet: Add error handling for RX metadata pointer retrieval\nAdd proper error checking for dmaengine_desc_get_metadata_ptr() which\ncan return an error pointer and lead to potential crashes or undefined\nbehaviour if the pointer retrieval fails.\nProperly handle the error by unmapping DMA buffer, freeing the skb and\nreturning early to prevent further processing with invalid data.

In the Linux kernel, the following vulnerability has been resolved:\naccel/ivpu: Prevent recovery work from being queued during device removal\nUse disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini()\nto ensure that no new recovery work items can be queued after device\nremoval has started. Previously, recovery work could be scheduled even\nafter canceling existing work, potentially leading to use-after-free\nbugs if recovery accessed freed resources.\nRename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to better\nreflect its new behavior.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm\nWhen send a broadcast packet to a tap device, which was added to a bridge,\nbr_nf_local_in() is called to confirm the conntrack. If another conntrack\nwith the same hash value is added to the hash table, which can be\ntriggered by a normal packet to a non-bridge device, the below warning\nmay happen.\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200\nCPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary)\nRIP: 0010:br_nf_local_in+0x168/0x200\nCall Trace:\n\nnf_hook_slow+0x3e/0xf0\nbr_pass_frame_up+0x103/0x180\nbr_handle_frame_finish+0x2de/0x5b0\nbr_nf_hook_thresh+0xc0/0x120\nbr_nf_pre_routing_finish+0x168/0x3a0\nbr_nf_pre_routing+0x237/0x5e0\nbr_handle_frame+0x1ec/0x3c0\n__netif_receive_skb_core+0x225/0x1210\n__netif_receive_skb_one_core+0x37/0xa0\nnetif_receive_skb+0x36/0x160\ntun_get_user+0xa54/0x10c0\ntun_chr_write_iter+0x65/0xb0\nvfs_write+0x305/0x410\nksys_write+0x60/0xd0\ndo_syscall_64+0xa4/0x260\nentry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n---[ end trace 0000000000000000 ]---\nTo solve the hash conflict, nf_ct_resolve_clash() try to merge the\nconntracks, and update skb->_nfct. However, br_nf_local_in() still use the\nold ct from local variable 'nfct' after confirm(), which leads to this\nwarning.\nIf confirm() does not insert the conntrack entry and return NF_DROP, the\nwarning may also occur. There is no need to reserve the WARN_ON_ONCE, just\nremove it.

In the Linux kernel, the following vulnerability has been resolved:\nspi: spi-qpic-snand: unregister ECC engine on probe error and device remove\nThe on-host hardware ECC engine remains registered both when\nthe spi_register_controller() function returns with an error\nand also on device removal.\nChange the qcom_spi_probe() function to unregister the engine\non the error path, and add the missing unregistering call to\nqcom_spi_remove() to avoid possible use-after-free issues.

In the Linux kernel, the following vulnerability has been resolved:\nASoC: soc-core: care NULL dirver name on snd_soc_lookup_component_nolocked()\nsoc-generic-dmaengine-pcm.c uses same dev for both CPU and Platform.\nIn such case, CPU component driver might not have driver->name, then\nsnd_soc_lookup_component_nolocked() will be NULL pointer access error.\nCare NULL driver name.\nCall trace:\nstrcmp from snd_soc_lookup_component_nolocked+0x64/0xa4\nsnd_soc_lookup_component_nolocked from snd_soc_unregister_component_by_driver+0x2c/0x44\nsnd_soc_unregister_component_by_driver from snd_dmaengine_pcm_unregister+0x28/0x64\nsnd_dmaengine_pcm_unregister from devres_release_all+0x98/0xfc\ndevres_release_all from device_unbind_cleanup+0xc/0x60\ndevice_unbind_cleanup from really_probe+0x220/0x2c8\nreally_probe from __driver_probe_device+0x88/0x1a0\n__driver_probe_device from driver_probe_device+0x30/0x110\ndriver_probe_device from __driver_attach+0x90/0x178\n__driver_attach from bus_for_each_dev+0x7c/0xcc\nbus_for_each_dev from bus_add_driver+0xcc/0x1ec\nbus_add_driver from driver_register+0x80/0x11c\ndriver_register from do_one_initcall+0x58/0x23c\ndo_one_initcall from kernel_init_freeable+0x198/0x1f4\nkernel_init_freeable from kernel_init+0x1c/0x12c\nkernel_init from ret_from_fork+0x14/0x28

FFmpeg git master before commit c08d30 was discovered to contain a NULL pointer dereference via the component libavformat/mov.c.

FFmpeg git-master before commit d5873b was discovered to contain a memory leak in the component libavutil/iamf.c.

A vulnerability was found in FFmpeg up to 7.1. It has been rated as problematic. Affected by this issue is the function mov_read_trak of the file libavformat/mov.c of the component MOV Parser. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The patch is identified as 43be8d07281caca2e88bfd8ee2333633e1fb1a13. It is recommended to apply a patch to fix this issue.

A flaw was found in QEMU. If the QIOChannelWebsock object is freed while it is waiting to complete a handshake, a GSource is leaked. This can lead to the callback firing later on and triggering a use-after-free in the use of the channel. This can be abused by a malicious client with network access to the VNC WebSocket port to cause a denial of service during the WebSocket handshake prior to the VNC client authentication.

This vulnerability affects Firefox < 143.0.3.

This vulnerability affects Firefox < 143.0.3.

A flaw was found in the cookie date handling logic of the libsoup HTTP library, widely used by GNOME and other applications for web communication. When processing cookies with specially crafted expiration dates, the library may perform an out-of-bounds memory read. This flaw could result in unintended disclosure of memory contents, potentially exposing sensitive information from the process using libsoup.

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.