LinuxQuestions.org - [Slackware security] vulnerabilities outstanding 20140101

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - [Slackware security] vulnerabilities outstanding 20140101 (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-security%5D-vulnerabilities-outstanding-20140101-a-4175489800/)

Mutt 2.0.5 was released on January 21, 2021. This is a bug-fix release, fixing a few memory leaks, including CVE-2021-3181.
ftp://ftp.mutt.org/pub/mutt/mutt-2.0.5.tar.gz

CVE-2021-3156 sudo heap buffer overflow

CVE-2021-3156
Heap buffer overflow affecting sudo versions 1.8.2 through 1.8.31p2 and 1.9.0 through 1.9.5p1.

Patch is here.

Additional note: Conditional check of libpam symbolic link in sudo.Slackbuild fails on Slackware64 because LIBDIRSUFFIX is not defined in the arch detection stanza like it usually is.

Fixed in -current (and 14.0, 14.1, 14.2).

Recently several dnsmasq vulnerabilities were reported. Version 2.78 in 14.2 is affected.

CVE-2021-21148 affects Google Chrome/Chromium-based browsers
Upgrade to Chromium 88.0.4324.150 or later.
https://chromereleases.googleblog.co...desktop_4.html

GNU Screen up to and including version 4.8.0 is vulnerable to CVE-2021-26937
https://www.linuxquestions.org/quest...ty-4175690257/
https://cve.mitre.org/cgi-bin/cvenam...CVE-2021-26937
A patch is available here:
https://salsa.debian.org/debian/scre...21-26937.patch

The patch seems to apply cleanly on 4.8.0 running Slackware-current as far as I can tell.

OpenSSL 1.1.1j
Upgraded in -current according to the latest ChangeLogs:

Quote:

n/openssl-1.1.1j-i586-1.txz: Upgraded.
n/openssl-1.1.1j-x86_64-1.txz: Upgraded.
This fixes bugs and denial of service vulnerabilities.
For more information, see:
https://cve.mitre.org/cgi-bin/cvenam...CVE-2021-23841
https://cve.mitre.org/cgi-bin/cvenam...CVE-2021-23840
(* Security fix *)

python 3.x through 3.9.1 are vulnerable to CVE-2021-3117

https://cve.mitre.org/cgi-bin/cvenam...=CVE-2021-3177

Not aware of any patch yet.

Quote:

Originally Posted by ttk (Post 6221917)

python 3.x through 3.9.1 are vulnerable to CVE-2021-3117

https://cve.mitre.org/cgi-bin/cvenam...=CVE-2021-3177

Not aware of any patch yet.

this should be the backported patch from the development branch

https://github.com/python/cpython/co...1353ecc3.patch

Bind-9.10.12 affected by a serious bug according to this: http://wiki.linuxfromscratch.org/blfs/ticket/14683

it's advised to downgrade to bind-9.10.11 + a sed patch.

Kinda "nice" thread, but perhaps unstick it and create [Slackware security] vulnerabilities outstanding 20210301 ?

Or whatever month/day we go beyond Slackware 15 beta...

Thunderbird 78.8.0 fixes the following security vulnerabilities:
https://www.mozilla.org/en-US/securi...s/mfsa2021-09/
Edit:
Available in -current according to the latest ChangeLogs.

Quote:

Wed Feb 24 20:34:08 UTC 2021
xap/mozilla-thunderbird-78.8.0-x86_64-1.txz: Upgraded.

GRUB: 117 security patches at once.

Daniel Kiper just released no less than 117 patches to fix vulnerabilities in GRUB.

I have pulled from git master and built a new GRUB package for Slint that I will upload today. I suggest to do the same for Slackware.

Quote:

Originally Posted by Didier Spaier (Post 6226564)

This is the reason why, although I tested GRUB in the virtual machine, I did not install it on the test server or on the production one.
GRUB 2.04 has quite a few issues (e.g. the BootHole vulnerability) and version 2.06 is still pending.

Quote:

Originally Posted by teoberi (Post 6226576)

Funnily, Daniel just answered a few seconds ago to people complaining about the delayed 2.06 release:

Quote:

I am planning to cut 2.06-rc1 in matter of days...

But he didn't say how many...

I am testing my new packages and for some reason grub-mkconfig doesn't create the boot entries expected from os-prober. Investigating. Of course I won't ship this package as-is.

Quote:

Originally Posted by Didier Spaier (Post 6226587)

I am testing my new packages and for some reason grub-mkconfig doesn't create the boot entries expected from os-prober. Investigating. Of course I won't ship this package as-is.

Found it. In the patch #116 a test is wrongly reverted. Now to get boot entries from os-prober one have to set GRUB_DISABLE_OS_PROBER=true instead of false. Go figure...

PS reported on the grub-devel mailing list.

Quote:

Originally Posted by Didier Spaier (Post 6226564)

I use also the git version since the latest current package.

Quote:

Originally Posted by Didier Spaier (Post 6226594)

Will be fixed soon.

git 2.30.2 due to this report

Security flaws in -stable (14.2) kernel before version 4.4.260:
https://linux.slashdot.org/story/21/...oot-privileges
https://www.scmagazine.com/home/secu...-to-attackers/
https://blog.grimm-co.com/2021/03/ne...ux-kernel.html

Edit:
New kernel packages are available according to the latest ChangeLogs:

Quote:

Sun Mar 14 03:24:31 UTC 2021
patches/packages/kernel-firmware-20210305_e425f76-noarch-1.txz: Upgraded.
patches/packages/linux-4.4.261/*: Upgraded.
These updates fix various bugs and security issues, including the recently
announced iSCSI vulnerabilities allowing local privilege escalation.
Be sure to upgrade your initrd after upgrading the kernel packages.
If you use lilo to boot your machine, be sure lilo.conf points to the correct
kernel and initrd and run lilo as root to update the bootloader.
If you use elilo to boot your machine, you should run eliloconfig to copy the
kernel and initrd to the EFI System Partition.
For more information, see:
https://cve.mitre.org/cgi-bin/cvenam...CVE-2021-27363
https://cve.mitre.org/cgi-bin/cvenam...CVE-2021-27364
https://cve.mitre.org/cgi-bin/cvenam...CVE-2021-27365
(* Security fix *)

I ran across nvd.nist.gov - CVE-2021-27135, looks like it is specific to 14.2 and earlier. From what I read, the version on current is fine.

So I took the xterm source and build from Current slackware.osuosl.org xterm-366 and compiled and installed it on 14.2. So far so good. But if you have custom fonts in ~/.Xdefaults you may need to adjust them.

CVE-2019-17498 libssh2 SSH_MSG_DISCONNECT

This is a bit of an oldie. It's mostly applicable to docker and flatpak: CVE-2019-17498

Quote:

In libssh2 v1.9.0 and earlier versions, the SSH_MSG_DISCONNECT logic in packet.c has an integer overflow in a bounds check, enabling an attacker to specify an arbitrary (out-of-bounds) offset for a subsequent memory read. A crafted SSH server may be able to disclose sensitive information or cause a denial of service condition on the client system when a user connects to the server.

A PoC exists although it's an exercise that requires docker and a user that wants to crash their own docker server.

This will mostly likely be fixed when upstream releases 1.9.1 because the patch comes from the main branch on github, but I'm submitting this for Pat's consideration in the meantime.

Code:

--- libssh2.SlackBuild.orig    2021-03-21 12:10:41.579936398 +0200

+++ libssh2.SlackBuild  2021-03-21 12:09:10.603865683 +0200

@@ -24,7 +24,7 @@

 

 PKGNAM=libssh2

 VERSION=${VERSION:-$(echo $PKGNAM-*.tar.?z | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}

-BUILD=${BUILD:-3}

+BUILD=${BUILD:-4}

 

 # Automatically determine the architecture we're building on:

 if [ -z "$ARCH" ]; then

@@ -77,6 +77,13 @@

  \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \

  -exec chmod 644 {} \+

 

+# CVE-2019-17498

+[[ ! -f ${CWD}/CVE-2019-17498.patch ]] && \

+wget https://github.com/libssh2/libssh2/commit/1c6fa92b77e34d089493fe6d3e2c6c8775858b94.patch \

+-O ${CWD}/CVE-2019-17498.patch

+

+patch -Np1 -i ${CWD}/CVE-2019-17498.patch || exit 1

+

 CFLAGS="$SLKCFLAGS" \

 ./configure \

  --prefix=/usr \

Linux kernel LTS versions prior to 5.10.29, 5.4.111, 4.19.186, 4.14.230, 4.9.266, and 4.4.266 are vulnerable to CVE-2021-29154
https://www.openwall.com/lists/oss-s...y/2021/04/08/1

Thought this would be as good a place as any to post this, :)

Quote:

New Spectre Variants Discovered By Exploiting Micro-op Caches
Written by Michael Larabel in Linux Security on 1 May 2021 at 06:13 AM EDT.

University of Virginia and University of California San Diego researchers have discovered multiple new variants of Spectre attacks that are not protected by existing Spectre mitigations and could yield both Intel and AMD CPUs leaking data via micro-op caches.

This week the Virginia and California academic researchers went public with their discoveries on exploiting the micro-op cache of modern Intel and AMD processors for beating existing Spectre defenses. Both Intel and AMD were informed in advance of these two variants (or their whitepaper lays it out as three) that allow speculatively stealing information from the system.

The researchers believe this new attack by way of the micro-op cache will be harder to mitigate. Needless to say, at this point there is no kernel patches or microcode updates to pass along. The researchers also believe that any mitigation will come with "much greater performance penalty" than what was found by previous attacks. Among the potential mitigations would involve flushing the micro-op cache at domain crossings and/or privilege level-based partitioning of the caches.
This paper describes three attacks – (1) a same thread cross-domain attack that leaks secrets across the user-kernel boundary, (2) a cross-SMT thread attack that transmits secrets across two SMT threads via the micro-op cache, and (3) transient execution attacks that have the ability to leak an unauthorized secret accessed along a misspeculated path, even before the transient instruction is dispatched to execution, breaking several existing invisible speculation and fencing-based solutions that mitigate Spectre.

The researchers will be presenting at ISCA next month on their findings while there is the whitepaper for those interested in the research. Stay tuned

https://www.phoronix.com/scan.php?pa...Cache-Exploits

Does Slackware have any mitigations against Row Hammer attacks? Can enough sram be clustered together to use instead of dram (if one could afford it)?

Critical vulnerability in the Linux kernel:
https://cve.mitre.org/cgi-bin/cvenam...CVE-2021-33909

Slackware64-current is safe (kernel 5.13.4).

Quote:

Originally Posted by teoberi (Post 6269155)

Slackware64-current is safe (kernel 5.13.4).

I know, but stable is not. If 15.0 is not released in the next weeks, something probably should be done about that.

Quote:

Originally Posted by M0M0 (Post 6269160)

I know, but stable is not. If 15.0 is not released in the next weeks, something probably should be done about that.

You might want to read the 21 July 2021 change log for Stable.

Quote:

+--------------------------+
Wed Jul 21 05:30:44 UTC 2021
patches/packages/linux-4.4.276/*: Upgraded.
These updates fix various bugs and security issues, including the recently
announced local privilege escalation vulnerability in the filesystem layer
(CVE-2021-33909)
Be sure to upgrade your initrd after upgrading the kernel packages.......

The full log can be found here, http://www.slackware.com/changelog/stable.php?cpu=i386
For 64-bit the change log can be found here, http://www.slackware.com/changelog/s...php?cpu=x86_64

I highlighted the CVE number.

I missed that. Sorry and thanks.

Linux glibc security fix created a nastier Linux bug
https://www.zdnet.com/article/linux-...ier-linux-bug/

Quote:

The Linux distributors are still working out the best way to deploy the fix. In the meantime, if you want to be extra careful -- and I think you should be -- you should upgrade to the newest stable version of glibc 2.34 or higher.

ChangeLog
Sat Aug 7 19:04:04 UTC 2021

Quote:

l/glibc-2.33-x86_64-3.txz: Rebuilt.
Since glibc-2.34 makes a potentially risky change of moving all functions
into the main library, and another inconvenient (for us) change of renaming
the library files, we'll stick with glibc-2.33 for Slackware 15.0 and test
the newer glibc in the next release cycle. But we'll backport the security
fixes from glibc-2.34 with this update...

Security fixes in Firefox & Thunderbird 91.0.1
https://slackware.osuosl.org/slackwa.../ChangeLog.txt

Quote:

Tue Aug 17 20:08:40 UTC 2021
xap/mozilla-firefox-91.0.1-x86_64-1.txz: Upgraded.
This release contains security fixes and improvements.
For more information, see:
https://www.mozilla.org/en-US/firefo.../releasenotes/
https://www.mozilla.org/security/adv...s/mfsa2021-37/
https://cve.mitre.org/cgi-bin/cvenam...CVE-2021-29991
(* Security fix *)
xap/mozilla-thunderbird-91.0.1-x86_64-1.txz: Upgraded.
This release contains security fixes and improvements.
For more information, see:
https://www.mozilla.org/en-US/thunde.../releasenotes/
https://www.mozilla.org/en-US/securi...s/mfsa2021-37/
https://cve.mitre.org/cgi-bin/cvenam...CVE-2021-29991
(* Security fix *)

According to this page openssl.org/news/vulnerabilities-1.0.2.html openssl 1.0.2, while out of support since end of 2019 still have few vulnerabilities not fixed in Slackware 14.2's openssl package. [edited because first post]

According to BLFS MIT krb5-1.19.2 is affected by a denial-of-service security vulnerability, follow link:
https://www.linuxfromscratch.org/blf...fs/mitkrb.html , it needs:
-------------------------
sed -i '210a if (sprinc == NULL) {\
status = "NULL_SERVER";\
errcode = KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN;\
goto cleanup;\
}' src/kdc/do_tgs_req.c
-------------------------

critical bug discovered in the kernel (from 5.10 to 5.15): https://threatpost.com/critical-linu...el-bug/176000/

With patch : https://github.com/torvalds/linux/co...799f76c88f7bb0

Quote:

critical bug

Please do not use such alarmist descriptions in this thread.
Yes, it is a potentially serious bug, but how many people are using Linux clusters?

Quote:

Originally Posted by allend (Post 6298933)

Please do not use such alarmist descriptions in this thread.
Yes, it is a potentially serious bug, but how many people are using Linux clusters?

This is not an alarmist description
This is a typical bug severity classification :
- critical
- high-severity
- medium-severity
- low-severity

Quote:

Originally Posted by nobodino (Post 6298920)

critical bug discovered in the kernel (from 5.10 to 5.15)

The fix was already in 5.15. And in 5.14.16.

Quote:

This is not a alarmist description
This is a typical bug severity classification :

This has a base score of 5.5 medium

OK - Got it. Thanks for noting it has been fixed.

I still question the severity. In my experience, people using distributed systems just want to get on with their work, rather than playing bad actor.

Xorg has a bunch of new CVE's, Fixes are pending in X.Org Server Git.
https://www.phoronix.com/scan.php?pa...-December-2021

According to BLFS wpa_supplicant is affected by some CVE's vulnerabilities (normal in the classification of CVE's), follow link :
https://wiki.linuxfromscratch.org/blfs/ticket/15851

with 2 commits to solve the problems:

https://w1.fi/cgit/hostap/commit/?id...72693cd7e96f15

and

https://w1.fi/cgit/hostap/commit/wpa...dbc0cbeabb8b55

cryptsetup 2.4.3 and 2.3.7 (CVE-2021-4122 fix)

As just announced by Milan Broz on the dm-crypt mailing list in three emails:

Code:

The cryptsetup 2.4.3 stable release is available at 



      https://gitlab.com/cryptsetup/cryptsetup 



Please note that release packages are located on kernel.org 



      https://www.kernel.org/pub/linux/utils/cryptsetup/v2.4/ 



Feedback and bug reports are welcomed. 



Cryptsetup 2.4.3 Release Notes 

============================== 

Stable security bug-fix release that fixes CVE-2021-4122. 



All users of cryptsetup 2.4.x must upgrade to this version. 



Changes since version 2.4.2 

~~~~~~~~~~~~~~~~~~~~~~~~~~~ 



* Fix possible attacks against data confidentiality through LUKS2 online 

  reencryption extension crash recovery (CVE-2021-4122). 



  An attacker can modify on-disk metadata to simulate decryption in 

  progress with crashed (unfinished) reencryption step and persistently 

  decrypt part of the LUKS device. 



  This attack requires repeated physical access to the LUKS device but 

  no knowledge of user passphrases. 



  The decryption step is performed after a valid user activates 

  the device with a correct passphrase and modified metadata. 

  There are no visible warnings for the user that such recovery happened 

  (except using the luksDump command). The attack can also be reversed 

  afterward (simulating crashed encryption from a plaintext) with 

  possible modification of revealed plaintext. 



  The size of possible decrypted data depends on configured LUKS2 header 

  size (metadata size is configurable for LUKS2). 

  With the default parameters (16 MiB LUKS2 header) and only one 

  allocated keyslot (512 bit key for AES-XTS), simulated decryption with 

  checksum resilience SHA1 (20 bytes checksum for 4096-byte blocks), 

  the maximal decrypted size can be over 3GiB. 



  The attack is not applicable to LUKS1 format, but the attacker can 

  update metadata in place to LUKS2 format as an additional step. 

  For such a converted LUKS2 header, the keyslot area is limited to 

  decrypted size (with SHA1 checksums) over 300 MiB. 



  The issue is present in all cryptsetup releases since 2.2.0. 

  Versions 1.x, 2.0.x, and 2.1.x are not affected, as these do not 

  contain LUKS2 reencryption extension. 



  The problem was caused by reusing a mechanism designed for actual 

  reencryption operation without reassessing the security impact for new 

  encryption and decryption operations. While the reencryption requires 

  calculating and verifying both key digests, no digest was needed to 

  initiate decryption recovery if the destination is plaintext (no 

  encryption key). Also, some metadata (like encryption cipher) is not 

  protected, and an attacker could change it. Note that LUKS2 protects 

  visible metadata only when a random change occurs. It does not protect 

  against intentional modification but such modification must not cause 

  a violation of data confidentiality. 



  The fix introduces additional digest protection of reencryption 

  metadata. The digest is calculated from known keys and critical 

  reencryption metadata. Now an attacker cannot create correct metadata 

  digest without knowledge of a passphrase for used keyslots. 

  For more details, see LUKS2 On-Disk Format Specification version 1.1.0. 



  The former reencryption operation (without the additional digest) is no 

  longer supported (reencryption with the digest is not backward 

  compatible). You need to finish in-progress reencryption before 

  updating to new packages. The alternative approach is to perform 

  a repair command from the updated package to recalculate reencryption 

  digest and fix metadata. 

  The reencryption repair operation always require a user passphrase. 



  WARNING: Devices with older reencryption in progress can be no longer 

  activated without performing the action mentioned above. 



  Encryption in progress can be detected by running the luksDump command 

  (output includes reencrypt keyslot with reencryption parameters). Also, 

  during the active reencryption, no keyslot operations are available 

  (change of passphrases, etc.). 



  The issue was found by Milan Broz as cryptsetup maintainer. 



Other changes 

~~~~~~~~~~~~~ 

* Add configure option --disable-luks2-reencryption to completely disable 

  LUKS2 reencryption code. 



  When used, the libcryptsetup library can read metadata with 

  reencryption code, but all reencryption API calls and cryptsetup 

  reencrypt commands are disabled. 



  Devices with online reencryption in progress cannot be activated. 

  This option can cause some incompatibilities. Please use with care. 



* Improve internal metadata validation code for reencryption metadata. 



* Add updated documentation for LUKS2 On-Disk Format Specification 

  version 1.1.0 (with reencryption extension description and updated 

  metadata description). See docs/on-disk-format-luks2.pdf or online 

  version in https://gitlab.com/cryptsetup/LUKS2-docs repository. 



* Fix support for bitlk (BitLocker compatible) startup key with new 

  metadata entry introduced in Windows 11. 



* Fix space restriction for LUKS2 reencryption with data shift. 

  The code required more space than was needed.

Code:

The cryptsetup 2.3.7 stable release is available at 



      https://gitlab.com/cryptsetup/cryptsetup 



Please note that release packages are located on kernel.org 



      https://www.kernel.org/pub/linux/utils/cryptsetup/v2.3/ 



Feedback and bug reports are welcomed. 



Cryptsetup 2.3.7 Release Notes 

============================== 

Stable security bug-fix release that fixes CVE-2021-4122. 



All users of cryptsetup 2.3.x must upgrade to this version. 



Changes since version 2.3.6 

~~~~~~~~~~~~~~~~~~~~~~~~~~~ 



* Fix possible attacks against data confidentiality through LUKS2 online 

  reencryption extension crash recovery (CVE-2021-4122). 



  An attacker can modify on-disk metadata to simulate decryption in 

  progress with crashed (unfinished) reencryption step and persistently 

  decrypt part of the LUKS device. 



  This attack requires repeated physical access to the LUKS device but 

  no knowledge of user passphrases. 



  The decryption step is performed after a valid user activates 

  the device with a correct passphrase and modified metadata. 

  There are no visible warnings for the user that such recovery happened 

  (except using the luksDump command). The attack can also be reversed 

  afterward (simulating crashed encryption from a plaintext) with 

  possible modification of revealed plaintext. 



  The size of possible decrypted data depends on configured LUKS2 header 

  size (metadata size is configurable for LUKS2). 

  With the default parameters (16 MiB LUKS2 header) and only one 

  allocated keyslot (512 bit key for AES-XTS), simulated decryption with 

  checksum resilience SHA1 (20 bytes checksum for 4096-byte blocks), 

  the maximal decrypted size can be over 3GiB. 



  The attack is not applicable to LUKS1 format, but the attacker can 

  update metadata in place to LUKS2 format as an additional step. 

  For such a converted LUKS2 header, the keyslot area is limited to 

  decrypted size (with SHA1 checksums) over 300 MiB. 



  The issue is present in all cryptsetup releases since 2.2.0. 

  Versions 1.x, 2.0.x, and 2.1.x are not affected, as these do not 

  contain LUKS2 reencryption extension. 



  The problem was caused by reusing a mechanism designed for actual 

  reencryption operation without reassessing the security impact for new 

  encryption and decryption operations. While the reencryption requires 

  calculating and verifying both key digests, no digest was needed to 

  initiate decryption recovery if the destination is plaintext (no 

  encryption key). Also, some metadata (like encryption cipher) is not 

  protected, and an attacker could change it. Note that LUKS2 protects 

  visible metadata only when a random change occurs. It does not protect 

  against intentional modification but such modification must not cause 

  a violation of data confidentiality. 



  The fix introduces additional digest protection of reencryption 

  metadata. The digest is calculated from known keys and critical 

  reencryption metadata. Now an attacker cannot create correct metadata 

  digest without knowledge of a passphrase for used keyslots. 

  For more details, see LUKS2 On-Disk Format Specification version 1.1.0. 



  The former reencryption operation (without the additional digest) is no 

  longer supported (reencryption with the digest is not backward 

  compatible). You need to finish in-progress reencryption before 

  updating to new packages. The alternative approach is to perform 

  a repair command from the updated package to recalculate reencryption 

  digest and fix metadata. 

  The reencryption repair operation always require a user passphrase. 



  WARNING: Devices with older reencryption in progress can be no longer 

  activated without performing the action mentioned above. 



  Encryption in progress can be detected by running the luksDump command 

  (output includes reencrypt keyslot with reencryption parameters). Also, 

  during the active reencryption, no keyslot operations are available 

  (change of passphrases, etc.). 



  The issue was found by Milan Broz as cryptsetup maintainer. 



Other changes 

~~~~~~~~~~~~~ 

* Add configure option --disable-luks2-reencryption to completely disable 

  LUKS2 reencryption code. 



  When used, the libcryptsetup library can read metadata with 

  reencryption code, but all reencryption API calls and cryptsetup 

  reencrypt commands are disabled. 



  Devices with online reencryption in progress cannot be activated. 

  This option can cause some incompatibilities. Please use with care. 



* Improve internal metadata validation code for reencryption metadata. 



* Add updated documentation for LUKS2 On-Disk Format Specification 

  version 1.1.0 (with reencryption extension description and updated 

  metadata description). See docs/on-disk-format-luks2.pdf or online 

  version in https://gitlab.com/cryptsetup/LUKS2-docs repository.

Code:

Just note - for 2.2.x version (no longer supported, there will be no release) backport 

is quite problematic, so I just backported reencryption disable configure option, 

see 2.2.x branch: https://gitlab.com/cryptsetup/cryptsetup/-/tree/v2.2.x 



Other versions are not affected (1.x, 2.0.x, 2.1.x). 



Also see 

https://www.openwall.com/lists/oss-s...y/2022/01/13/2 



Milan

wpa_supplicant

https://www.cvedetails.com/cve/CVE-2022-23303/
https://www.cvedetails.com/cve/CVE-2022-23304/

Code:

The implementations of EAP-pwd in hostapd before 2.10 and wpa_supplicant before 2.10 are vulnerable 

to side-channel attacks as a result of cache access patterns. 

NOTE: this issue exists because of an incomplete fix for CVE-2019-9495.

and patches
https://w1.fi/security/2022-1/

v2.10
https://w1.fi/cgit/hostap/snapshot/h...ap_2_10.tar.gz

buffer overflow in kernel, up to 5.16.1 included

https://seclists.org/oss-sec/2022/q1/55

CVE-2022-0185 -- Heap-based buffer overflow in kernel fs/fs_context

Severity is high according to redhat
https://bugzilla.redhat.com/show_bug.cgi?id=2040358

It seems to be fixed in kernel 5.16.2
commit 8b1530a3772ae5b49c6d8d171fd3146bb947430f
Author: Jamie Hill-Daniel <jamie@hill-daniel.co.uk>
Date: Tue Jan 18 08:06:04 2022 +0100