Vulnerabilities

Directory Traversal vulnerability in codesiddhant Jasmin Ransomware v.1.0.1 allows an attacker to obtain sensitive information via the download_file.php component.

There is a ClusterRole in piraeus-operator v2.5.0 and earlier which has been granted list secrets permission, which allows an attacker to impersonate the service account bound to this ClusterRole and use its high-risk privileges to list confidential information across the cluster.

An issue was discovered in the Bouncy Castle Crypto Package For Java before BC TLS Java 1.0.19 (ships with BC Java 1.78, BC Java (LTS) 2.73.6) and before BC FIPS TLS Java 1.0.19. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.

Vditor 3.10.3 allows XSS via an attribute of an A element. NOTE: the vendor indicates that a user is supposed to mitigate this via sanitize=true.

IBM Aspera Orchestrator 4.0.1 could allow a remote authenticated attacker to execute arbitrary commands on the system by sending a specially crafted request. IBM X-Force ID: 260116.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap: spi: Reserve space for register address/padding<br /> <br /> Currently the max_raw_read and max_raw_write limits in regmap_spi struct<br /> do not take into account the additional size of the transmitted register<br /> address and padding. This may result in exceeding the maximum permitted<br /> SPI message size, which could cause undefined behaviour, e.g. data<br /> corruption.<br /> <br /> Fix regmap_get_spi_bus() to properly adjust the above mentioned limits<br /> by reserving space for the register address/padding as set in the regmap<br /> configuration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix a use-after-free<br /> <br /> Fix the following use-after-free complaint triggered by blktests nvme/004:<br /> <br /> BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350<br /> Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460<br /> Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]<br /> Call Trace:<br /> show_stack+0x52/0x58<br /> dump_stack_lvl+0x49/0x5e<br /> print_report.cold+0x36/0x1e2<br /> kasan_report+0xb9/0xf0<br /> __asan_load4+0x6b/0x80<br /> blk_mq_complete_request_remote+0xac/0x350<br /> nvme_loop_queue_response+0x1df/0x275 [nvme_loop]<br /> __nvmet_req_complete+0x132/0x4f0 [nvmet]<br /> nvmet_req_complete+0x15/0x40 [nvmet]<br /> nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]<br /> nvme_loop_execute_work+0x20/0x30 [nvme_loop]<br /> process_one_work+0x56e/0xa70<br /> worker_thread+0x2d1/0x640<br /> kthread+0x183/0x1c0<br /> ret_from_fork+0x1f/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix memory leak when using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. Fix this up by properly<br /> calling dput().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/debug: fix dentry leak in update_sched_domain_debugfs<br /> <br /> Kuyo reports that the pattern of using debugfs_remove(debugfs_lookup())<br /> leaks a dentry and with a hotplug stress test, the machine eventually<br /> runs out of memory.<br /> <br /> Fix this up by using the newly created debugfs_lookup_and_remove() call<br /> instead which properly handles the dentry reference counting logic.

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 /> ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface()<br /> <br /> There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and<br /> the number of it&amp;#39;s interfaces less than 4, an out-of-bounds read bug occurs<br /> when parsing the interface descriptor for this device.<br /> <br /> Fix this by checking the number of interfaces.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()<br /> <br /> The voice allocator sometimes begins allocating from near the end of the<br /> array and then wraps around, however snd_emu10k1_pcm_channel_alloc()<br /> accesses the newly allocated voices as if it never wrapped around.<br /> <br /> This results in out of bounds access if the first voice has a high enough<br /> index so that first_voice + requested_voice_count &gt; NUM_G (64).<br /> The more voices are requested, the more likely it is for this to occur.<br /> <br /> This was initially discovered using PipeWire, however it can be reproduced<br /> by calling aplay multiple times with 16 channels:<br /> aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero<br /> <br /> UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40<br /> index 65 is out of range for type &amp;#39;snd_emu10k1_voice [64]&amp;#39;<br /> CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7<br /> Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x49/0x63<br /> dump_stack+0x10/0x16<br /> ubsan_epilogue+0x9/0x3f<br /> __ubsan_handle_out_of_bounds.cold+0x44/0x49<br /> snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]<br /> snd_pcm_hw_params+0x29f/0x600 [snd_pcm]<br /> snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]<br /> ? exit_to_user_mode_prepare+0x35/0x170<br /> ? do_syscall_64+0x69/0x90<br /> ? syscall_exit_to_user_mode+0x26/0x50<br /> ? do_syscall_64+0x69/0x90<br /> ? exit_to_user_mode_prepare+0x35/0x170<br /> snd_pcm_ioctl+0x27/0x40 [snd_pcm]<br /> __x64_sys_ioctl+0x95/0xd0<br /> do_syscall_64+0x5c/0x90<br /> ? do_syscall_64+0x69/0x90<br /> ? do_syscall_64+0x69/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd