Where
AND
-Infinity
0
Severity
9.8
Command Injection, OS Command Injection
AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

A flaw was found in OpenSSL. The crehash script does not properly sanitize shell meta-characters to prevent command injection. Some operating systems distribute this script in a manner where it is automatically executed. This flaw allows an attacker to execute arbitrary commands with the privileges of the script on these operating systems.

1 / 4
First published (updated )
Severity
9.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Last updated 24 July 2024

1 / 2
Source: Ubuntu
First published (updated )
Severity
9
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

A remote stack overflow in the TIPC networking module. With FORTIFYSOURCE's stricter memcpy() bounds checking, this can be exploited to cause remote DOS via kernel panic on systems using TIPC. Prior to these bounds checks, and with a canary leak (or no CONFIGSTACKPROTECTOR), this can be exploited for RCE.

Reference: https://www.openwall.com/lists/oss-security/2022/02/10/1

1 / 4
Source: Red Hat

Remedy

The TIPC module will NOT be automatically loaded. When required, administrative action is needed to explicitly load this module. Loading the module can be prevented with the following instructions: # echo "install tipc /bin/true" >> /etc/modprobe.d/disable-tipc.conf The system will need to be restarted if the tipc module is loaded. In most circumstances, the TIPC kernel module will be unable to be unloaded while any network interfaces are active and the protocol is in use. If the system requires this module to work correctly, this mitigation may not be suitable.

Remedy

Ensure the tipc module is not loaded; unlike many other network protocols in the Linux kernel, the tipc module cannot be auto-loaded by an unprivileged user.
First published (updated )
Severity
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

An attacker-controlled pointer free in Busybox's hush applet leads to denial of service and possible code execution when processing a crafted shell command, due to the shell mishandling the &&& string. This may be used for remote code execution under rare conditions of filtered command input.

First published (updated )
Severity
9.8
Input Validation, Buffer Overflow
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

A flaw was discovered in the cryptographic receive code in the Linux kernel's implementation of transparent interprocess communication. An attacker, with the ability to send TIPC messages to the target, can corrupt memory and escalate privileges on the target system.

1 / 4

Remedy

The TIPC module will NOT be automatically loaded. When required, administrative action is needed to explicitly load this module. Loading the module can be prevented with the following instructions: # echo "install tipc /bin/true" >> /etc/modprobe.d/disable-tipc.conf The system will need to be restarted if the tipc module is loaded. In most circumstances, the TIPC kernel module will be unable to be unloaded while any network interfaces are active and the protocol is in use. If the system requires this module to work correctly, this mitigation may not be suitable. If you need further assistance, see KCS article https://access.redhat.com/solutions/41278 or contact Red Hat Global Support Services. To mitigate the issue on systems that do need to use TIPC and do *not* deploy the TIPC protocol level encryption but rather use different ways to ensure secure communication between nodes (eg. physical network separation, IPSec/MACsec): - BEWARE THAT THIS WILL DISABLE THE TIPC PROTOCOL LEVEL ENCRYPTION - 1) On the host, save the following in a file with the ".stp" extension: %{ #include <linux/skbuff.h> #define MSG_CRYPTO 14 #define SOCK_WAKEUP 14 /* pseudo user */ #define TOP_SRV 15 /* pseudo user */ struct tipc_msg { __be32 hdr[15]; }; static inline struct tipc_msg *buf_msg(struct sk_buff *skb) { return (struct tipc_msg *)skb->data; } static inline u32 msg_word(struct tipc_msg *m, u32 pos) { return ntohl(m->hdr[pos]); } static inline void msg_set_word(struct tipc_msg *m, u32 w, u32 val) { m->hdr[w] = htonl(val); } static inline u32 msg_bits(struct tipc_msg *m, u32 w, u32 pos, u32 mask) { return (msg_word(m, w) >> pos) & mask; } static inline void msg_set_bits(struct tipc_msg *m, u32 w, u32 pos, u32 mask, u32 val) { val = (val & mask) << pos; mask = mask << pos; m->hdr[w] &= ~htonl(mask); m->hdr[w] |= htonl(val); } static inline u32 msg_user(struct tipc_msg *m) { return msg_bits(m, 0, 25, 0xf); } static inline void msg_set_user(struct tipc_msg *m, u32 n) { msg_set_bits(m, 0, 25, 0xf, n); } %} function sanitize:long (skb:long) %{ struct sk_buff *skb; struct tipc_msg *hdr; #if STAP_COMPAT_VERSION >= STAP_VERSION(1,8) skb = (struct sk_buff *) (unsigned long) STAP_ARG_skb; #else skb = (struct sk_buff *) (unsigned long) THIS->skb; #endif hdr = buf_msg(skb); if(msg_user(hdr) == MSG_CRYPTO) { msg_set_user(hdr, TOP_SRV); // set to invalid in this context } %} probe module("tipc").function("tipc_data_input").call { sanitize($skb); } 2) Install the "systemtap" package and any required dependencies (such as kernel-devel and kernel-debuginfo packages). 3) Run the "stap -g [filename-from-step-1].stp" command as root. If the host is rebooted, the changes will be lost and the script must be run again. Alternatively, build the systemtap script on a development system with "stap -g -p 4 [filename-from-step-1].stp", distribute the resulting kernel module to all affected systems, and run "staprun -L <module>" on those. When using this approach only systemtap-runtime package is required on the affected systems. Please notice that the kernel version must be the same across all systems.
First published (updated )
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Severity
9.1
Double Free
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

curl. Multiple issues were addressed by updating to curl version 7.79.1.

1 / 2
First published (updated )
Severity
9.8
Use After Free
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The mqnotify function in the GNU C Library (aka glibc) versions 2.32 and 2.33 has a use-after-free. It may use the notification thread attributes object (passed through its struct sigevent parameter) after it has been freed by the caller, leading to a denial of service (application crash) or possibly unspecified other impact.

First published (updated )
Severity
9.8
Buffer Overflow, Integer Overflow
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

In BIND 9.5.0 -> 9.11.29, 9.12.0 -> 9.16.13, and versions BIND 9.11.3-S1 -> 9.11.29-S1 and 9.16.8-S1 -> 9.16.13-S1 of BIND Supported Preview Edition, as well as release versions 9.17.0 -> 9.17.1 of the BIND 9.17 development branch, BIND servers are vulnerable if they are running an affected version and are configured to use GSS-TSIG features. In a configuration which uses BIND's default settings the vulnerable code path is not exposed, but a server can be rendered vulnerable by explicitly setting values for the tkey-gssapi-keytab or tkey-gssapi-credential configuration options. Although the default configuration is not vulnerable, GSS-TSIG is frequently used in networks where BIND is integrated with Samba, as well as in mixed-server environments that combine BIND servers with Active Directory domain controllers. For servers that meet these conditions, the ISC SPNEGO implementation is vulnerable to various attacks, depending on the CPU architecture for which BIND was built: For named binaries compiled for 64-bit platforms, this flaw can be used to trigger a buffer over-read, leading to a server crash. For named binaries compiled for 32-bit platforms, this flaw can be used to trigger a server crash due to a buffer overflow and possibly also to achieve remote code execution. We have determined that standard SPNEGO implementations are available in the MIT and Heimdal Kerberos libraries, which support a broad range of operating systems, rendering the ISC implementation unnecessary and obsolete. Therefore, to reduce the attack surface for BIND users, we will be removing the ISC SPNEGO implementation in the April releases of BIND 9.11 and 9.16 (it had already been dropped from BIND 9.17). We would not normally remove something from a stable ESV (Extended Support Version) of BIND, but since system libraries can replace the ISC SPNEGO implementation, we have made an exception in this case for reasons of stability and security.

1 / 2

Remedy

Upgrade to the patched release most closely related to your current version of BIND: BIND 9.11.31 BIND 9.16.15 BIND 9.17.12 BIND Supported Preview Edition is a special feature preview branch of BIND provided to eligible ISC support customers. BIND 9.11.31-S1 BIND 9.16.15-S1
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203