Vulnerabilities

Westermo EDW-100 devices through 2024-05-03 allow an unauthenticated user to download a configuration file containing a cleartext password. NOTE: this is a serial-to-Ethernet converter that should not be placed at the edge of the network.

Cross-Site WebSocket Hijacking in SysReptor from version 2024.28 to version 2024.30 causes attackers to escalate privileges and obtain sensitive information when a logged-in SysReptor user visits a malicious same-site subdomain in the same browser session.

tine before 2023.11.8, when an LDAP backend is used, allows anonymous remote attackers to obtain sensitive authentication information via setup.php because of getRegistryData in Setup/Frontend/Json.php. (An update is also available for the 2022.11 series.)

In the mintupload package through 4.2.0 for Linux Mint, service-name mishandling leads to command injection via shell metacharacters in check_connection, drop_data_received_cb, and Service.remove. A user can modify a service name in a ~/.linuxmint/mintUpload/services/service file.

A vulnerability was found in SourceCodester Simple Inventory System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file updateproduct.php. The manipulation of the argument ITEM leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-265084.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dyndbg: fix old BUG_ON in &gt;control parser<br /> <br /> Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn&amp;#39;t<br /> really look), lets make sure by removing it, doing pr_err and return<br /> -EINVAL instead.

A vulnerability was found in SourceCodester Simple Inventory System 1.0. It has been classified as critical. This affects an unknown part of the file tableedit.php. The manipulation of the argument from/to leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-265083.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: phy_device: Prevent nullptr exceptions on ISR<br /> <br /> If phydev-&gt;irq is set unconditionally, check<br /> for valid interrupt handler or fall back to polling mode to prevent<br /> nullptr exceptions in interrupt service routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: fix null pointer access when abort scan<br /> <br /> During cancel scan we might use vif that weren&amp;#39;t scanning.<br /> Fix this by using the actual scanning vif.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()<br /> <br /> Syzkaller hit &amp;#39;WARNING in dg_dispatch_as_host&amp;#39; bug.<br /> <br /> memcpy: detected field-spanning write (size 56) of single field "&amp;dg_info-&gt;msg"<br /> at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)<br /> <br /> WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237<br /> dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237<br /> <br /> Some code commentry, based on my understanding:<br /> <br /> 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)-&gt;payload_size)<br /> /// This is 24 + payload_size<br /> <br /> memcpy(&amp;dg_info-&gt;msg, dg, dg_size);<br /> Destination = dg_info-&gt;msg ---&gt; this is a 24 byte<br /> structure(struct vmci_datagram)<br /> Source = dg --&gt; this is a 24 byte structure (struct vmci_datagram)<br /> Size = dg_size = 24 + payload_size<br /> <br /> {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.<br /> <br /> 35 struct delayed_datagram_info {<br /> 36 struct datagram_entry *entry;<br /> 37 struct work_struct work;<br /> 38 bool in_dg_host_queue;<br /> 39 /* msg and msg_payload must be together. */<br /> 40 struct vmci_datagram msg;<br /> 41 u8 msg_payload[];<br /> 42 };<br /> <br /> So those extra bytes of payload are copied into msg_payload[], a run time<br /> warning is seen while fuzzing with Syzkaller.<br /> <br /> One possible way to fix the warning is to split the memcpy() into<br /> two parts -- one -- direct assignment of msg and second taking care of payload.<br /> <br /> Gustavo quoted:<br /> "Under FORTIFY_SOURCE we should not copy data across multiple members<br /> in a structure."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()<br /> <br /> The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an<br /> unsuccessful status. In such cases, the elsiocb is not issued, the<br /> completion is not called, and thus the elsiocb resource is leaked.<br /> <br /> Check return value after calling lpfc_sli4_resume_rpi() and conditionally<br /> release the elsiocb resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Skip do PCI error slot reset during RAS recovery<br /> <br /> Why:<br /> The PCI error slot reset maybe triggered after inject ue to UMC multi times, this<br /> caused system hang.<br /> [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume<br /> [ 557.373718] [drm] PCIE GART of 512M enabled.<br /> [ 557.373722] [drm] PTB located at 0x0000031FED700000<br /> [ 557.373788] [drm] VRAM is lost due to GPU reset!<br /> [ 557.373789] [drm] PSP is resuming...<br /> [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset<br /> [ 557.547067] [drm] PCI error: detected callback, state(1)!!<br /> [ 557.547069] [drm] No support for XGMI hive yet...<br /> [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter<br /> [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations<br /> [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered<br /> [ 557.610492] [drm] PCI error: slot reset callback!!<br /> ...<br /> [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!<br /> [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!<br /> [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI<br /> [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu<br /> [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023<br /> [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]<br /> [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]<br /> [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00<br /> [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202<br /> [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0<br /> [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010<br /> [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08<br /> [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000<br /> [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000<br /> [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000<br /> [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0<br /> [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 560.843444] PKRU: 55555554<br /> [ 560.846480] Call Trace:<br /> [ 560.849225] <br /> [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea<br /> [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea<br /> [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]<br /> [ 560.867778] ? show_regs.part.0+0x23/0x29<br /> [ 560.872293] ? __die_body.cold+0x8/0xd<br /> [ 560.876502] ? die_addr+0x3e/0x60<br /> [ 560.880238] ? exc_general_protection+0x1c5/0x410<br /> [ 560.885532] ? asm_exc_general_protection+0x27/0x30<br /> [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]<br /> [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]<br /> [ 560.904520] process_one_work+0x228/0x3d0<br /> How:<br /> In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected<br /> all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.