In affected versions of Octopus Server it is possible for target discovery to print certain values marked as sensitive to log files in plaint-text in when verbose logging is enabled.

Summary

Target Discovery prints certain sensitive values in plain-text when verbose logging is enabled (CVE-2022-2721)

Advisory Number

2022-24

Discovery Date

08 Aug 2022

Patch Release Date

21 Aug 2022

Advisory Release Date

25 Nov 2022

Product

Octopus Server

Operating System

Linux and Microsoft Windows

Severity

Medium

CVE ID

CVE-2022-2721

Customers who have downloaded and installed any of the Octopus Server versions listed below ("Details") are affected.

Please upgrade your Octopus Server immediately to fix this vulnerability.

Customers who have upgraded Octopus Server to version 2022.3.10807 or higher are not affected.

**Severity**

Octopus Deploy has given this vulnerability a medium rating. This rating was given according to the Octopus Deploy severity levels, which ranks vulnerabilities as critical, high, medium, or low severity.

This is our assessment and you should evaluate its applicability to your own environment.

**Details**

In affected versions of Octopus Server it is possible for target discovery to print certain values marked as sensitive to log files in plaint-text in when verbose logging is enabled

The versions of Octopus Server affected by this vulnerability are:

*   All 2022.2.x versions before 2022.2.7965
*   All 2022.3.x versions before 2022.3.9163

**Fix**

To address this vulnerability, we have released Octopus Server version:

*   2022.2.7965
*   2022.3.9163

The latest versions of Octopus Deploy products can be downloaded from https://octopus.com/downloads and previous versions can be downloaded from https://octopus.com/downloads/previous

**What You Need to Do**

Octopus Deploy recommends that you upgrade to the latest version (2022.3.10807). You can download the latest version of Octopus Server from https://octopus.com/downloads

**If you can't upgrade to the latest version (2022.3.10807):**

If you have feature version...

...then upgrade to this version

2022.2.x

2022.2.7965 or greater

2022.3.x

2022.3.9163 or greater

**Mitigation**

There is no known mitigation for CVE-2022-2721, it is important to upgrade to a fixed version as soon as possible.

**Support**

If you have any questions or concerns regarding this advisory, please contact our support team https://octopus.com/support.

**Exploitation and Public Announcements**

The Octopus Deploy security team is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory.

**Source**

This vulnerability was found during internal testing by Matt Hilton at Octopus Deploy.

CVE-2022-2721: Security Advisory 2022-24

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

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.

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()

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/char/xillybus/xillyusb.c has a race condition and use-after-free during physical removal of a USB device.

From: Hyunwoo Kim <imv4bel@gmail.com>
To: eli.billauer@gmail.com, arnd@arndb.de, gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org
Subject: \[PATCH\] char: xillybus: Fix use-after-free in xillyusb\_open()
Date: Sat, 22 Oct 2022 10:54:04 -0700	\[thread overview\]
Message-ID: <20221022175404.GA375335@ubuntu> (raw)

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

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

So, add a mutex to the xillyusb\_open() and xillyusb\_disconnect()
functions to avoid race contidion.

Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
 drivers/char/xillybus/xillyusb.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/char/xillybus/xillyusb.c b/drivers/char/xillybus/xillyusb.c
index 39bcbfd908b4..d615f74dcf36 100644
--- a/drivers/char/xillybus/xillyusb.c
+++ b/drivers/char/xillybus/xillyusb.c
@@ -63,6 +63,7 @@ static const struct usb\_device\_id xillyusb\_table\[\] = {
 };
 
 MODULE\_DEVICE\_TABLE(usb, xillyusb\_table);
+static DEFINE\_MUTEX(disconnect\_mutex);
 
 struct xillyusb\_dev;
 
@@ -1237,9 +1238,13 @@ static int xillyusb\_open(struct inode \*inode, struct file \*filp)
 	int rc;
 	int index;
 
+	mutex\_lock(&disconnect\_mutex);
+
 	rc = xillybus\_find\_inode(inode, (void \*\*)&xdev, &index);
\-	if (rc)
+	if (rc) {
+		mutex\_unlock(&disconnect\_mutex);
 		return rc;
+	}
 
 	chan = &xdev->channels\[index\];
 	filp->private\_data = chan;
@@ -1379,6 +1384,8 @@ static int xillyusb\_open(struct inode \*inode, struct file \*filp)
 			request\_read\_anything(chan, OPCODE\_SET\_PUSH);
 	}
 
+	mutex\_unlock(&disconnect\_mutex);
+
 	return 0;
 
 unfifo:
@@ -1410,10 +1417,14 @@ static int xillyusb\_open(struct inode \*inode, struct file \*filp)
 
 	kref\_put(&xdev->kref, cleanup\_dev);
 
+	mutex\_unlock(&disconnect\_mutex);
+
 	return rc;
 
 unmutex\_fail:
 	mutex\_unlock(&chan->lock);
+	mutex\_unlock(&disconnect\_mutex);
+
 	return rc;
 }
 
@@ -1698,6 +1709,8 @@ static int xillyusb\_release(struct inode \*inode, struct file \*filp)
 	struct xillyusb\_dev \*xdev = chan->xdev;
 	int rc\_read = 0, rc\_write = 0;
 
+	mutex\_lock(&disconnect\_mutex);
+
 	if (filp->f\_mode & FMODE\_READ) {
 		struct xillyfifo \*in\_fifo = chan->in\_fifo;
 
@@ -1760,6 +1773,8 @@ static int xillyusb\_release(struct inode \*inode, struct file \*filp)
 
 	kref\_put(&xdev->kref, cleanup\_dev);
 
+	mutex\_unlock(&disconnect\_mutex);
+
 	return rc\_read ? rc\_read : rc\_write;
 }
 
@@ -2172,6 +2187,8 @@ static void xillyusb\_disconnect(struct usb\_interface \*interface)
 	int rc;
 	int i;
 
+	mutex\_lock(&disconnect\_mutex);
+
 	xillybus\_cleanup\_chrdev(xdev, &interface->dev);
 
 	/\*
@@ -2228,6 +2245,8 @@ static void xillyusb\_disconnect(struct usb\_interface \*interface)
 	xdev->dev = NULL;
 
 	kref\_put(&xdev->kref, cleanup\_dev);
+
+	mutex\_unlock(&disconnect\_mutex);
 }
 
 static struct usb\_driver xillyusb\_driver = {
-- 
2.25.1


Dear,


This race condition can occur in the flow of:
\`\`\`
 cpu0 cpu1
 1. xillyusb\_open()
 xillybus\_find\_inode()
 mutex\_lock(&unit\_mutex);
 unit = iter;
 mutex\_unlock(&unit\_mutex);
 2. xillyusb\_disconnect()
 xillybus\_cleanup\_chrdev()
 mutex\_lock(&unit\_mutex);
 kfree(unit);
 mutex\_unlock(&unit\_mutex);
 3. \*private\_data = unit->private\_data; // UAF

\`\`\`

Because the interval between 1 and 3 in xillyusb\_open() is very short, this race condition is usually rare.

However, if someone wants to trigger this UAF, they can use the technique presented in this paper:
https://www.usenix.org/system/files/sec21-lee-yoochan.pdf

This is a method to increase the execution time between No. 1 and No. 3 using the Reschedule IPI.
This means you will be able to trigger the UAF much more reliably.

Here is the KASAN log:
\`\`\`
\[ 66.645661\] ==================================================================
\[ 66.645678\] BUG: KASAN: use-after-free in xillybus\_find\_inode+0x2c6/0x2ea \[xillybus\_class\]
\[ 66.645712\] Read of size 8 at addr ffff88811eb45f90 by task xillyusb\_test/2143

\[ 66.645735\] CPU: 2 PID: 2143 Comm: xillyusb\_test Not tainted 6.1.0-rc1+ #10
\[ 66.645752\] Hardware name: Gigabyte Technology Co., Ltd. B460MDS3H/B460M DS3H, BIOS F3 05/27/2020
\[ 66.645762\] Call Trace:
\[ 66.645772\] <TASK>
\[ 66.645783\] dump\_stack\_lvl+0x49/0x63
\[ 66.645808\] print\_report+0x177/0x46e
\[ 66.645828\] ? kasan\_complete\_mode\_report\_info+0x7c/0x210
\[ 66.645846\] ? xillybus\_find\_inode+0x2c6/0x2ea \[xillybus\_class\]
\[ 66.645871\] kasan\_report+0xb0/0x140
\[ 66.645891\] ? xillybus\_find\_inode+0x2c6/0x2ea \[xillybus\_class\]
\[ 66.645917\] \_\_asan\_report\_load8\_noabort+0x14/0x20
\[ 66.645932\] xillybus\_find\_inode+0x2c6/0x2ea \[xillybus\_class\]
\[ 66.645960\] xillyusb\_open+0xa6/0x1030 \[xillyusb\]
\[ 66.645990\] ? endpoint\_alloc+0x6d0/0x6d0 \[xillyusb\]
\[ 66.646014\] ? \_\_kasan\_check\_write+0x14/0x20
\[ 66.646028\] ? \_raw\_spin\_lock+0x88/0xe0
\[ 66.646044\] ? try\_module\_get.part.0+0xb8/0x1a0
\[ 66.646062\] chrdev\_open+0x230/0x6d0
\[ 66.646082\] ? cdev\_device\_add+0x1f0/0x1f0
\[ 66.646099\] ? fsnotify\_perm.part.0+0x1d9/0x4e0
\[ 66.646118\] do\_dentry\_open+0x449/0x1000
\[ 66.646132\] ? inode\_permission+0x125/0x560
\[ 66.646148\] ? cdev\_device\_add+0x1f0/0x1f0
\[ 66.646167\] vfs\_open+0x9f/0xd0
\[ 66.646181\] path\_openat+0xd58/0x3eb0
\[ 66.646199\] ? kasan\_save\_alloc\_info+0x1e/0x30
\[ 66.646212\] ? \_\_kasan\_slab\_alloc+0x90/0xa0
\[ 66.646229\] ? kmem\_cache\_alloc+0x1f6/0x310
\[ 66.646244\] ? getname\_flags.part.0+0x52/0x490
\[ 66.646260\] ? getname+0x7a/0xb0
\[ 66.646275\] ? \_\_x64\_sys\_openat+0x128/0x210
\[ 66.646288\] ? do\_syscall\_64+0x59/0x90
\[ 66.646306\] ? path\_lookupat+0x660/0x660
\[ 66.646328\] do\_filp\_open+0x1b1/0x3e0
\[ 66.646344\] ? debug\_smp\_processor\_id+0x17/0x20
\[ 66.646363\] ? may\_open\_dev+0xd0/0xd0
\[ 66.646378\] ? getname\_flags.part.0+0x52/0x490
\[ 66.646399\] ? \_raw\_spin\_lock\_bh+0xe0/0xe0
\[ 66.646422\] do\_sys\_openat2+0x132/0x450
\[ 66.646435\] ? recalc\_sigpending+0x144/0x1c0
\[ 66.646450\] ? build\_open\_flags+0x450/0x450
\[ 66.646465\] ? sigprocmask+0x201/0x360
\[ 66.646478\] ? \_\_ia32\_sys\_ssetmask+0x1d0/0x1d0
\[ 66.646495\] \_\_x64\_sys\_openat+0x128/0x210
\[ 66.646509\] ? \_\_ia32\_compat\_sys\_open+0x1b0/0x1b0
\[ 66.646526\] ? debug\_smp\_processor\_id+0x17/0x20
\[ 66.646545\] do\_syscall\_64+0x59/0x90
\[ 66.646560\] ? syscall\_exit\_to\_user\_mode+0x26/0x50
\[ 66.646578\] ? do\_syscall\_64+0x69/0x90
\[ 66.646593\] ? debug\_smp\_processor\_id+0x17/0x20
\[ 66.646610\] ? fpregs\_assert\_state\_consistent+0x52/0xc0
\[ 66.646630\] ? exit\_to\_user\_mode\_prepare+0x49/0x1a0
\[ 66.646644\] ? syscall\_exit\_to\_user\_mode+0x26/0x50
\[ 66.646662\] ? do\_syscall\_64+0x69/0x90
\[ 66.646675\] ? exit\_to\_user\_mode\_prepare+0x16a/0x1a0
\[ 66.646689\] ? syscall\_exit\_to\_user\_mode+0x26/0x50
\[ 66.646706\] entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd
\[ 66.646722\] RIP: 0033:0x4534e4
\[ 66.646736\] Code: 24 20 eb 8f 66 90 44 89 54 24 0c e8 d6 ab 02 00 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 34 44 89 c7 89 44 24 0c e8 18 ac 02 00 8b 44
\[ 66.646751\] RSP: 002b:00007f8130000140 EFLAGS: 00000293 ORIG\_RAX: 0000000000000101
\[ 66.646771\] RAX: ffffffffffffffda RBX: 00007f8130000640 RCX: 00000000004534e4
\[ 66.646784\] RDX: 0000000000000000 RSI: 00000000004b1008 RDI: 00000000ffffff9c
\[ 66.646795\] RBP: 00000000004b1008 R08: 0000000000000000 R09: 00007ffc22c66baf
\[ 66.646806\] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
\[ 66.646817\] R13: 0000000000000000 R14: 000000000041b2a0 R15: 00007f812f800000
\[ 66.646834\] </TASK>

\[ 66.646848\] Allocated by task 2115:
\[ 66.646859\] kasan\_save\_stack+0x26/0x50
\[ 66.646875\] kasan\_set\_track+0x25/0x40
\[ 66.646888\] kasan\_save\_alloc\_info+0x1e/0x30
\[ 66.646898\] \_\_kasan\_kmalloc+0xb4/0xc0
\[ 66.646911\] kmalloc\_trace+0x4a/0xb0
\[ 66.646924\] xillybus\_init\_chrdev+0xf2/0x815 \[xillybus\_class\]
\[ 66.646944\] xillyusb\_probe.cold+0xa61/0xadf \[xillyusb\]
\[ 66.646966\] usb\_probe\_interface+0x266/0x740
\[ 66.646981\] really\_probe+0x1fa/0xa80
\[ 66.646993\] \_\_driver\_probe\_device+0x2cb/0x490
\[ 66.647005\] driver\_probe\_device+0x4e/0x140
\[ 66.647017\] \_\_driver\_attach+0x1a3/0x520
\[ 66.647028\] bus\_for\_each\_dev+0x11e/0x1c0
\[ 66.647039\] driver\_attach+0x3d/0x60
\[ 66.647050\] bus\_add\_driver+0x449/0x5a0
\[ 66.647061\] driver\_register+0x219/0x390
\[ 66.647073\] usb\_register\_driver+0x228/0x400
\[ 66.647084\] 0xffffffffc033202d
\[ 66.647094\] do\_one\_initcall+0x97/0x310
\[ 66.647109\] do\_init\_module+0x19a/0x630
\[ 66.647120\] load\_module+0x6ca4/0x7d90
\[ 66.647131\] \_\_do\_sys\_finit\_module+0x134/0x1d0
\[ 66.647142\] \_\_x64\_sys\_finit\_module+0x72/0xb0
\[ 66.647153\] do\_syscall\_64+0x59/0x90
\[ 66.647164\] entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd

\[ 66.647182\] Freed by task 2089:
\[ 66.647191\] kasan\_save\_stack+0x26/0x50
\[ 66.647205\] kasan\_set\_track+0x25/0x40
\[ 66.647218\] kasan\_save\_free\_info+0x2e/0x50
\[ 66.647228\] \_\_\_\_kasan\_slab\_free+0x174/0x1e0
\[ 66.647241\] \_\_kasan\_slab\_free+0x12/0x20
\[ 66.647255\] slab\_free\_freelist\_hook+0xd0/0x1a0
\[ 66.647267\] \_\_kmem\_cache\_free+0x193/0x2c0
\[ 66.647280\] kfree+0x79/0x120
\[ 66.647291\] xillybus\_cleanup\_chrdev+0x3c1/0x570 \[xillybus\_class\]
\[ 66.647311\] xillyusb\_disconnect+0xfe/0x790 \[xillyusb\]
\[ 66.647332\] usb\_unbind\_interface+0x187/0x7c0
\[ 66.647345\] device\_remove+0x117/0x170
\[ 66.647357\] device\_release\_driver\_internal+0x418/0x660
\[ 66.647369\] device\_release\_driver+0x12/0x20
\[ 66.647381\] bus\_remove\_device+0x28f/0x540
\[ 66.647392\] device\_del+0x501/0xc30
\[ 66.647407\] usb\_disable\_device+0x2a5/0x660
\[ 66.647418\] usb\_disconnect.cold+0x1f9/0x620
\[ 66.647431\] hub\_event+0x16d3/0x3d20
\[ 66.647446\] process\_one\_work+0x778/0x11c0
\[ 66.647459\] worker\_thread+0x544/0x1180
\[ 66.647471\] kthread+0x280/0x320
\[ 66.647481\] ret\_from\_fork+0x1f/0x30

\[ 66.647501\] Last potentially related work creation:
\[ 66.647510\] kasan\_save\_stack+0x26/0x50
\[ 66.647524\] \_\_kasan\_record\_aux\_stack+0xb6/0xd0
\[ 66.647534\] kasan\_record\_aux\_stack\_noalloc+0xb/0x20
\[ 66.647544\] kvfree\_call\_rcu+0xaf/0xa50
\[ 66.647555\] memcg\_reparent\_list\_lrus+0x477/0x790
\[ 66.647566\] mem\_cgroup\_css\_offline+0x1ea/0x310
\[ 66.647579\] css\_killed\_work\_fn+0xe4/0x380
\[ 66.647590\] process\_one\_work+0x778/0x11c0
\[ 66.647602\] worker\_thread+0x544/0x1180
\[ 66.647614\] kthread+0x280/0x320
\[ 66.647623\] ret\_from\_fork+0x1f/0x30

\[ 66.647642\] The buggy address belongs to the object at ffff88811eb45f80
 which belongs to the cache kmalloc-64 of size 64
\[ 66.647656\] The buggy address is located 16 bytes inside of
 64-byte region \[ffff88811eb45f80, ffff88811eb45fc0)

\[ 66.647677\] The buggy address belongs to the physical page:
\[ 66.647686\] page:000000009bdb1cfb refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88811eb45a00 pfn:0x11eb45
\[ 66.647701\] flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)
\[ 66.647720\] raw: 0017ffffc0000200 ffffea000481fec8 ffffea0004544b48 ffff888100042640
\[ 66.647731\] raw: ffff88811eb45a00 000000000020001e 00000001ffffffff 0000000000000000
\[ 66.647738\] page dumped because: kasan: bad access detected

\[ 66.647751\] Memory state around the buggy address:
\[ 66.647760\] ffff88811eb45e80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
\[ 66.647771\] ffff88811eb45f00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
\[ 66.647781\] >ffff88811eb45f80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
\[ 66.647790\] ^
\[ 66.647800\] ffff88811eb46000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\[ 66.647810\] ffff88811eb46080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\[ 66.647818\] ==================================================================
\[ 66.647826\] Disabling lock debugging due to kernel taint
\`\`\`


Regards,
Hyunwoo Kim.

next reply	other threads:\[~2022-10-22 17:54 UTC|newest\]

**Thread overview:** 4+ messages / expand\[flat|nested\] mbox.gz Atom feed top
**2022-10-22 17:54 Hyunwoo Kim \[this message\]**
2022-10-23 14:19 \` \[PATCH\] char: xillybus: Fix use-after-free in xillyusb\_open() Eli Billauer
2022-10-23 14:26 \` Hyunwoo Kim
2022-10-24 7:10 \` Eli Billauer

**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=20221022175404.GA375335@ubuntu \\
 --to=imv4bel@gmail.com \\
 --cc=arnd@arndb.de \\
 --cc=eli.billauer@gmail.com \\
 --cc=gregkh@linuxfoundation.org \\
 --cc=linux-kernel@vger.kernel.org \\
 /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.

CVE-2022-45888: [PATCH] char: xillybus: Fix use-after-free in xillyusb_open()

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**

Tag

#linux