Vulnerabilities

Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as trusted certificate. In this configuration, an attacker may be able to craft a malicious certificate that could be used to bypass authentication. Fixed in Vault 1.15.5 and 1.14.10.

On affected 7130 Series FPGA platforms running MOS and recent versions of the MultiAccess FPGA, application of ACL’s may result in incorrect operation of the configured ACL for a port resulting in some packets that should be denied being permitted and some

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/qib: Fix memory leak in qib_user_sdma_queue_pkts()<br /> <br /> The wrong goto label was used for the error case and missed cleanup of the<br /> pkt allocation.<br /> <br /> Addresses-Coverity-ID: 1493352 ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: xsk: return xsk buffers back to pool when cleaning the ring<br /> <br /> Currently we only NULL the xdp_buff pointer in the internal SW ring but<br /> we never give it back to the xsk buffer pool. This means that buffers<br /> can be leaked out of the buff pool and never be used again.<br /> <br /> Add missing xsk_buff_free() call to the routine that is supposed to<br /> clean the entries that are left in the ring so that these buffers in the<br /> umem can be used by other sockets.<br /> <br /> Also, only go through the space that is actually left to be cleaned<br /> instead of a whole ring.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: fix use-after-free in nft_set_catchall_destroy()<br /> <br /> We need to use list_for_each_entry_safe() iterator<br /> because we can not access @catchall after kfree_rcu() call.<br /> <br /> syzbot reported:<br /> <br /> BUG: KASAN: use-after-free in nft_set_catchall_destroy net/netfilter/nf_tables_api.c:4486 [inline]<br /> BUG: KASAN: use-after-free in nft_set_destroy net/netfilter/nf_tables_api.c:4504 [inline]<br /> BUG: KASAN: use-after-free in nft_set_destroy+0x3fd/0x4f0 net/netfilter/nf_tables_api.c:4493<br /> Read of size 8 at addr ffff8880716e5b80 by task syz-executor.3/8871<br /> <br /> CPU: 1 PID: 8871 Comm: syz-executor.3 Not tainted 5.16.0-rc5-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0x8d/0x2ed mm/kasan/report.c:247<br /> __kasan_report mm/kasan/report.c:433 [inline]<br /> kasan_report.cold+0x83/0xdf mm/kasan/report.c:450<br /> nft_set_catchall_destroy net/netfilter/nf_tables_api.c:4486 [inline]<br /> nft_set_destroy net/netfilter/nf_tables_api.c:4504 [inline]<br /> nft_set_destroy+0x3fd/0x4f0 net/netfilter/nf_tables_api.c:4493<br /> __nft_release_table+0x79f/0xcd0 net/netfilter/nf_tables_api.c:9626<br /> nft_rcv_nl_event+0x4f8/0x670 net/netfilter/nf_tables_api.c:9688<br /> notifier_call_chain+0xb5/0x200 kernel/notifier.c:83<br /> blocking_notifier_call_chain kernel/notifier.c:318 [inline]<br /> blocking_notifier_call_chain+0x67/0x90 kernel/notifier.c:306<br /> netlink_release+0xcb6/0x1dd0 net/netlink/af_netlink.c:788<br /> __sock_release+0xcd/0x280 net/socket.c:649<br /> sock_close+0x18/0x20 net/socket.c:1314<br /> __fput+0x286/0x9f0 fs/file_table.c:280<br /> task_work_run+0xdd/0x1a0 kernel/task_work.c:164<br /> tracehook_notify_resume include/linux/tracehook.h:189 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:175 [inline]<br /> exit_to_user_mode_prepare+0x27e/0x290 kernel/entry/common.c:207<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]<br /> syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300<br /> do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f75fbf28adb<br /> Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44<br /> RSP: 002b:00007ffd8da7ec10 EFLAGS: 00000293 ORIG_RAX: 0000000000000003<br /> RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f75fbf28adb<br /> RDX: 00007f75fc08e828 RSI: ffffffffffffffff RDI: 0000000000000003<br /> RBP: 00007f75fc08a960 R08: 0000000000000000 R09: 00007f75fc08e830<br /> R10: 00007ffd8da7ed10 R11: 0000000000000293 R12: 00000000002067c3<br /> R13: 00007ffd8da7ed10 R14: 00007f75fc088f60 R15: 0000000000000032<br /> <br /> <br /> Allocated by task 8886:<br /> kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38<br /> kasan_set_track mm/kasan/common.c:46 [inline]<br /> set_alloc_info mm/kasan/common.c:434 [inline]<br /> ____kasan_kmalloc mm/kasan/common.c:513 [inline]<br /> ____kasan_kmalloc mm/kasan/common.c:472 [inline]<br /> __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:522<br /> kasan_kmalloc include/linux/kasan.h:269 [inline]<br /> kmem_cache_alloc_trace+0x1ea/0x4a0 mm/slab.c:3575<br /> kmalloc include/linux/slab.h:590 [inline]<br /> nft_setelem_catchall_insert net/netfilter/nf_tables_api.c:5544 [inline]<br /> nft_setelem_insert net/netfilter/nf_tables_api.c:5562 [inline]<br /> nft_add_set_elem+0x232e/0x2f40 net/netfilter/nf_tables_api.c:5936<br /> nf_tables_newsetelem+0x6ff/0xbb0 net/netfilter/nf_tables_api.c:6032<br /> nfnetlink_rcv_batch+0x1710/0x25f0 net/netfilter/nfnetlink.c:513<br /> nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline]<br /> nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:652<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix READDIR buffer overflow<br /> <br /> If a client sends a READDIR count argument that is too small (say,<br /> zero), then the buffer size calculation in the new init_dirlist<br /> helper functions results in an underflow, allowing the XDR stream<br /> functions to write beyond the actual buffer.<br /> <br /> This calculation has always been suspect. NFSD has never sanity-<br /> checked the READDIR count argument, but the old entry encoders<br /> managed the problem correctly.<br /> <br /> With the commits below, entry encoding changed, exposing the<br /> underflow to the pointer arithmetic in xdr_reserve_space().<br /> <br /> Modern NFS clients attempt to retrieve as much data as possible<br /> for each READDIR request. Also, we have no unit tests that<br /> exercise the behavior of READDIR at the lower bound of @count<br /> values. Thus this case was missed during testing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf<br /> <br /> In commit 41ca9caaae0b<br /> ("drm/mediatek: hdmi: Add check for CEA modes only") a check<br /> for CEA modes was added to function mtk_hdmi_bridge_mode_valid()<br /> in order to address possible issues on MT8167;<br /> moreover, with commit c91026a938c2<br /> ("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode clock")<br /> another similar check was introduced.<br /> <br /> Unfortunately though, at the time of writing, MT8173 does not provide<br /> any mtk_hdmi_conf structure and this is crashing the kernel with NULL<br /> pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as<br /> soon as a HDMI cable gets plugged in.<br /> <br /> To fix this regression, add a NULL pointer check for hdmi-&gt;conf in the<br /> said function, restoring HDMI functionality and avoiding NULL pointer<br /> kernel panics.

IBM Connect:Express for UNIX 1.5.0 is vulnerable to a buffer overflow that could allow a remote attacker to cause a denial of service through its browser UI. IBM X-Force ID: 254979.

In JetBrains TeamCity before 2023.11.4 authentication bypass allowing to perform admin actions was possible

In JetBrains TeamCity before 2023.11.4 path traversal allowing to perform limited admin actions was possible

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: elantech - fix stack out of bound access in elantech_change_report_id()<br /> <br /> The array param[] in elantech_change_report_id() must be at least 3<br /> bytes, because elantech_read_reg_params() is calling ps2_command() with<br /> PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but<br /> it&amp;#39;s defined in the stack as an array of 2 bytes, therefore we have a<br /> potential stack out-of-bounds access here, also confirmed by KASAN:<br /> <br /> [ 6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0<br /> [ 6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118<br /> <br /> [ 6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110<br /> [ 6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020<br /> [ 6.512436] Workqueue: events_long serio_handle_event<br /> [ 6.512453] Call Trace:<br /> [ 6.512462] show_stack+0x52/0x58<br /> [ 6.512474] dump_stack+0xa1/0xd3<br /> [ 6.512487] print_address_description.constprop.0+0x1d/0x140<br /> [ 6.512502] ? __ps2_command+0x372/0x7e0<br /> [ 6.512516] __kasan_report.cold+0x7d/0x112<br /> [ 6.512527] ? _raw_write_lock_irq+0x20/0xd0<br /> [ 6.512539] ? __ps2_command+0x372/0x7e0<br /> [ 6.512552] kasan_report+0x3c/0x50<br /> [ 6.512564] __asan_load1+0x6a/0x70<br /> [ 6.512575] __ps2_command+0x372/0x7e0<br /> [ 6.512589] ? ps2_drain+0x240/0x240<br /> [ 6.512601] ? dev_printk_emit+0xa2/0xd3<br /> [ 6.512612] ? dev_vprintk_emit+0xc5/0xc5<br /> [ 6.512621] ? __kasan_check_write+0x14/0x20<br /> [ 6.512634] ? mutex_lock+0x8f/0xe0<br /> [ 6.512643] ? __mutex_lock_slowpath+0x20/0x20<br /> [ 6.512655] ps2_command+0x52/0x90<br /> [ 6.512670] elantech_ps2_command+0x4f/0xc0 [psmouse]<br /> [ 6.512734] elantech_change_report_id+0x1e6/0x256 [psmouse]<br /> [ 6.512799] ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse]<br /> [ 6.512863] ? ps2_command+0x7f/0x90<br /> [ 6.512877] elantech_query_info.cold+0x6bd/0x9ed [psmouse]<br /> [ 6.512943] ? elantech_setup_ps2+0x460/0x460 [psmouse]<br /> [ 6.513005] ? psmouse_reset+0x69/0xb0 [psmouse]<br /> [ 6.513064] ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse]<br /> [ 6.513122] ? phys_pmd_init+0x30e/0x521<br /> [ 6.513137] elantech_init+0x8a/0x200 [psmouse]<br /> [ 6.513200] ? elantech_init_ps2+0xf0/0xf0 [psmouse]<br /> [ 6.513249] ? elantech_query_info+0x440/0x440 [psmouse]<br /> [ 6.513296] ? synaptics_send_cmd+0x60/0x60 [psmouse]<br /> [ 6.513342] ? elantech_query_info+0x440/0x440 [psmouse]<br /> [ 6.513388] ? psmouse_try_protocol+0x11e/0x170 [psmouse]<br /> [ 6.513432] psmouse_extensions+0x65d/0x6e0 [psmouse]<br /> [ 6.513476] ? psmouse_try_protocol+0x170/0x170 [psmouse]<br /> [ 6.513519] ? mutex_unlock+0x22/0x40<br /> [ 6.513526] ? ps2_command+0x7f/0x90<br /> [ 6.513536] ? psmouse_probe+0xa3/0xf0 [psmouse]<br /> [ 6.513580] psmouse_switch_protocol+0x27d/0x2e0 [psmouse]<br /> [ 6.513624] psmouse_connect+0x272/0x530 [psmouse]<br /> [ 6.513669] serio_driver_probe+0x55/0x70<br /> [ 6.513679] really_probe+0x190/0x720<br /> [ 6.513689] driver_probe_device+0x160/0x1f0<br /> [ 6.513697] device_driver_attach+0x119/0x130<br /> [ 6.513705] ? device_driver_attach+0x130/0x130<br /> [ 6.513713] __driver_attach+0xe7/0x1a0<br /> [ 6.513720] ? device_driver_attach+0x130/0x130<br /> [ 6.513728] bus_for_each_dev+0xfb/0x150<br /> [ 6.513738] ? subsys_dev_iter_exit+0x10/0x10<br /> [ 6.513748] ? _raw_write_unlock_bh+0x30/0x30<br /> [ 6.513757] driver_attach+0x2d/0x40<br /> [ 6.513764] serio_handle_event+0x199/0x3d0<br /> [ 6.513775] process_one_work+0x471/0x740<br /> [ 6.513785] worker_thread+0x2d2/0x790<br /> [ 6.513794] ? process_one_work+0x740/0x740<br /> [ 6.513802] kthread+0x1b4/0x1e0<br /> [ 6.513809] ? set_kthread_struct+0x80/0x80<br /> [ 6.513816] ret_from_fork+0x22/0x30<br /> <br /> [ 6.513832] The buggy address belongs to the page:<br /> [ 6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7<br /> [ 6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)<br /> [ 6.513860] raw: 0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations<br /> <br /> Commit b50aa49638c7 ("hwmon: (lm90) Prevent integer underflows of<br /> temperature calculations") addressed a number of underflow situations<br /> when writing temperature limits. However, it missed one situation, seen<br /> when an attempt is made to set the hysteresis value to MAX_LONG and the<br /> critical temperature limit is negative.<br /> <br /> Use clamp_val() when setting the hysteresis temperature to ensure that<br /> the provided value can never overflow or underflow.