|
|
Search Results
There are 34 CVE Records that match your search.
| Name | Description |
|---|---|
| CVE-2024-8258 | Improper Control of Generation of Code ('Code Injection') in Electron Fuses in Logitech Options Plus version 1.60.496306 on macOS allows attackers to execute arbitrary code via insecure Electron Fuses configuration. |
| CVE-2024-8011 | Logitech Options+ on MacOS prior 1.72 allows a local attacker to inject dynamic library within Options+ runtime and abuse permissions granted by the user to Options+ such as Camera. |
| CVE-2024-40934 | In the Linux kernel, the following vulnerability has been resolved: HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode() Fix a memory leak on logi_dj_recv_send_report() error path. |
| CVE-2024-4031 | Unquoted Search Path or Element vulnerability in Logitech MEVO WEBCAM APP on Windows allows Local Execution of Code. |
| CVE-2024-35932 | In the Linux kernel, the following vulnerability has been resolved: drm/vc4: don't check if plane->state->fb == state->fb Currently, when using non-blocking commits, we can see the following kernel warning: [ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]--- This happens because, although `prepare_fb` and `cleanup_fb` are perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The opposite can also be true. In fact, the struct drm_plane .state shouldn't be accessed directly but instead, the `drm_atomic_get_new_plane_state()` helper function should be used. So, we could stick to this check, but using `drm_atomic_get_new_plane_state()`. But actually, this check is not re ---truncated--- |
| CVE-2024-2537 | Improper Control of Dynamically-Managed Code Resources vulnerability in Logitech Logi Tune on MacOS allows Local Code Inclusion. |
| CVE-2023-52478 | In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- |
| CVE-2022-46338 | g810-led 0.4.2, a LED configuration tool for Logitech Gx10 keyboards, contained a udev rule to make supported device nodes world-readable and writable, allowing any process on the system to read traffic from keyboards, including sensitive data. |
| CVE-2022-0916 | An issue was discovered in Logitech Options. The OAuth 2.0 state parameter was not properly validated. This leaves applications vulnerable to CSRF attacks during authentication and authorization operations. |
| CVE-2022-0915 | There is a Time-of-check Time-of-use (TOCTOU) Race Condition Vulnerability in Logitech Sync for Windows prior to 2.4.574. Successful exploitation of these vulnerabilities may escalate the permission to the system user. |
| CVE-2021-38547 | Logitech Z120 and S120 speakers through 2021-08-09 allow remote attackers to recover speech signals from an LED on the device, via a telescope and an electro-optical sensor, aka a "Glowworm" attack. The power indicator LED of the speakers is connected directly to the power line, as a result, the intensity of a device's power indicator LED is correlative to the power consumption. The sound played by the speakers affects their power consumption and as a result is also correlative to the light intensity of the LEDs. By analyzing measurements obtained from an electro-optical sensor directed at the power indicator LEDs of the speakers, we can recover the sound played by them. |
| CVE-2019-19532 | In the Linux kernel before 5.3.9, there are multiple out-of-bounds write bugs that can be caused by a malicious USB device in the Linux kernel HID drivers, aka CID-d9d4b1e46d95. This affects drivers/hid/hid-axff.c, drivers/hid/hid-dr.c, drivers/hid/hid-emsff.c, drivers/hid/hid-gaff.c, drivers/hid/hid-holtekff.c, drivers/hid/hid-lg2ff.c, drivers/hid/hid-lg3ff.c, drivers/hid/hid-lg4ff.c, drivers/hid/hid-lgff.c, drivers/hid/hid-logitech-hidpp.c, drivers/hid/hid-microsoft.c, drivers/hid/hid-sony.c, drivers/hid/hid-tmff.c, and drivers/hid/hid-zpff.c. |
| CVE-2019-13055 | Certain Logitech Unifying devices allow attackers to dump AES keys and addresses, leading to the capability of live decryption of Radio Frequency transmissions, as demonstrated by an attack against a Logitech K360 keyboard. |
| CVE-2019-13054 | The Logitech R500 presentation clicker allows attackers to determine the AES key, leading to keystroke injection. On Windows, any text may be injected by using ALT+NUMPAD input to bypass the restriction on the characters A through Z. |
| CVE-2019-13053 | Logitech Unifying devices allow keystroke injection, bypassing encryption. The attacker must press a "magic" key combination while sniffing cryptographic data from a Radio Frequency transmission. NOTE: this issue exists because of an incomplete fix for CVE-2016-10761. |
| CVE-2019-13052 | Logitech Unifying devices allow live decryption if the pairing of a keyboard to a receiver is sniffed. |
| CVE-2019-12506 | Due to unencrypted and unauthenticated data communication, the wireless presenter Logitech R700 Laser Presentation Remote R-R0010 is prone to keystroke injection attacks. Thus, an attacker is able to send arbitrary keystrokes to a victim's computer system, e.g., to install malware when the target system is unattended. In this way, an attacker can remotely take control over the victim's computer that is operated with an affected receiver of this device. |
| CVE-2018-15723 | The Logitech Harmony Hub before version 4.15.206 is vulnerable to application level command injection via crafted HTTP request. An unauthenticated remote attacker can leverage this vulnerability to execute application defined commands (e.g. harmony.system?systeminfo). |
| CVE-2018-15722 | The Logitech Harmony Hub before version 4.15.206 is vulnerable to OS command injection via the time update request. A remote server or man in the middle can inject OS commands with a properly formatted response. |
| CVE-2018-15721 | The XMPP server in Logitech Harmony Hub before version 4.15.206 is vulnerable to authentication bypass via a crafted XMPP request. Remote attackers can use this vulnerability to gain access to the local API. |
| CVE-2018-15720 | Logitech Harmony Hub before version 4.15.206 contained two hard-coded accounts in the XMPP server that gave remote users access to the local API. |
| CVE-2017-16568 | Cross-site scripting (XSS) vulnerability in Logitech Media Server 7.9.0 allows remote attackers to inject arbitrary web script or HTML via a radio URL. |
| CVE-2017-16567 | Cross-site scripting (XSS) vulnerability in Logitech Media Server 7.9.0 allows remote attackers to inject arbitrary web script or HTML via a "favorite." |
| CVE-2017-15687 | DOM Based Cross Site Scripting (XSS) exists in Logitech Media Server 7.7.1, 7.7.2, 7.7.3, 7.7.5, 7.7.6, 7.9.0, and 7.9.1 via a crafted URI. |
| CVE-2016-7915 | The hid_input_field function in drivers/hid/hid-core.c in the Linux kernel before 4.6 allows physically proximate attackers to obtain sensitive information from kernel memory or cause a denial of service (out-of-bounds read) by connecting a device, as demonstrated by a Logitech DJ receiver. |
| CVE-2016-10761 | Logitech Unifying devices before 2016-02-26 allow keystroke injection, bypassing encryption, aka MouseJack. |
| CVE-2014-3183 | Heap-based buffer overflow in the logi_dj_ll_raw_request function in drivers/hid/hid-logitech-dj.c in the Linux kernel before 3.16.2 allows physically proximate attackers to cause a denial of service (system crash) or possibly execute arbitrary code via a crafted device that specifies a large report size for an LED report. |
| CVE-2014-3182 | Array index error in the logi_dj_raw_event function in drivers/hid/hid-logitech-dj.c in the Linux kernel before 3.16.2 allows physically proximate attackers to execute arbitrary code or cause a denial of service (invalid kfree) via a crafted device that provides a malformed REPORT_TYPE_NOTIF_DEVICE_UNPAIRED value. |
| CVE-2013-2895 | drivers/hid/hid-logitech-dj.c in the Human Interface Device (HID) subsystem in the Linux kernel through 3.11, when CONFIG_HID_LOGITECH_DJ is enabled, allows physically proximate attackers to cause a denial of service (NULL pointer dereference and OOPS) or obtain sensitive information from kernel memory via a crafted device. |
| CVE-2013-2893 | The Human Interface Device (HID) subsystem in the Linux kernel through 3.11, when CONFIG_LOGITECH_FF, CONFIG_LOGIG940_FF, or CONFIG_LOGIWHEELS_FF is enabled, allows physically proximate attackers to cause a denial of service (heap-based out-of-bounds write) via a crafted device, related to (1) drivers/hid/hid-lgff.c, (2) drivers/hid/hid-lg3ff.c, and (3) drivers/hid/hid-lg4ff.c. |
| CVE-2008-0956 | Multiple stack-based buffer overflows in the BackWeb Lite Install Runner ActiveX control in the BackWeb Web Package ActiveX object in LiteInstActivator.dll in BackWeb before 8.1.1.87, as used in Logitech Desktop Manager (LDM) before 2.56, allow remote attackers to execute arbitrary code via unspecified vectors. |
| CVE-2007-2918 | Multiple stack-based buffer overflows in ActiveX controls (1) VibeC in (a) vibecontrol.dll, (2) CallManager and (3) ViewerClient in (b) StarClient.dll, (4) ComLink in (c) uicomlink.dll, and (5) WebCamXMP in (d) wcamxmp.dll in Logitech VideoCall allow remote attackers to cause a denial of service (browser crash) and execute arbitrary code via unspecified vectors. |
| CVE-2002-1722 | Logitech iTouch keyboards allows attackers with physical access to the system to bypass the screen locking function and execute user-defined commands that have been assigned to a button. |
| CVE-2001-0737 | A long 'synch' delay in Logitech wireless mice and keyboard receivers allows a remote attacker to hijack connections via a man-in-the-middle attack. |
|
You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select “Other” from dropdown)
|
||
