Vulnerabilities

An issue was discovered on Marbella KR8s Dashcam FF 2.0.8 devices. Via port 7777 without any need to pair or press a physical button, a remote attacker can disable recording, delete recordings, or even disable battery protection to cause a flat battery to essentially disable the car from being used. During the process of changing these settings, there are no indications or sounds on the dashcam to alert the dashcam owner that someone else is making those changes.

A server-side request forgery vulnerability exists in the cecho.php functionality of MedDream PACS Premium 7.3.5.860. A specially crafted HTTP request can lead to SSRF. An attacker can make an unauthenticated HTTP request to trigger this vulnerability.

A flaw was found in GLib. A denial of service on Windows platforms may occur if an application attempts to spawn a program using long command lines.

In Malwarebytes Binisoft Windows Firewall Control before 6.16.0.0, the installer is vulnerable to local privilege escalation.

A vulnerability, which was classified as problematic, has been found in bsc Peru Cocktails App 1.0.0 on Android. Affected by this issue is some unknown functionality of the file AndroidManifest.xml of the component bsc.devy.peru_cocktails. The manipulation leads to improper export of android application components. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.

Incorrect Use of Privileged APIs vulnerability in Beamsec PhishPro allows Privilege Abuse.This issue affects PhishPro: before 7.5.4.2.

A vulnerability classified as critical was found in Campcodes Online Recruitment Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /admin/ajax.php?action=save_recruitment_status. The manipulation of the argument ID leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: ensure the allocated report buffer can contain the reserved report ID<br /> <br /> When the report ID is not used, the low level transport drivers expect<br /> the first byte to be 0. However, currently the allocated buffer not<br /> account for that extra byte, meaning that instead of having 8 guaranteed<br /> bytes for implement to be working, we only have 7.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: configfs: Fix OOB read on empty string write<br /> <br /> When writing an empty string to either &amp;#39;qw_sign&amp;#39; or &amp;#39;landingPage&amp;#39;<br /> sysfs attributes, the store functions attempt to access page[l - 1]<br /> before validating that the length &amp;#39;l&amp;#39; is greater than zero.<br /> <br /> This patch fixes the vulnerability by adding a check at the beginning<br /> of os_desc_qw_sign_store() and webusb_landingPage_store() to handle<br /> the zero-length input case gracefully by returning immediately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: libwx: remove duplicate page_pool_put_full_page()<br /> <br /> page_pool_put_full_page() should only be invoked when freeing Rx buffers<br /> or building a skb if the size is too short. At other times, the pages<br /> need to be reused. So remove the redundant page put. In the original<br /> code, double free pages cause kernel panic:<br /> <br /> [ 876.949834] __irq_exit_rcu+0xc7/0x130<br /> [ 876.949836] common_interrupt+0xb8/0xd0<br /> [ 876.949838] <br /> [ 876.949838] <br /> [ 876.949840] asm_common_interrupt+0x22/0x40<br /> [ 876.949841] RIP: 0010:cpuidle_enter_state+0xc2/0x420<br /> [ 876.949843] Code: 00 00 e8 d1 1d 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 cd fc 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d<br /> [ 876.949844] RSP: 0018:ffffaa7340267e78 EFLAGS: 00000246<br /> [ 876.949845] RAX: ffff9e3f135be000 RBX: 0000000000000002 RCX: 0000000000000000<br /> [ 876.949846] RDX: 000000cc2dc4cb7c RSI: ffffffff89ee49ae RDI: ffffffff89ef9f9e<br /> [ 876.949847] RBP: ffff9e378f940800 R08: 0000000000000002 R09: 00000000000000ed<br /> [ 876.949848] R10: 000000000000afc8 R11: ffff9e3e9e5a9b6c R12: ffffffff8a6d8580<br /> [ 876.949849] R13: 000000cc2dc4cb7c R14: 0000000000000002 R15: 0000000000000000<br /> [ 876.949852] ? cpuidle_enter_state+0xb3/0x420<br /> [ 876.949855] cpuidle_enter+0x29/0x40<br /> [ 876.949857] cpuidle_idle_call+0xfd/0x170<br /> [ 876.949859] do_idle+0x7a/0xc0<br /> [ 876.949861] cpu_startup_entry+0x25/0x30<br /> [ 876.949862] start_secondary+0x117/0x140<br /> [ 876.949864] common_startup_64+0x13e/0x148<br /> [ 876.949867] <br /> [ 876.949868] ---[ end trace 0000000000000000 ]---<br /> [ 876.949869] ------------[ cut here ]------------<br /> [ 876.949870] list_del corruption, ffffead40445a348-&gt;next is NULL<br /> [ 876.949873] WARNING: CPU: 14 PID: 0 at lib/list_debug.c:52 __list_del_entry_valid_or_report+0x67/0x120<br /> [ 876.949875] Modules linked in: snd_hrtimer(E) bnep(E) binfmt_misc(E) amdgpu(E) squashfs(E) vfat(E) loop(E) fat(E) amd_atl(E) snd_hda_codec_realtek(E) intel_rapl_msr(E) snd_hda_codec_generic(E) intel_rapl_common(E) snd_hda_scodec_component(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) edac_mce_amd(E) snd_intel_dspcfg(E) snd_hda_codec(E) snd_hda_core(E) amdxcp(E) kvm_amd(E) snd_hwdep(E) gpu_sched(E) drm_panel_backlight_quirks(E) cec(E) snd_pcm(E) drm_buddy(E) snd_seq_dummy(E) drm_ttm_helper(E) btusb(E) kvm(E) snd_seq_oss(E) btrtl(E) ttm(E) btintel(E) snd_seq_midi(E) btbcm(E) drm_exec(E) snd_seq_midi_event(E) i2c_algo_bit(E) snd_rawmidi(E) bluetooth(E) drm_suballoc_helper(E) irqbypass(E) snd_seq(E) ghash_clmulni_intel(E) sha512_ssse3(E) drm_display_helper(E) aesni_intel(E) snd_seq_device(E) rfkill(E) snd_timer(E) gf128mul(E) drm_client_lib(E) drm_kms_helper(E) snd(E) i2c_piix4(E) joydev(E) soundcore(E) wmi_bmof(E) ccp(E) k10temp(E) i2c_smbus(E) gpio_amdpt(E) i2c_designware_platform(E) gpio_generic(E) sg(E)<br /> [ 876.949914] i2c_designware_core(E) sch_fq_codel(E) parport_pc(E) drm(E) ppdev(E) lp(E) parport(E) fuse(E) nfnetlink(E) ip_tables(E) ext4 crc16 mbcache jbd2 sd_mod sfp mdio_i2c i2c_core txgbe ahci ngbe pcs_xpcs libahci libwx r8169 phylink libata realtek ptp pps_core video wmi<br /> [ 876.949933] CPU: 14 UID: 0 PID: 0 Comm: swapper/14 Kdump: loaded Tainted: G W E 6.16.0-rc2+ #20 PREEMPT(voluntary)<br /> [ 876.949935] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE<br /> [ 876.949936] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024<br /> [ 876.949936] RIP: 0010:__list_del_entry_valid_or_report+0x67/0x120<br /> [ 876.949938] Code: 00 00 00 48 39 7d 08 0f 85 a6 00 00 00 5b b8 01 00 00 00 5d 41 5c e9 73 0d 93 ff 48 89 fe 48 c7 c7 a0 31 e8 89 e8 59 7c b3 ff 0b 31 c0 5b 5d 41 5c e9 57 0d 93 ff 48 89 fe 48 c7 c7 c8 31 e8<br /> [ 876.949940] RSP: 0018:ffffaa73405d0c60 EFLAGS: 00010282<br /> [ 876.949941] RAX: 0000000000000000 RBX: ffffead40445a348 RCX: 0000000000000000<br /> [ 876.949942] RDX: 0000000000000105 RSI: 00000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix race between cache write completion and ALL_QUEUED being set<br /> <br /> When netfslib is issuing subrequests, the subrequests start processing<br /> immediately and may complete before we reach the end of the issuing<br /> function. At the end of the issuing function we set NETFS_RREQ_ALL_QUEUED<br /> to indicate to the collector that we aren&amp;#39;t going to issue any more subreqs<br /> and that it can do the final notifications and cleanup.<br /> <br /> Now, this isn&amp;#39;t a problem if the request is synchronous<br /> (NETFS_RREQ_OFFLOAD_COLLECTION is unset) as the result collection will be<br /> done in-thread and we&amp;#39;re guaranteed an opportunity to run the collector.<br /> <br /> However, if the request is asynchronous, collection is primarily triggered<br /> by the termination of subrequests queuing it on a workqueue. Now, a race<br /> can occur here if the app thread sets ALL_QUEUED after the last subrequest<br /> terminates.<br /> <br /> This can happen most easily with the copy2cache code (as used by Ceph)<br /> where, in the collection routine of a read request, an asynchronous write<br /> request is spawned to copy data to the cache. Folios are added to the<br /> write request as they&amp;#39;re unlocked, but there may be a delay before<br /> ALL_QUEUED is set as the write subrequests may complete before we get<br /> there.<br /> <br /> If all the write subreqs have finished by the ALL_QUEUED point, no further<br /> events happen and the collection never happens, leaving the request<br /> hanging.<br /> <br /> Fix this by queuing the collector after setting ALL_QUEUED. This is a bit<br /> heavy-handed and it may be sufficient to do it only if there are no extant<br /> subreqs.<br /> <br /> Also add a tracepoint to cross-reference both requests in a copy-to-request<br /> operation and add a trace to the netfs_rreq tracepoint to indicate the<br /> setting of ALL_QUEUED.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/osnoise: Fix crash in timerlat_dump_stack()<br /> <br /> We have observed kernel panics when using timerlat with stack saving,<br /> with the following dmesg output:<br /> <br /> memcpy: detected buffer overflow: 88 byte write of buffer size 0<br /> WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0<br /> CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy)<br /> Call Trace:<br /> <br /> ? trace_buffer_lock_reserve+0x2a/0x60<br /> __fortify_panic+0xd/0xf<br /> __timerlat_dump_stack.cold+0xd/0xd<br /> timerlat_dump_stack.part.0+0x47/0x80<br /> timerlat_fd_read+0x36d/0x390<br /> vfs_read+0xe2/0x390<br /> ? syscall_exit_to_user_mode+0x1d5/0x210<br /> ksys_read+0x73/0xe0<br /> do_syscall_64+0x7b/0x160<br /> ? exc_page_fault+0x7e/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> __timerlat_dump_stack() constructs the ftrace stack entry like this:<br /> <br /> struct stack_entry *entry;<br /> ...<br /> memcpy(&amp;entry-&gt;caller, fstack-&gt;calls, size);<br /> entry-&gt;size = fstack-&gt;nr_entries;<br /> <br /> Since commit e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to<br /> kernel_stack event structure"), struct stack_entry marks its caller<br /> field with __counted_by(size). At the time of the memcpy, entry-&gt;size<br /> contains garbage from the ringbuffer, which under some circumstances is<br /> zero, triggering a kernel panic by buffer overflow.<br /> <br /> Populate the size field before the memcpy so that the out-of-bounds<br /> check knows the correct size. This is analogous to<br /> __ftrace_trace_stack().