Details:
USN-4883-1: Linux kernel vulnerabilities
20 March 2021
Several security issues were fixed in the Linux kernel.
Releases
o Ubuntu 18.04 LTS
o Ubuntu 16.04 LTS
o Ubuntu 14.04 ESM
Packages
o linux - Linux kernel
o linux-aws - Linux kernel for Amazon Web Services (AWS) systems
o linux-aws-hwe - Linux kernel for Amazon Web Services (AWS-HWE) systems
o linux-azure - Linux kernel for Microsoft Azure Cloud systems
o linux-azure-4.15 - Linux kernel for Microsoft Azure Cloud systems
o linux-gcp - Linux kernel for Google Cloud Platform (GCP) systems
o linux-gcp-4.15 - Linux kernel for Google Cloud Platform (GCP) systems
o linux-hwe - Linux hardware enablement (HWE) kernel
o linux-kvm - Linux kernel for cloud environments
o linux-oracle - Linux kernel for Oracle Cloud systems
o linux-raspi2 - Linux kernel for Raspberry Pi (V8) systems
o linux-snapdragon - Linux kernel for Qualcomm Snapdragon processors
Adam Nichols discovered that heap overflows existed in the iSCSI subsystem
in the Linux kernel. A local attacker could use this to cause a denial of
service (system crash) or possibly execute arbitrary code. ( CVE-2021-27365 )
Adam Nichols discovered that the iSCSI subsystem in the Linux kernel did
not properly restrict access to iSCSI transport handles. A local attacker
could use this to cause a denial of service or expose sensitive information
(kernel pointer addresses). ( CVE-2021-27363 )
Adam Nichols discovered that an out-of-bounds read existed in the iSCSI
subsystem in the Linux kernel. A local attacker could use this to cause a
denial of service (system crash) or expose sensitive information (kernel
memory). ( CVE-2021-27364 )
Update instructions
The problem can be corrected by updating your system to the following package
versions:
Ubuntu 18.04
o linux-image-4.15.0-1081-raspi2 - 4.15.0-1081.86
o linux-image-powerpc-e500mc - 4.15.0.139.126
o linux-image-4.15.0-1096-aws - 4.15.0-1096.103
o linux-image-4.15.0-139-lowlatency - 4.15.0-139.143
o linux-image-gcp-lts-18.04 - 4.15.0.1095.113
o linux-image-4.15.0-1087-kvm - 4.15.0-1087.89
o linux-image-oracle-lts-18.04 - 4.15.0.1067.77
o linux-image-4.15.0-1095-gcp - 4.15.0-1095.108
o linux-image-virtual - 4.15.0.139.126
o linux-image-4.15.0-139-generic-lpae - 4.15.0-139.143
o linux-image-snapdragon - 4.15.0.1098.101
o linux-image-powerpc64-emb - 4.15.0.139.126
o linux-image-4.15.0-1067-oracle - 4.15.0-1067.75
o linux-image-aws-lts-18.04 - 4.15.0.1096.99
o linux-image-4.15.0-1110-azure - 4.15.0-1110.122
o linux-image-generic - 4.15.0.139.126
o linux-image-4.15.0-1098-snapdragon - 4.15.0-1098.107
o linux-image-kvm - 4.15.0.1087.83
o linux-image-raspi2 - 4.15.0.1081.78
o linux-image-azure-lts-18.04 - 4.15.0.1110.83
o linux-image-powerpc-smp - 4.15.0.139.126
o linux-image-generic-lpae - 4.15.0.139.126
o linux-image-4.15.0-139-generic - 4.15.0-139.143
o linux-image-powerpc64-smp - 4.15.0.139.126
o linux-image-lowlatency - 4.15.0.139.126
Ubuntu 16.04
o linux-image-powerpc-e500mc - 4.4.0.206.212
o linux-image-4.4.0-206-powerpc-smp - 4.4.0-206.238
o linux-image-4.4.0-206-powerpc-e500mc - 4.4.0-206.238
o linux-image-4.15.0-1096-aws - 4.15.0-1096.103~16.04.1
o linux-image-generic-hwe-16.04 - 4.15.0.139.134
o linux-image-4.15.0-139-lowlatency - 4.15.0-139.143~16.04.1
o linux-image-virtual-hwe-16.04 - 4.15.0.139.134
o linux-image-oracle - 4.15.0.1067.55
o linux-image-azure - 4.15.0.1110.101
o linux-image-generic-lpae-hwe-16.04 - 4.15.0.139.134
o linux-image-4.4.0-1090-kvm - 4.4.0-1090.99
o linux-image-4.15.0-1095-gcp - 4.15.0-1095.108~16.04.1
o linux-image-virtual - 4.4.0.206.212
o linux-image-4.15.0-139-generic-lpae - 4.15.0-139.143~16.04.1
o linux-image-4.4.0-206-generic-lpae - 4.4.0-206.238
o linux-image-snapdragon - 4.4.0.1152.144
o linux-image-powerpc64-smp - 4.4.0.206.212
o linux-image-4.15.0-139-generic - 4.15.0-139.143~16.04.1
o linux-image-4.4.0-206-lowlatency - 4.4.0-206.238
o linux-image-gke - 4.15.0.1095.96
o linux-image-4.4.0-206-powerpc64-smp - 4.4.0-206.238
o linux-image-azure-edge - 4.15.0.1110.101
o linux-image-4.15.0-1110-azure - 4.15.0-1110.122~16.04.1
o linux-image-generic - 4.4.0.206.212
o linux-image-4.4.0-1124-aws - 4.4.0-1124.138
o linux-image-oem - 4.15.0.139.134
o linux-image-aws - 4.4.0.1124.129
o linux-image-kvm - 4.4.0.1090.88
o linux-image-powerpc-smp - 4.4.0.206.212
o linux-image-generic-lpae - 4.4.0.206.212
o linux-image-4.4.0-206-powerpc64-emb - 4.4.0-206.238
o linux-image-gcp - 4.15.0.1095.96
o linux-image-lowlatency-hwe-16.04 - 4.15.0.139.134
o linux-image-4.4.0-1152-snapdragon - 4.4.0-1152.162
o linux-image-powerpc64-emb - 4.4.0.206.212
o linux-image-4.4.0-206-generic - 4.4.0-206.238
o linux-image-4.15.0-1067-oracle - 4.15.0-1067.75~16.04.1
o linux-image-lowlatency - 4.4.0.206.212
o linux-image-aws-hwe - 4.15.0.1096.89
Ubuntu 14.04
o linux-image-4.15.0-1110-azure - 4.15.0-1110.122~14.04.1
o linux-image-aws - 4.4.0.1088.85
o linux-image-4.4.0-1088-aws - 4.4.0-1088.92
o linux-image-azure - 4.15.0.1110.83
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
Exploit code:
nbd: freeze the queue while we're adding connections
When setting up a device, we can krealloc the config->socks array to add new sockets to the configuration. However if we happen to get a IO request in at this point even though we aren't setup we could hit a UAF, as we deref config->socks without any locking, assuming that the configuration was setup already and that ->socks is safe to access it as we have a reference on the configuration. But there's nothing really preventing IO from occurring at this point of the device setup, we don't want to incur the overhead of a lock to access ->socks when it will never change while the device is running. To fix this UAF scenario simply freeze the queue if we are adding sockets. This will protect us from this particular case without adding any additional overhead for the normal running case. Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
-rw-r--r--drivers/block/nbd.c8
1 files changed, 8 insertions, 0 deletions
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 6727358e147dd..e6ea5d344f87b 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -1022,6 +1022,12 @@ static int nbd_add_socket(struct nbd_device *nbd, unsigned long arg,
if (!sock)
return err;
+ /*
+ * We need to make sure we don't get any errant requests while we're
+ * reallocating the ->socks array.
+ */
+ blk_mq_freeze_queue(nbd->disk->queue);
+
if (!netlink && !nbd->task_setup &&
!test_bit(NBD_RT_BOUND, &config->runtime_flags))
nbd->task_setup = current;
@@ -1060,10 +1066,12 @@ static int nbd_add_socket(struct nbd_device *nbd, unsigned long arg,
nsock->cookie = 0;
socks[config->num_connections++] = nsock;
atomic_inc(&config->live_connections);
+ blk_mq_unfreeze_queue(nbd->disk->queue);
return 0;
put_socket:
+ blk_mq_unfreeze_queue(nbd->disk->queue);
sockfd_put(sock);
return err;
}
References:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b98e762e3d71e893b221f871825dc64694cfb258
https://www.openwall.com/lists/oss-security/2021/01/28/3
https://usn.ubuntu.com/usn/usn-4884-1?_ga=2.92893853.1231898363.1616426267-122264924.1616426267
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3348
https://www.auscert.org.au/bulletins/ESB-2021.098
1
0 Comments