Vulnerabilities

Uncontrolled Resource Consumption in Elasticsearch while evaluating specifically crafted search templates with Mustache functions can lead to Denial of Service by causing the Elasticsearch node to crash.

Unrestricted upload of a file with dangerous type in Kibana can lead to arbitrary JavaScript execution in a victim’s browser (XSS) via crafted HTML and JavaScript files.<br /> <br /> The attacker must have access to the Synthetics app AND/OR have access to write to the synthetics indices.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe()<br /> <br /> devm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does<br /> not check for this case, which can result in a NULL pointer dereference.<br /> <br /> Add NULL check after devm_ioremap() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix memory leak in tipc_link_xmit<br /> <br /> In case the backlog transmit queue for system-importance messages is overloaded,<br /> tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to<br /> memory leak and failure when a skb is allocated.<br /> <br /> This commit fixes this issue by purging the skb list before tipc_link_xmit()<br /> returns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tls: explicitly disallow disconnect<br /> <br /> syzbot discovered that it can disconnect a TLS socket and then<br /> run into all sort of unexpected corner cases. I have a vague<br /> recollection of Eric pointing this out to us a long time ago.<br /> Supporting disconnect is really hard, for one thing if offload<br /> is enabled we&amp;#39;d need to wait for all packets to be _acked_.<br /> Disconnect is not commonly used, disallow it.<br /> <br /> The immediate problem syzbot run into is the warning in the strp,<br /> but that&amp;#39;s just the easiest bug to trigger:<br /> <br /> WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486<br /> RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486<br /> Call Trace:<br /> <br /> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363<br /> tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043<br /> inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678<br /> sock_recvmsg_nosec net/socket.c:1023 [inline]<br /> sock_recvmsg+0x109/0x280 net/socket.c:1045<br /> __sys_recvfrom+0x202/0x380 net/socket.c:2237

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: libwx: handle page_pool_dev_alloc_pages error<br /> <br /> page_pool_dev_alloc_pages could return NULL. There was a WARN_ON(!page)<br /> but it would still proceed to use the NULL pointer and then crash.<br /> <br /> This is similar to commit 001ba0902046<br /> ("net: fec: handle page_pool_dev_alloc_pages error").<br /> <br /> This is found by our static analysis tool KNighter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/huc: Fix fence not released on early probe errors<br /> <br /> HuC delayed loading fence, introduced with commit 27536e03271da<br /> ("drm/i915/huc: track delayed HuC load with a fence"), is registered with<br /> object tracker early on driver probe but unregistered only from driver<br /> remove, which is not called on early probe errors. Since its memory is<br /> allocated under devres, then released anyway, it may happen to be<br /> allocated again to the fence and reused on future driver probes, resulting<br /> in kernel warnings that taint the kernel:<br /> <br /> [309.731371] ------------[ cut here ]------------<br /> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915]<br /> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0<br /> ...<br /> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1<br /> ...<br /> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0<br /> ...<br /> [309.731728] Call Trace:<br /> [309.731730] <br /> ...<br /> [309.731949] __debug_object_init+0x17b/0x1c0<br /> [309.731957] debug_object_init+0x34/0x50<br /> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915]<br /> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915]<br /> [309.732468] intel_uc_init_early+0x61/0x680 [i915]<br /> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915]<br /> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915]<br /> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915]<br /> [309.733075] i915_pci_probe+0xe6/0x220 [i915]<br /> [309.733198] local_pci_probe+0x44/0xb0<br /> [309.733203] pci_device_probe+0xf4/0x270<br /> [309.733209] really_probe+0xee/0x3c0<br /> [309.733215] __driver_probe_device+0x8c/0x180<br /> [309.733219] driver_probe_device+0x24/0xd0<br /> [309.733223] __driver_attach+0x10f/0x220<br /> [309.733230] bus_for_each_dev+0x7d/0xe0<br /> [309.733236] driver_attach+0x1e/0x30<br /> [309.733239] bus_add_driver+0x151/0x290<br /> [309.733244] driver_register+0x5e/0x130<br /> [309.733247] __pci_register_driver+0x7d/0x90<br /> [309.733251] i915_pci_register_driver+0x23/0x30 [i915]<br /> [309.733413] i915_init+0x34/0x120 [i915]<br /> [309.733655] do_one_initcall+0x62/0x3f0<br /> [309.733667] do_init_module+0x97/0x2a0<br /> [309.733671] load_module+0x25ff/0x2890<br /> [309.733688] init_module_from_file+0x97/0xe0<br /> [309.733701] idempotent_init_module+0x118/0x330<br /> [309.733711] __x64_sys_finit_module+0x77/0x100<br /> [309.733715] x64_sys_call+0x1f37/0x2650<br /> [309.733719] do_syscall_64+0x91/0x180<br /> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [309.733792] <br /> ...<br /> [309.733806] ---[ end trace 0000000000000000 ]---<br /> <br /> That scenario is most easily reproducible with<br /> igt@i915_module_load@reload-with-fault-injection.<br /> <br /> Fix the issue by moving the cleanup step to driver release path.<br /> <br /> (cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix handling recovery &amp; reissue in ublk_abort_queue()<br /> <br /> Commit 8284066946e6 ("ublk: grab request reference when the request is handled<br /> by userspace") doesn&amp;#39;t grab request reference in case of recovery reissue.<br /> Then the request can be requeued &amp; re-dispatch &amp; failed when canceling<br /> uring command.<br /> <br /> If it is one zc request, the request can be freed before io_uring<br /> returns the zc buffer back, then cause kernel panic:<br /> <br /> [ 126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8<br /> [ 126.773657] #PF: supervisor read access in kernel mode<br /> [ 126.774052] #PF: error_code(0x0000) - not-present page<br /> [ 126.774455] PGD 0 P4D 0<br /> [ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ #182 PREEMPT(full)<br /> [ 126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014<br /> [ 126.776275] Workqueue: iou_exit io_ring_exit_work<br /> [ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv]<br /> <br /> Fixes it by always grabbing request reference for aborting the request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: sch_sfq: move the limit validation<br /> <br /> It is not sufficient to directly validate the limit on the data that<br /> the user passes as it can be updated based on how the other parameters<br /> are changed.<br /> <br /> Move the check at the end of the configuration update process to also<br /> catch scenarios where the limit is indirectly updated, for example<br /> with the following configurations:<br /> <br /> tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1<br /> tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1<br /> <br /> This fixes the following syzkaller reported crash:<br /> <br /> ------------[ cut here ]------------<br /> UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6<br /> index 65535 is out of range for type &amp;#39;struct sfq_head[128]&amp;#39;<br /> CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120<br /> ubsan_epilogue lib/ubsan.c:231 [inline]<br /> __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429<br /> sfq_link net/sched/sch_sfq.c:203 [inline]<br /> sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231<br /> sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493<br /> sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518<br /> qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035<br /> tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339<br /> qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035<br /> dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311<br /> netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]<br /> dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ppp: Add bound checking for skb data on ppp_sync_txmung<br /> <br /> Ensure we have enough data in linear buffer from skb before accessing<br /> initial bytes. This prevents potential out-of-bounds accesses<br /> when processing short packets.<br /> <br /> When ppp_sync_txmung receives an incoming package with an empty<br /> payload:<br /> (remote) gef➤ p *(struct pppoe_hdr *) (skb-&gt;head + skb-&gt;network_header)<br /> $18 = {<br /> type = 0x1,<br /> ver = 0x1,<br /> code = 0x0,<br /> sid = 0x2,<br /> length = 0x0,<br /> tag = 0xffff8880371cdb96<br /> }<br /> <br /> from the skb struct (trimmed)<br /> tail = 0x16,<br /> end = 0x140,<br /> head = 0xffff88803346f400 "4",<br /> data = 0xffff88803346f416 ":\377",<br /> truesize = 0x380,<br /> len = 0x0,<br /> data_len = 0x0,<br /> mac_len = 0xe,<br /> hdr_len = 0x0,<br /> <br /> it is not safe to access data[2].<br /> <br /> [pabeni@redhat.com: fixed subj typo]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group<br /> <br /> Currently, mtk_iommu calls during probe iommu_device_register before<br /> the hw_list from driver data is initialized. Since iommu probing issue<br /> fix, it leads to NULL pointer dereference in mtk_iommu_device_group when<br /> hw_list is accessed with list_first_entry (not null safe).<br /> <br /> So, change the call order to ensure iommu_device_register is called<br /> after the driver data are initialized.