In the Linux kernel, the following vulnerability has been resolved:\n\ns390/pkey: Prevent overflow in size calculation for memdup_user()\n\nNumber of apqn target list entries contained in 'nr_apqns' variable is\ndetermined by userspace via an ioctl call so the result of the product in\ncalculation of size passed to memdup_user() may overflow.\n\nIn this case the actual size of the allocated area and the value\ndescribing it won't be in sync leading to various types of unpredictable\nbehaviour later.\n\nUse a proper memdup_array_user() helper which returns an error if an\noverflow is detected. Note that it is different from when nr_apqns is\ninitially zero - that case is considered valid and should be handled in\nsubsequent pkey_handler implementations.\n\nFound by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/rsrc: fix folio unpinning\n\nsyzbot complains about an unmapping failure:\n\n[ 108.070381][ T14] kernel BUG at mm/gup.c:71!\n[ 108.070502][ T14] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025\n[ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work\n[ 108.174205][ T14] Call trace:\n[ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P)\n[ 108.178138][ T14] unpin_user_page+0x80/0x10c\n[ 108.180189][ T14] io_release_ubuf+0x84/0xf8\n[ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c\n[ 108.184345][ T14] io_rsrc_data_free+0x148/0x298\n[ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0\n[ 108.188991][ T14] io_ring_ctx_free+0x48/0x480\n[ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8\n[ 108.193207][ T14] process_one_work+0x7e8/0x155c\n[ 108.195431][ T14] worker_thread+0x958/0xed8\n[ 108.197561][ T14] kthread+0x5fc/0x75c\n[ 108.199362][ T14] ret_from_fork+0x10/0x20\n\nWe can pin a tail page of a folio, but then io_uring will try to unpin\nthe head page of the folio. While it should be fine in terms of keeping\nthe page actually alive, mm folks say it's wrong and triggers a debug\nwarning. Use unpin_user_folio() instead of unpin_user_page*.\n\n[axboe: adapt to current tree, massage commit message]

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add sanity checks for drm_edid_raw()\n\nWhen EDID is retrieved via drm_edid_raw(), it doesn't guarantee to\nreturn proper EDID bytes the caller wants: it may be either NULL (that\nleads to an Oops) or with too long bytes over the fixed size raw_edid\narray (that may lead to memory corruption). The latter was reported\nactually when connected with a bad adapter.\n\nAdd sanity checks for drm_edid_raw() to address the above corner\ncases, and return EDID_BAD_INPUT accordingly.\n\n(cherry picked from commit 648d3f4d209725d51900d6a3ed46b7b600140cdf)

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: wacom: fix crash in wacom_aes_battery_handler()\n\nCommit fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extended\ninactivity") introduced wacom_aes_battery_handler() which is scheduled\nas a delayed work (aes_battery_work).\n\nIn wacom_remove(), aes_battery_work is not canceled. Consequently, if\nthe device is removed while aes_battery_work is still pending, then hard\ncrashes or "Oops: general protection fault..." are experienced when\nwacom_aes_battery_handler() is finally called. E.g., this happens with\nbuilt-in USB devices after resume from hibernate when aes_battery_work\nwas still pending at the time of hibernation.\n\nSo, take care to cancel aes_battery_work in wacom_remove().

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/ras: Fix CPER handler device confusion\n\nBy inspection, cxl_cper_handle_prot_err() is making a series of fragile\nassumptions that can lead to crashes:\n\n1/ It assumes that endpoints identified in the record are a CXL-type-3\n device, nothing guarantees that.\n\n2/ It assumes that the device is bound to the cxl_pci driver, nothing\n guarantees that.\n\n3/ Minor, it holds the device lock over the switch-port tracing for no\n reason as the trace is 100% generated from data in the record.\n\nCorrect those by checking that the PCIe endpoint parents a cxl_memdev\nbefore assuming the format of the driver data, and move the lock to where\nit is required. Consequently this also makes the implementation ready for\nCXL accelerators that are not bound to cxl_pci.

In the Linux kernel, the following vulnerability has been resolved:\n\nuserns and mnt_idmap leak in open_tree_attr(2)\n\nOnce want_mount_setattr() has returned a positive, it does require\nfinish_mount_kattr() to release ->mnt_userns. Failing do_mount_setattr()\ndoes not change that.\n\nAs the result, we can end up leaking userns and possibly mnt_idmap as\nwell.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix invalid inode pointer dereferences during log replay\n\nIn a few places where we call read_one_inode(), if we get a NULL pointer\nwe end up jumping into an error path, or fallthrough in case of\n__add_inode_ref(), where we then do something like this:\n\n iput(&inode->vfs_inode);\n\nwhich results in an invalid inode pointer that triggers an invalid memory\naccess, resulting in a crash.\n\nFix this by making sure we don't do such dereferences.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: userfaultfd: fix race of userfaultfd_move and swap cache\n\nThis commit fixes two kinds of races, they may have different results:\n\nBarry reported a BUG_ON in commit c50f8e6053b0, we may see the same\nBUG_ON if the filemap lookup returned NULL and folio is added to swap\ncache after that.\n\nIf another kind of race is triggered (folio changed after lookup) we\nmay see RSS counter is corrupted:\n\n[ 406.893936] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0\ntype:MM_ANONPAGES val:-1\n[ 406.894071] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0\ntype:MM_SHMEMPAGES val:1\n\nBecause the folio is being accounted to the wrong VMA.\n\nI'm not sure if there will be any data corruption though, seems no. \nThe issues above are critical already.\n\n\nOn seeing a swap entry PTE, userfaultfd_move does a lockless swap cache\nlookup, and tries to move the found folio to the faulting vma. Currently,\nit relies on checking the PTE value to ensure that the moved folio still\nbelongs to the src swap entry and that no new folio has been added to the\nswap cache, which turns out to be unreliable.\n\nWhile working and reviewing the swap table series with Barry, following\nexisting races are observed and reproduced [1]:\n\nIn the example below, move_pages_pte is moving src_pte to dst_pte, where\nsrc_pte is a swap entry PTE holding swap entry S1, and S1 is not in the\nswap cache:\n\nCPU1 CPU2\nuserfaultfd_move\n move_pages_pte()\n entry = pte_to_swp_entry(orig_src_pte);\n // Here it got entry = S1\n ... < interrupted> ...\n \n // folio A is a new allocated folio\n // and get installed into src_pte\n \n // src_pte now points to folio A, S1\n // has swap count == 0, it can be freed\n // by folio_swap_swap or swap\n // allocator's reclaim.\n \n // folio B is a folio in another VMA.\n \n // S1 is freed, folio B can use it\n // for swap out with no problem.\n ...\n folio = filemap_get_folio(S1)\n // Got folio B here !!!\n ... < interrupted again> ...\n \n // Now S1 is free to be used again.\n \n // Now src_pte is a swap entry PTE\n // holding S1 again.\n folio_trylock(folio)\n move_swap_pte\n double_pt_lock\n is_pte_pages_stable\n // Check passed because src_pte == S1\n folio_move_anon_rmap(...)\n // Moved invalid folio B here !!!\n\nThe race window is very short and requires multiple collisions of multiple\nrare events, so it's very unlikely to happen, but with a deliberately\nconstructed reproducer and increased time window, it can be reproduced\neasily.\n\nThis can be fixed by checking if the folio returned by filemap is the\nvalid swap cache folio after acquiring the folio lock.\n\nAnother similar race is possible: filemap_get_folio may return NULL, but\nfolio (A) could be swapped in and then swapped out again using the same\nswap entry after the lookup. In such a case, folio (A) may remain in the\nswap cache, so it must be moved too:\n\nCPU1 CPU2\nuserfaultfd_move\n move_pages_pte()\n entry = pte_to_swp_entry(orig_src_pte);\n // Here it got entry = S1, and S1 is not in swap cache\n folio = filemap_get\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/shmem, swap: fix softlockup with mTHP swapin\n\nFollowing softlockup can be easily reproduced on my test machine with:\n\necho always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled\nswapon /dev/zram0 # zram0 is a 48G swap device\nmkdir -p /sys/fs/cgroup/memory/test\necho 1G > /sys/fs/cgroup/test/memory.max\necho $BASHPID > /sys/fs/cgroup/test/cgroup.procs\nwhile true; do\n dd if=/dev/zero of=/tmp/test.img bs=1M count=5120\n cat /tmp/test.img > /dev/null\n rm /tmp/test.img\ndone\n\nThen after a while:\nwatchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]\nModules linked in: zram virtiofs\nCPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)·\nTainted: [L]=SOFTLOCKUP\nHardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015\nRIP: 0010:mpol_shared_policy_lookup+0xd/0x70\nCode: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8\nRSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202\nRAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001\nRDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518\nRBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001\nR13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000\nFS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \n shmem_alloc_folio+0x31/0xc0\n shmem_swapin_folio+0x309/0xcf0\n ? filemap_get_entry+0x117/0x1e0\n ? xas_load+0xd/0xb0\n ? filemap_get_entry+0x101/0x1e0\n shmem_get_folio_gfp+0x2ed/0x5b0\n shmem_file_read_iter+0x7f/0x2e0\n vfs_read+0x252/0x330\n ksys_read+0x68/0xf0\n do_syscall_64+0x4c/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f03f9a46991\nCode: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\nRSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991\nRDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003\nRBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\nR13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000\n \n\nThe reason is simple, readahead brought some order 0 folio in swap cache,\nand the swapin mTHP folio being allocated is in conflict with it, so\nswapcache_prepare fails and causes shmem_swap_alloc_folio to return\n-EEXIST, and shmem simply retries again and again causing this loop.\n\nFix it by applying a similar fix for anon mTHP swapin.\n\nThe performance change is very slight, time of swapin 10g zero folios\nwith shmem (test for 12 times):\nBefore: 2.47s\nAfter: 2.48s\n\n[kasong@tencent.com: add comment]

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out\n\nWhen both the RHBA and RPA FDMI requests time out, fnic reuses a frame to\nsend ABTS for each of them. On send completion, this causes an attempt to\nfree the same frame twice that leads to a crash.\n\nFix crash by allocating separate frames for RHBA and RPA, and modify ABTS\nlogic accordingly.\n\nTested by checking MDS for FDMI information.\n\nTested by using instrumented driver to:\n\n - Drop PLOGI response\n - Drop RHBA response\n - Drop RPA response\n - Drop RHBA and RPA response\n - Drop PLOGI response + ABTS response\n - Drop RHBA response + ABTS response\n - Drop RPA response + ABTS response\n - Drop RHBA and RPA response + ABTS response for both of them

In the Linux kernel, the following vulnerability has been resolved:\nLoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()\nERROR INFO:\nCPU 25 Unable to handle kernel paging request at virtual address 0x0\n...\nCall Trace:\n[<900000000023c30c>] huge_pte_offset+0x3c/0x58\n[<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438\n[<900000000051fee8>] __get_user_pages+0xe0/0x4c8\n[<9000000000522414>] faultin_page_range+0x84/0x380\n[<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48\n[<900000000056689c>] do_madvise+0x1bc/0x3e8\n[<9000000000566df4>] sys_madvise+0x24/0x38\n[<90000000015b9e88>] do_syscall+0x78/0x98\n[<9000000000221f18>] handle_syscall+0xb8/0x158\nIn some cases, pmd may be NULL and rely on NULL as the return value for\nprocessing, so it is necessary to determine this situation here.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

Gitk is a Tcl/Tk based Git history browser. Starting with 1.7.0, when a user clones an untrusted repository and runs gitk without additional command arguments, files for which the user has write permission can be created and truncated. The option Support per-file encoding must have been enabled before in Gitk's Preferences. This option is disabled by default. The same happens when Show origin of this line is used in the main window (regardless of whether Support per-file encoding is enabled or not). This vulnerability is fixed in 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1, and 2.50.1.

LuaJIT through 2.1 has an out-of-bounds read in the stack-overflow handler in lj_state.c

LuaJIT through 2.1 has a stack-buffer-overflow in lj_strfmt_wfnum in lj_strfmt_num.c.

A buffer overflow vulnerability has been identified in the Linux kernel's Common Internet File System (CIFS) module, specifically within the parse_mf_symlink() function. This flaw is caused by insufficient input validation on the link_len value, which dictates the length of a symbolic link. An attacker could exploit this issue by providing an overly large symlink string, leading to a buffer overflow. This can result in memory corruption, system instability, or a denial-of-service condition.

No description is available for this CVE.

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When cloning a repository Git knows to optionally fetch a bundle advertised by the remote server, which allows the server-side to offload parts of the clone to a CDN. The Git client does not perform sufficient validation of the advertised bundles, which allows the remote side to perform protocol injection. This protocol injection can cause the client to write the fetched bundle to a location controlled by the adversary. The fetched content is fully controlled by the server, which can in the worst case lead to arbitrary code execution. The use of bundle URIs is not enabled by default and can be controlled by the bundle.heuristic config option. Some cases of the vulnerability require that the adversary is in control of where a repository will be cloned to. This either requires social engineering or a recursive clone with submodules. These cases can thus be avoided by disabling recursive clones. This vulnerability is fixed in v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When reading a config value, Git strips any trailing carriage return and line feed (CRLF). When writing a config entry, values with a trailing CR are not quoted, causing the CR to be lost when the config is later read. When initializing a submodule, if the submodule path contains a trailing CR, the altered path is read resulting in the submodule being checked out to an incorrect location. If a symlink exists that points the altered path to the submodule hooks directory, and the submodule contains an executable post-checkout hook, the script may be unintentionally executed after checkout. This vulnerability is fixed in v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.

containerd is an open-source container runtime. A bug was found in the containerd's CRI implementation where containerd, starting in version 2.0.1 and prior to version 2.0.5, doesn't put usernamespaced containers under the Kubernetes' cgroup hierarchy, therefore some Kubernetes limits are not honored. This may cause a denial of service of the Kubernetes node. This bug has been fixed in containerd 2.0.5+ and 2.1.0+. Users should update to these versions to resolve the issue. As a workaround, disable usernamespaced pods in Kubernetes temporarily.

在 Linux 内核的 net/unix/af_unix.c 模块中发现了一个 Use-After-Free 漏洞。该漏洞位于 unix_stream_recv_urg() 及相关数据读取路径中。当 AF_UNIX 套接字处理连续的 MSG_OOB 消息时，内核未能正确管理已消费 OOB 数据包的生命周期，导致悬空指针的产生。本地非特权用户可利用此漏洞破坏内核内存，导致系统拒绝服务或提升权限。

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

Redis is an open source, in-memory database that persists on disk. An unauthenticated connection can cause repeated IP protocol errors, leading to client starvation and, ultimately, a denial of service. This vulnerability is fixed in 8.0.3, 7.4.5, 7.2.10, and 6.2.19.

In multispectral MIFF image processing in ImageMagick before 7.1.1-44, packet_size is mishandled (related to the rendering of all channels in an arbitrary order).

In MIFF image processing in ImageMagick before 7.1.1-44, image depth is mishandled after SetQuantumFormat is used.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\nmedia: imagination: fix a potential memory leak in e5010_probe()\nAdd video_device_release() to release the memory allocated by\nvideo_device_alloc() if something goes wrong.

In the Linux kernel, the following vulnerability has been resolved:\ncan: kvaser_pciefd: refine error prone echo_skb_max handling logic\necho_skb_max should define the supported upper limit of echo_skb[]\nallocated inside the netdevice's priv. The corresponding size value\nprovided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNT\nwhich is 17.\nBut later echo_skb_max is rounded up to the nearest power of two (for the\nmax case, that would be 32) and the tx/ack indices calculated further\nduring tx/rx may exceed the upper array boundary. Kasan reported this for\nthe ack case inside kvaser_pciefd_handle_ack_packet(), though the xmit\nfunction has actually caught the same thing earlier.\nBUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528\nRead of size 8 at addr ffff888105e4f078 by task swapper/4/0\nCPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary)\nCall Trace:\n\ndump_stack_lvl lib/dump_stack.c:122\nprint_report mm/kasan/report.c:521\nkasan_report mm/kasan/report.c:634\nkvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528\nkvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605\nkvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656\nkvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684\nkvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733\n__handle_irq_event_percpu kernel/irq/handle.c:158\nhandle_irq_event kernel/irq/handle.c:210\nhandle_edge_irq kernel/irq/chip.c:833\n__common_interrupt arch/x86/kernel/irq.c:296\ncommon_interrupt arch/x86/kernel/irq.c:286\n\nTx max count definitely matters for kvaser_pciefd_tx_avail(), but for seq\nnumbers' generation that's not the case - we're free to calculate them as\nwould be more convenient, not taking tx max count into account. The only\ndownside is that the size of echo_skb[] should correspond to the max seq\nnumber (not tx max count), so in some situations a bit more memory would\nbe consumed than could be.\nThus make the size of the underlying echo_skb[] sufficient for the rounded\nmax tx value.\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:\niommu/vt-d: Restore context entry setup order for aliased devices\nCommit 2031c469f816 ("iommu/vt-d: Add support for static identity domain")\nchanged the context entry setup during domain attachment from a\nset-and-check policy to a clear-and-reset approach. This inadvertently\nintroduced a regression affecting PCI aliased devices behind PCIe-to-PCI\nbridges.\nSpecifically, keyboard and touchpad stopped working on several Apple\nMacbooks with below messages:\nkernel: platform pxa2xx-spi.3: Adding to iommu group 20\nkernel: input: Apple SPI Keyboard as\n/devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spi_master/spi2/spi-APP000D:00/input/input0\nkernel: DMAR: DRHD: handling fault status reg 3\nkernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr\n0xffffa000 [fault reason 0x06] PTE Read access is not set\nkernel: DMAR: DRHD: handling fault status reg 3\nkernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr\n0xffffa000 [fault reason 0x06] PTE Read access is not set\nkernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00\nkernel: DMAR: DRHD: handling fault status reg 3\nkernel: DMAR: [DMA Read NO_PASID] Request device [00:1e.3] fault addr\n0xffffa000 [fault reason 0x06] PTE Read access is not set\nkernel: DMAR: DRHD: handling fault status reg 3\nkernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00\nFix this by restoring the previous context setup order.

In the Linux kernel, the following vulnerability has been resolved:\nnvme-tcp: remove tag set when second admin queue config fails\nCommit 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure\nconcatenation") modified nvme_tcp_setup_ctrl() to call\nnvme_tcp_configure_admin_queue() twice. The first call prepares for\nDH-CHAP negotitation, and the second call is required for secure\nconcatenation. However, this change triggered BUG KASAN slab-use-after-\nfree in blk_mq_queue_tag_busy_iter(). This BUG can be recreated by\nrepeating the blktests test case nvme/063 a few times [1].\nWhen the BUG happens, nvme_tcp_create_ctrl() fails in the call chain\nbelow:\nnvme_tcp_create_ctrl()\nnvme_tcp_alloc_ctrl() new=true ... Alloc nvme_tcp_ctrl and admin_tag_set\nnvme_tcp_setup_ctrl() new=true\nnvme_tcp_configure_admin_queue() new=true ... Succeed\nnvme_alloc_admin_tag_set() ... Alloc the tag set for admin_tag_set\nnvme_stop_keep_alive()\nnvme_tcp_teardown_admin_queue() remove=false\nnvme_tcp_configure_admin_queue() new=false\nnvme_tcp_alloc_admin_queue() ... Fail, but do not call nvme_remove_admin_tag_set()\nnvme_uninit_ctrl()\nnvme_put_ctrl() ... Free up the nvme_tcp_ctrl and admin_tag_set\nThe first call of nvme_tcp_configure_admin_queue() succeeds with\nnew=true argument. The second call fails with new=false argument. This\nsecond call does not call nvme_remove_admin_tag_set() on failure, due to\nthe new=false argument. Then the admin tag set is not removed. However,\nnvme_tcp_create_ctrl() assumes that nvme_tcp_setup_ctrl() would call\nnvme_remove_admin_tag_set(). Then it frees up struct nvme_tcp_ctrl which\nhas admin_tag_set field. Later on, the timeout handler accesses the\nadmin_tag_set field and causes the BUG KASAN slab-use-after-free.\nTo not leave the admin tag set, call nvme_remove_admin_tag_set() when\nthe second nvme_tcp_configure_admin_queue() call fails. Do not return\nfrom nvme_tcp_setup_ctrl() on failure. Instead, jump to "destroy_admin"\ngo-to label to call nvme_tcp_teardown_admin_queue() which calls\nnvme_remove_admin_tag_set().

In the Linux kernel, the following vulnerability has been resolved:\nplatform/x86: dell_rbu: Fix list usage\nPass the correct list head to list_for_each_entry*() when looping through\nthe packet list.\nWithout this patch, reading the packet data via sysfs will show the data\nincorrectly (because it starts at the wrong packet), and clearing the\npacket list will result in a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\nio_uring/rsrc: validate buffer count with offset for cloning\nsyzbot reports that it can trigger a WARN_ON() for kmalloc() attempt\nthat's too big:\nWARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024\nModules linked in:\nCPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\npstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024\nlr : __do_kmalloc_node mm/slub.c:-1 [inline]\nlr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012\nsp : ffff80009cfd7a90\nx29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0\nx26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000\nx23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8\nx20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff\nx17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005\nx14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000\nx11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938\nx8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000\nx2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001\nCall trace:\n__kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)\nkvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]\nio_rsrc_data_alloc io_uring/rsrc.c:206 [inline]\nio_clone_buffers io_uring/rsrc.c:1178 [inline]\nio_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287\n__io_uring_register io_uring/register.c:815 [inline]\n__do_sys_io_uring_register io_uring/register.c:926 [inline]\n__se_sys_io_uring_register io_uring/register.c:903 [inline]\n__arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903\n__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\ninvoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\nel0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\ndo_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\nel0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767\nel0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786\nel0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\nwhich is due to offset + buffer_count being too large. The registration\ncode checks only the total count of buffers, but given that the indexing\nis an array, it should also check offset + count. That can't exceed\nIORING_MAX_REG_BUFFERS either, as there's no way to reach buffers beyond\nthat limit.\nThere's no issue with registrering a table this large, outside of the\nfact that it's pointless to register buffers that cannot be reached, and\nthat it can trigger this kmalloc() warning for attempting an allocation\nthat is too large.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/nouveau: fix a use-after-free in r535_gsp_rpc_push()\nThe RPC container is released after being passed to r535_gsp_rpc_send().\nWhen sending the initial fragment of a large RPC and passing the\ncaller's RPC container, the container will be freed prematurely. Subsequent\nattempts to send remaining fragments will therefore result in a\nuse-after-free.\nAllocate a temporary RPC container for holding the initial fragment of a\nlarge RPC when sending. Free the caller's container when all fragments\nare successfully sent.\n[ Rebase onto Blackwell changes. - Danilo ]

In the Linux kernel, the following vulnerability has been resolved:\nbnxt_en: Fix double invocation of bnxt_ulp_stop()/bnxt_ulp_start()\nBefore the commit under the Fixes tag below, bnxt_ulp_stop() and\nbnxt_ulp_start() were always invoked in pairs. After that commit,\nthe new bnxt_ulp_restart() can be invoked after bnxt_ulp_stop()\nhas been called. This may result in the RoCE driver's aux driver\n.suspend() method being invoked twice. The 2nd bnxt_re_suspend()\ncall will crash when it dereferences a NULL pointer:\n(NULL ib_device): Handle device suspend call\nBUG: kernel NULL pointer dereference, address: 0000000000000b78\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP PTI\nCPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S 6.15.0-rc1 #4 PREEMPT(voluntary)\nTainted: [S]=CPU_OUT_OF_SPEC\nHardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017\nWorkqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en]\nRIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re]\nCode: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff <48> 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00\nRSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001\nRDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffff\nRBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfff\nR10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070\nR13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\nbnxt_ulp_stop+0x69/0x90 [bnxt_en]\nbnxt_sp_task+0x678/0x920 [bnxt_en]\n? __schedule+0x514/0xf50\nprocess_scheduled_works+0x9d/0x400\nworker_thread+0x11c/0x260\n? __pfx_worker_thread+0x10/0x10\nkthread+0xfe/0x1e0\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x2b/0x40\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1a/0x30\nCheck the BNXT_EN_FLAG_ULP_STOPPED flag and do not proceed if the flag\nis already set. This will preserve the original symmetrical\nbnxt_ulp_stop() and bnxt_ulp_start().\nAlso, inside bnxt_ulp_start(), clear the BNXT_EN_FLAG_ULP_STOPPED\nflag after taking the mutex to avoid any race condition. And for\nsymmetry, only proceed in bnxt_ulp_start() if the\nBNXT_EN_FLAG_ULP_STOPPED is set.

In the Linux kernel, the following vulnerability has been resolved:\nublk: santizize the arguments from userspace when adding a device\nSanity check the values for queue depth and number of queues\nwe get from userspace when adding a device.

Redis is an open source, in-memory database that persists on disk. From 2.8 to before 8.0.3, 7.4.5, 7.2.10, and 6.2.19, an authenticated user may use a specially crafted string to trigger a stack/heap out of bounds write on hyperloglog operations, potentially leading to remote code execution. The bug likely affects all Redis versions with hyperloglog operations implemented. This vulnerability is fixed in 8.0.3, 7.4.5, 7.2.10, and 6.2.19. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing hyperloglog operations. This can be done using ACL to restrict HLL commands.

No description is available for this CVE.

mtr through 0.95, in certain privileged contexts, mishandles execution of a program specified by the MTR_PACKET environment variable. NOTE: mtr on macOS may often have Sudo rules, as an indirect consequence of Homebrew not installing setuid binaries.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nceph: avoid kernel BUG for encrypted inode with unaligned file size\n\nThe generic/397 test hits a BUG_ON for the case of encrypted inode with\nunaligned file size (for example, 33K or 1K):\n\n[ 877.737811] run fstests generic/397 at 2025-01-03 12:34:40\n[ 877.875761] libceph: mon0 (2)127.0.0.1:40674 session established\n[ 877.876130] libceph: client4614 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949\n[ 877.991965] libceph: mon0 (2)127.0.0.1:40674 session established\n[ 877.992334] libceph: client4617 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949\n[ 878.017234] libceph: mon0 (2)127.0.0.1:40674 session established\n[ 878.017594] libceph: client4620 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949\n[ 878.031394] xfs_io (pid 18988) is setting deprecated v1 encryption policy; recommend upgrading to v2.\n[ 878.054528] libceph: mon0 (2)127.0.0.1:40674 session established\n[ 878.054892] libceph: client4623 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949\n[ 878.070287] libceph: mon0 (2)127.0.0.1:40674 session established\n[ 878.070704] libceph: client4626 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949\n[ 878.264586] libceph: mon0 (2)127.0.0.1:40674 session established\n[ 878.265258] libceph: client4629 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949\n[ 878.374578] -----------[ cut here ]------------\n[ 878.374586] kernel BUG at net/ceph/messenger.c:1070!\n[ 878.375150] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 878.378145] CPU: 2 UID: 0 PID: 4759 Comm: kworker/2:9 Not tainted 6.13.0-rc5+ #1\n[ 878.378969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 878.380167] Workqueue: ceph-msgr ceph_con_workfn\n[ 878.381639] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50\n[ 878.382152] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90\n[ 878.383928] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287\n[ 878.384447] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000\n[ 878.385129] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378\n[ 878.385839] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000\n[ 878.386539] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030\n[ 878.387203] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001\n[ 878.387877] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000\n[ 878.388663] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 878.389212] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0\n[ 878.389921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 878.390620] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 878.391307] PKRU: 55555554\n[ 878.391567] Call Trace:\n[ 878.391807] \n[ 878.392021] ? show_regs+0x71/0x90\n[ 878.392391] ? die+0x38/0xa0\n[ 878.392667] ? do_trap+0xdb/0x100\n[ 878.392981] ? do_error_trap+0x75/0xb0\n[ 878.393372] ? ceph_msg_data_cursor_init+0x42/0x50\n[ 878.393842] ? exc_invalid_op+0x53/0x80\n[ 878.394232] ? ceph_msg_data_cursor_init+0x42/0x50\n[ 878.394694] ? asm_exc_invalid_op+0x1b/0x20\n[ 878.395099] ? ceph_msg_data_cursor_init+0x42/0x50\n[ 878.395583] ? ceph_con_v2_try_read+0xd16/0x2220\n[ 878.396027] ? _raw_spin_unlock+0xe/0x40\n[ 878.396428] ? raw_spin_rq_unlock+0x10/0x40\n[ 878.396842] ? finish_task_switch.isra.0+0x97/0x310\n[ 878.397338] ? __schedule+0x44b/0x16b0\n[ 878.397738] ceph_con_workfn+0x326/0x750\n[ 878.398121] process_one_work+0x188/0x3d0\n[ 878.398522] ? __pfx_worker_thread+0x10/0x10\n[ 878.398929] worker_thread+0x2b5/0x3c0\n[ 878.399310] ? __pfx_worker_thread+0x10/0x10\n[ 878.399727] kthread+0xe1/0x120\n[ 878.400031] ? __pfx_kthread+0x10/0x10\n[ 878.400431] ret_from_fork+0x43/0x70\n[ 878.400771] ? __pfx_kthread+0x10/0x10\n[ 878.401127] ret_from_fork_asm+0x1a/0x30\n[ 878.401543] \n[ 878.401760] Modules l\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix out of bounds punch offset\n\nPunching a hole with a start offset that exceeds max_end is not\npermitted and will result in a negative length in the\ntruncate_inode_partial_folio() function while truncating the page cache,\npotentially leading to undesirable consequences.\n\nA simple reproducer:\n\n truncate -s 9895604649994 /mnt/foo\n xfs_io -c "pwrite 8796093022208 4096" /mnt/foo\n xfs_io -c "fpunch 8796093022213 25769803777" /mnt/foo\n\n kernel BUG at include/linux/highmem.h:275!\n Oops: invalid opcode: 0000 [#1] SMP PTI\n CPU: 3 UID: 0 PID: 710 Comm: xfs_io Not tainted 6.15.0-rc3\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n RIP: 0010:zero_user_segments.constprop.0+0xd7/0x110\n RSP: 0018:ffffc90001cf3b38 EFLAGS: 00010287\n RAX: 0000000000000005 RBX: ffffea0001485e40 RCX: 0000000000001000\n RDX: 000000000040b000 RSI: 0000000000000005 RDI: 000000000040b000\n RBP: 000000000040affb R08: ffff888000000000 R09: ffffea0000000000\n R10: 0000000000000003 R11: 00000000fffc7fc5 R12: 0000000000000005\n R13: 000000000040affb R14: ffffea0001485e40 R15: ffff888031cd3000\n FS: 00007f4f63d0b780(0000) GS:ffff8880d337d000(0000)\n knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000001ae0b038 CR3: 00000000536aa000 CR4: 00000000000006f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \n truncate_inode_partial_folio+0x3dd/0x620\n truncate_inode_pages_range+0x226/0x720\n ? bdev_getblk+0x52/0x3e0\n ? ext4_get_group_desc+0x78/0x150\n ? crc32c_arch+0xfd/0x180\n ? __ext4_get_inode_loc+0x18c/0x840\n ? ext4_inode_csum+0x117/0x160\n ? jbd2_journal_dirty_metadata+0x61/0x390\n ? __ext4_handle_dirty_metadata+0xa0/0x2b0\n ? kmem_cache_free+0x90/0x5a0\n ? jbd2_journal_stop+0x1d5/0x550\n ? __ext4_journal_stop+0x49/0x100\n truncate_pagecache_range+0x50/0x80\n ext4_truncate_page_cache_block_range+0x57/0x3a0\n ext4_punch_hole+0x1fe/0x670\n ext4_fallocate+0x792/0x17d0\n ? __count_memcg_events+0x175/0x2a0\n vfs_fallocate+0x121/0x560\n ksys_fallocate+0x51/0xc0\n __x64_sys_fallocate+0x24/0x40\n x64_sys_call+0x18d2/0x4170\n do_syscall_64+0xa7/0x220\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFix this by filtering out cases where the punching start offset exceeds\nmax_end.

In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var\n\nIf fb_add_videomode() in do_register_framebuffer() fails to allocate\nmemory for fb_videomode, it will later lead to a null-ptr dereference in\nfb_videomode_to_var(), as the fb_info is registered while not having the\nmode in modelist that is expected to be there, i.e. the one that is\ndescribed in fb_info->var.\n\n================================================================\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901\nCall Trace:\n display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929\n fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071\n resize_screen drivers/tty/vt/vt.c:1176 [inline]\n vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263\n fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720\n fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776\n do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128\n fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203\n vfs_ioctl fs/ioctl.c:48 [inline]\n __do_sys_ioctl fs/ioctl.c:753 [inline]\n __se_sys_ioctl fs/ioctl.c:739 [inline]\n __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739\n do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x67/0xd1\n================================================================\n\nEven though fbcon_init() checks beforehand if fb_match_mode() in\nvar_to_display() fails, it can not prevent the panic because fbcon_init()\ndoes not return error code. Considering this and the comment in the code\nabout fb_match_mode() returning NULL - "This should not happen" - it is\nbetter to prevent registering the fb_info if its mode was not set\nsuccessfully. Also move fb_add_videomode() closer to the beginning of\ndo_register_framebuffer() to avoid having to do the cleanup on fail.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

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_sched: sch_sfq: reject invalid perturb period\n\nGerrard Tai reported that SFQ perturb_period has no range check yet,\nand this can be used to trigger a race condition fixed in a separate patch.\n\nWe want to make sure ctl->perturb_period * HZ will not overflow\nand is positive.\n\n\ntc qd add dev lo root sfq perturb -10 # negative value : error\nError: sch_sfq: invalid perturb period.\n\ntc qd add dev lo root sfq perturb 1000000000 # too big : error\nError: sch_sfq: invalid perturb period.\n\ntc qd add dev lo root sfq perturb 2000000 # acceptable value\ntc -s -d qd sh dev lo\nqdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec\n Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)\n backlog 0b 0p requeues 0

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix max_sge overflow in smb_extract_folioq_to_rdma()\n\nThis fixes the following problem:\n\n[ 749.901015] [ T8673] run fstests cifs/001 at 2025-06-17 09:40:30\n[ 750.346409] [ T9870] ==================================================================\n[ 750.346814] [ T9870] BUG: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs]\n[ 750.347330] [ T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870\n[ 750.347705] [ T9870]\n[ 750.348077] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Not tainted 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary)\n[ 750.348082] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006\n[ 750.348085] [ T9870] Call Trace:\n[ 750.348086] [ T9870] \n[ 750.348088] [ T9870] dump_stack_lvl+0x76/0xa0\n[ 750.348106] [ T9870] print_report+0xd1/0x640\n[ 750.348116] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 750.348120] [ T9870] ? kasan_complete_mode_report_info+0x26/0x210\n[ 750.348124] [ T9870] kasan_report+0xe7/0x130\n[ 750.348128] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]\n[ 750.348262] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]\n[ 750.348377] [ T9870] __asan_report_store8_noabort+0x17/0x30\n[ 750.348381] [ T9870] smb_set_sge+0x2cc/0x3b0 [cifs]\n[ 750.348496] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs]\n[ 750.348625] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs]\n[ 750.348741] [ T9870] ? update_stack_state+0x2a0/0x670\n[ 750.348749] [ T9870] ? cifs_flush+0x153/0x320 [cifs]\n[ 750.348870] [ T9870] ? cifs_flush+0x153/0x320 [cifs]\n[ 750.348990] [ T9870] ? update_stack_state+0x2a0/0x670\n[ 750.348995] [ T9870] smbd_send+0x58c/0x9c0 [cifs]\n[ 750.349117] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs]\n[ 750.349231] [ T9870] ? unwind_get_return_address+0x65/0xb0\n[ 750.349235] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10\n[ 750.349242] [ T9870] ? arch_stack_walk+0xa7/0x100\n[ 750.349250] [ T9870] ? stack_trace_save+0x92/0xd0\n[ 750.349254] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs]\n[ 750.349374] [ T9870] ? kernel_text_address+0x173/0x190\n[ 750.349379] [ T9870] ? kasan_save_stack+0x39/0x70\n[ 750.349382] [ T9870] ? kasan_save_track+0x18/0x70\n[ 750.349385] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0\n[ 750.349389] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs]\n[ 750.349508] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs]\n[ 750.349626] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs]\n[ 750.349746] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]\n[ 750.349867] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs]\n[ 750.349900] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs]\n[ 750.349929] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs]\n[ 750.349958] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs]\n[ 750.349987] [ T9870] ? do_writepages+0x21f/0x590\n[ 750.349993] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140\n[ 750.349997] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 750.350002] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs]\n[ 750.350131] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs]\n[ 750.350255] [ T9870] ? local_clock_noinstr+0xe/0xd0\n[ 750.350261] [ T9870] ? kasan_save_alloc_info+0x37/0x60\n[ 750.350268] [ T9870] ? __kasan_check_write+0x14/0x30\n[ 750.350271] [ T9870] ? _raw_spin_lock+0x81/0xf0\n[ 750.350275] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10\n[ 750.350278] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs]\n[ 750.350398] [ T9870] cifs_call_async+0x477/0xb00 [cifs]\n[ 750.350518] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]\n[ 750.350636] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs]\n[ 750.350756] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10\n[ 750.350760] [ T9870] ? __kasan_check_write+0x14/0x30\n[ 750.350763] [ T98\n---truncated---

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix use-after-free in binderfs_evict_inode()\n\nRunning 'stress-ng --binderfs 16 --timeout 300' under KASAN-enabled\nkernel, I've noticed the following:\n\nBUG: KASAN: slab-use-after-free in binderfs_evict_inode+0x1de/0x2d0\nWrite of size 8 at addr ffff88807379bc08 by task stress-ng-binde/1699\n\nCPU: 0 UID: 0 PID: 1699 Comm: stress-ng-binde Not tainted 6.14.0-rc7-g586de92313fc-dirty #13\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014\nCall Trace:\n \n dump_stack_lvl+0x1c2/0x2a0\n ? __pfx_dump_stack_lvl+0x10/0x10\n ? __pfx__printk+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? __virt_addr_valid+0x18c/0x540\n ? __virt_addr_valid+0x469/0x540\n print_report+0x155/0x840\n ? __virt_addr_valid+0x18c/0x540\n ? __virt_addr_valid+0x469/0x540\n ? __phys_addr+0xba/0x170\n ? binderfs_evict_inode+0x1de/0x2d0\n kasan_report+0x147/0x180\n ? binderfs_evict_inode+0x1de/0x2d0\n binderfs_evict_inode+0x1de/0x2d0\n ? __pfx_binderfs_evict_inode+0x10/0x10\n evict+0x524/0x9f0\n ? __pfx_lock_release+0x10/0x10\n ? __pfx_evict+0x10/0x10\n ? do_raw_spin_unlock+0x4d/0x210\n ? _raw_spin_unlock+0x28/0x50\n ? iput+0x697/0x9b0\n __dentry_kill+0x209/0x660\n ? shrink_kill+0x8d/0x2c0\n shrink_kill+0xa9/0x2c0\n shrink_dentry_list+0x2e0/0x5e0\n shrink_dcache_parent+0xa2/0x2c0\n ? __pfx_shrink_dcache_parent+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? __pfx_do_raw_spin_lock+0x10/0x10\n do_one_tree+0x23/0xe0\n shrink_dcache_for_umount+0xa0/0x170\n generic_shutdown_super+0x67/0x390\n kill_litter_super+0x76/0xb0\n binderfs_kill_super+0x44/0x90\n deactivate_locked_super+0xb9/0x130\n cleanup_mnt+0x422/0x4c0\n ? lockdep_hardirqs_on+0x9d/0x150\n task_work_run+0x1d2/0x260\n ? __pfx_task_work_run+0x10/0x10\n resume_user_mode_work+0x52/0x60\n syscall_exit_to_user_mode+0x9a/0x120\n do_syscall_64+0x103/0x210\n ? asm_sysvec_apic_timer_interrupt+0x1a/0x20\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0xcac57b\nCode: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8\nRSP: 002b:00007ffecf4226a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6\nRAX: 0000000000000000 RBX: 00007ffecf422720 RCX: 0000000000cac57b\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffecf422850\nRBP: 00007ffecf422850 R08: 0000000028d06ab1 R09: 7fffffffffffffff\nR10: 3fffffffffffffff R11: 0000000000000246 R12: 00007ffecf422718\nR13: 00007ffecf422710 R14: 00007f478f87b658 R15: 00007ffecf422830\n \n\nAllocated by task 1705:\n kasan_save_track+0x3e/0x80\n __kasan_kmalloc+0x8f/0xa0\n __kmalloc_cache_noprof+0x213/0x3e0\n binderfs_binder_device_create+0x183/0xa80\n binder_ctl_ioctl+0x138/0x190\n __x64_sys_ioctl+0x120/0x1b0\n do_syscall_64+0xf6/0x210\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 1705:\n kasan_save_track+0x3e/0x80\n kasan_save_free_info+0x46/0x50\n __kasan_slab_free+0x62/0x70\n kfree+0x194/0x440\n evict+0x524/0x9f0\n do_unlinkat+0x390/0x5b0\n __x64_sys_unlink+0x47/0x50\n do_syscall_64+0xf6/0x210\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThis 'stress-ng' workload causes the concurrent deletions from\n'binder_devices' and so requires full-featured synchronization\nto prevent list corruption.\n\nI've found this issue independently but pretty sure that syzbot did\nthe same, so Reported-by: and Closes: should be applicable here as well.

In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix yet another UAF in binder_devices\n\nCommit e77aff5528a18 ("binderfs: fix use-after-free in binder_devices")\naddressed a use-after-free where devices could be released without first\nbeing removed from the binder_devices list. However, there is a similar\npath in binder_free_proc() that was missed:\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in binder_remove_device+0xd4/0x100\n Write of size 8 at addr ffff0000c773b900 by task umount/467\n CPU: 12 UID: 0 PID: 467 Comm: umount Not tainted 6.15.0-rc7-00138-g57483a362741 #9 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n Call trace:\n binder_remove_device+0xd4/0x100\n binderfs_evict_inode+0x230/0x2f0\n evict+0x25c/0x5dc\n iput+0x304/0x480\n dentry_unlink_inode+0x208/0x46c\n __dentry_kill+0x154/0x530\n [...]\n\n Allocated by task 463:\n __kmalloc_cache_noprof+0x13c/0x324\n binderfs_binder_device_create.isra.0+0x138/0xa60\n binder_ctl_ioctl+0x1ac/0x230\n [...]\n\n Freed by task 215:\n kfree+0x184/0x31c\n binder_proc_dec_tmpref+0x33c/0x4ac\n binder_deferred_func+0xc10/0x1108\n process_one_work+0x520/0xba4\n [...]\n ==================================================================\n\nCall binder_remove_device() within binder_free_proc() to ensure the\ndevice is removed from the binder_devices list before being kfreed.

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.

Next.js is a React framework for building full-stack web applications. In Next.js App Router from 15.3.0 to before 15.3.3 and Vercel CLI from 41.4.1 to 42.2.0, a cache poisoning vulnerability was found. The issue allowed page requests for HTML content to return a React Server Component (RSC) payload instead under certain conditions. When deployed to Vercel, this would only impact the browser cache, and would not lead to the CDN being poisoned. When self-hosted and deployed externally, this could lead to cache poisoning if the CDN does not properly distinguish between RSC / HTML in the cache keys. This issue has been resolved in Next.js 15.3.3.

Pillow is a Python imaging library. In versions 11.2.0 to before 11.3.0, there is a heap buffer overflow when writing a sufficiently large (>64k encoded with default settings) image in the DDS format due to writing into a buffer without checking for available space. This only affects users who save untrusted data as a compressed DDS image. This issue has been patched in version 11.3.0.

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.

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.

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.

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 denial-of-service vulnerability has been identified in the Linux kernel, stemming from an out-of-bounds overflow. This flaw occurs when the requested memory mapping region size exceeds the allocated region size. An attacker can exploit this by crafting a specially designed file, which, when processed by the kernel, could trigger an overflow. This leads to a system crash, impacting the availability of the affected system.

No description is available for this CVE.

A flaw was found in Sudo. This flaw allows a local attacker to escalate their privileges by tricking Sudo into loading an arbitrary shared library using the user-specified root directory via the `-R` (`--chroot`) option. An attacker can run arbitrary commands as root on systems that support `/etc/nsswitch.conf`.

Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines.

A flaw was found in Ceph. This vulnerability allows a non-privileged user to change the permissions from a directory owned by the root user and gain access to the targeted directory.

In the Linux kernel, the following vulnerability has been resolved:\nASoC: codecs: wcd937x: fix a potential memory leak in wcd937x_soc_codec_probe()\nWhen snd_soc_dapm_new_controls() or snd_soc_dapm_add_routes() fails,\nwcd937x_soc_codec_probe() returns without releasing 'wcd937x->clsh_info',\nwhich is allocated by wcd_clsh_ctrl_alloc. Add wcd_clsh_ctrl_free()\nto prevent potential memory leak.

When a non-x86 platform is detected, cloud-init grants root access to a hardcoded url with a local IP address. To prevent this, cloud-init default configurations disable platform enumeration.

No description is available for this CVE.

No description is available for this CVE.