Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix operation precedence bug in port timestamping napi_poll context<br /> <br /> Indirection (*) is of lower precedence than postfix increment (++). Logic<br /> in napi_poll context would cause an out-of-bound read by first increment<br /> the pointer address by byte address space and then dereference the value.<br /> Rather, the intended logic was to dereference first and then increment the<br /> underlying value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad7091r: Allow users to configure device events<br /> <br /> AD7091R-5 devices are supported by the ad7091r-5 driver together with<br /> the ad7091r-base driver. Those drivers declared iio events for notifying<br /> user space when ADC readings fall bellow the thresholds of low limit<br /> registers or above the values set in high limit registers.<br /> However, to configure iio events and their thresholds, a set of callback<br /> functions must be implemented and those were not present until now.<br /> The consequence of trying to configure ad7091r-5 events without the<br /> proper callback functions was a null pointer dereference in the kernel<br /> because the pointers to the callback functions were not set.<br /> <br /> Implement event configuration callbacks allowing users to read/write<br /> event thresholds and enable/disable event generation.<br /> <br /> Since the event spec structs are generic to AD7091R devices, also move<br /> those from the ad7091r-5 driver the base driver so they can be reused<br /> when support for ad7091r-2/-4/-8 be added.

It is possible for a user in a different organization from the owner of a snapshot to bypass authorization and delete a snapshot by issuing a DELETE request to /api/snapshots/ using its view key. This functionality is intended to only be available to individuals with the permission to write/edit to the snapshot in question, but due to a bug in the authorization logic, deletion requests issued by an unprivileged user in a different organization than the snapshot owner are treated as authorized.<br /> <br /> Grafana Labs would like to thank Ravid Mazon and Jay Chen of Palo <br /> Alto Research for discovering and disclosing this vulnerability.<br /> <br /> This issue affects Grafana: from 9.5.0 before 9.5.18, from 10.0.0 before 10.0.13, from 10.1.0 before 10.1.9, from 10.2.0 before 10.2.6, from 10.3.0 before 10.3.5.

Insertion of Sensitive Information into Log File vulnerability in GSheetConnector CF7 Google Sheets Connector.This issue affects CF7 Google Sheets Connector: from n/a through 5.0.5.<br /> <br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid online resizing failures due to oversized flex bg<br /> <br /> When we online resize an ext4 filesystem with a oversized flexbg_size,<br /> <br /> mkfs.ext4 -F -G 67108864 $dev -b 4096 100M<br /> mount $dev $dir<br /> resize2fs $dev 16G<br /> <br /> the following WARN_ON is triggered:<br /> ==================================================================<br /> WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550<br /> Modules linked in: sg(E)<br /> CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314<br /> RIP: 0010:__alloc_pages+0x411/0x550<br /> Call Trace:<br /> <br /> __kmalloc_large_node+0xa2/0x200<br /> __kmalloc+0x16e/0x290<br /> ext4_resize_fs+0x481/0xd80<br /> __ext4_ioctl+0x1616/0x1d90<br /> ext4_ioctl+0x12/0x20<br /> __x64_sys_ioctl+0xf0/0x150<br /> do_syscall_64+0x3b/0x90<br /> ==================================================================<br /> <br /> This is because flexbg_size is too large and the size of the new_group_data<br /> array to be allocated exceeds MAX_ORDER. Currently, the minimum value of<br /> MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding<br /> maximum number of groups that can be allocated is:<br /> <br /> (PAGE_SIZE

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Wake DMCUB before executing GPINT commands<br /> <br /> [Why]<br /> DMCUB can be in idle when we attempt to interface with the HW through<br /> the GPINT mailbox resulting in a system hang.<br /> <br /> [How]<br /> Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep<br /> sequence.<br /> <br /> If the GPINT executes successfully then DMCUB will be put back into<br /> sleep after the optional response is returned.<br /> <br /> It functions similar to the inbox command interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix a suspicious RCU usage warning<br /> <br /> I received the following warning while running cthon against an ontap<br /> server running pNFS:<br /> <br /> [ 57.202521] =============================<br /> [ 57.202522] WARNING: suspicious RCU usage<br /> [ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted<br /> [ 57.202525] -----------------------------<br /> [ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!<br /> [ 57.202527]<br /> other info that might help us debug this:<br /> <br /> [ 57.202528]<br /> rcu_scheduler_active = 2, debug_locks = 1<br /> [ 57.202529] no locks held by test5/3567.<br /> [ 57.202530]<br /> stack backtrace:<br /> [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e<br /> [ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022<br /> [ 57.202536] Call Trace:<br /> [ 57.202537] <br /> [ 57.202540] dump_stack_lvl+0x77/0xb0<br /> [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0<br /> [ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]<br /> [ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]<br /> [ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]<br /> [ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]<br /> [ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]<br /> [ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]<br /> [ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]<br /> [ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]<br /> [ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]<br /> [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]<br /> [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]<br /> [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]<br /> [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]<br /> [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]<br /> [ 57.202866] write_cache_pages+0x265/0x450<br /> [ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]<br /> [ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]<br /> [ 57.202913] do_writepages+0xd2/0x230<br /> [ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80<br /> [ 57.202921] filemap_fdatawrite_wbc+0x67/0x80<br /> [ 57.202924] filemap_write_and_wait_range+0xd9/0x170<br /> [ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]<br /> [ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]<br /> [ 57.202969] __se_sys_close+0x46/0xd0<br /> [ 57.202972] do_syscall_64+0x68/0x100<br /> [ 57.202975] ? do_syscall_64+0x77/0x100<br /> [ 57.202976] ? do_syscall_64+0x77/0x100<br /> [ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 57.202982] RIP: 0033:0x7fe2b12e4a94<br /> [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3<br /> [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003<br /> [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94<br /> [ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003<br /> [ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49<br /> [ 57.202993] R10: 00007f<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers<br /> <br /> These three bpf_map_{lookup,update,delete}_elem() helpers are also<br /> available for sleepable bpf program, so add the corresponding lock<br /> assertion for sleepable bpf program, otherwise the following warning<br /> will be reported when a sleepable bpf program manipulates bpf map under<br /> interpreter mode (aka bpf_jit_enable=0):<br /> <br /> WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......<br /> CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......<br /> RIP: 0010:bpf_map_lookup_elem+0x54/0x60<br /> ......<br /> Call Trace:<br /> <br /> ? __warn+0xa5/0x240<br /> ? bpf_map_lookup_elem+0x54/0x60<br /> ? report_bug+0x1ba/0x1f0<br /> ? handle_bug+0x40/0x80<br /> ? exc_invalid_op+0x18/0x50<br /> ? asm_exc_invalid_op+0x1b/0x20<br /> ? __pfx_bpf_map_lookup_elem+0x10/0x10<br /> ? rcu_lockdep_current_cpu_online+0x65/0xb0<br /> ? rcu_is_watching+0x23/0x50<br /> ? bpf_map_lookup_elem+0x54/0x60<br /> ? __pfx_bpf_map_lookup_elem+0x10/0x10<br /> ___bpf_prog_run+0x513/0x3b70<br /> __bpf_prog_run32+0x9d/0xd0<br /> ? __bpf_prog_enter_sleepable_recur+0xad/0x120<br /> ? __bpf_prog_enter_sleepable_recur+0x3e/0x120<br /> bpf_trampoline_6442580665+0x4d/0x1000<br /> __x64_sys_getpgid+0x5/0x30<br /> ? do_syscall_64+0x36/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br />

A vulnerability was found in Tenda AC7 15.03.06.44. It has been classified as critical. This affects the function formSetQosBand of the file /goform/SetNetControlList. The manipulation of the argument list leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-257937 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was found in Tenda AC7 15.03.06.44 and classified as critical. Affected by this issue is the function formSetDeviceName of the file /goform/SetOnlineDevName. The manipulation of the argument devName leads to stack-based buffer overflow. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-257936. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

Improper Preservation of Permissions vulnerability in Apache Airflow.This issue affects Apache Airflow from 2.8.2 through 2.8.3.<br /> <br /> Airflow&amp;#39;s local file task handler in Airflow incorrectly set permissions for all parent folders of log folder, in default configuration adding write access to Unix group of the folders. In the case Airflow is run with the root user (not recommended) it added group write permission to all folders up to the root of the filesystem.<br /> <br /> If your log files are stored in the home directory, these permission changes might impact your ability to run SSH operations after your home directory becomes group-writeable.<br /> <br /> This issue does not affect users who use or extend Airflow using Official Airflow Docker reference images ( https://hub.docker.com/r/apache/airflow/ ) - those images require to have group write permission set anyway.<br /> <br /> You are affected only if you install Airflow using local installation / virtualenv or other Docker images, but the issue has no impact if docker containers are used as intended, i.e. where Airflow components do not share containers with other applications and users.<br /> <br /> Also you should not be affected if your umask is 002 (group write enabled) - this is the default on many linux systems.<br /> <br /> Recommendation for users using Airflow outside of the containers:<br /> <br /> * if you are using root to run Airflow, change your Airflow user to use non-root<br /> * upgrade Apache Airflow to 2.8.4 or above<br /> * If you prefer not to upgrade, you can change the https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#file-task-handler-new-folder-permissions  to 0o755 (original value 0o775).<br /> * if you already ran Airflow tasks before and your default umask is 022 (group write disabled) you should stop Airflow components, check permissions of AIRFLOW_HOME/logs in all your components and all parent directories of this directory and remove group write access for all the parent directories

Improper access control in PAM JIT elevation in Devolutions Server 2024.1.6 and earlier allows an attacker with access to the PAM JIT elevation feature to elevate themselves to unauthorized groups via a specially crafted request.<br /> <br />