Search Results
There are 30 CVE Records that match your search.
| Name | Description |
|---|---|
| CVE-2024-4031 | Unquoted Search Path or Element vulnerability in Logitech MEVO WEBCAM APP on Windows allows Local Execution of Code. |
| 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)
|
||
