On Sun, 8 Mar 2026 03:57:45 +0100, Solar Designer wrote: others have. It may well be that allowing those other env vars by and maybe allowing LANG and LC is desirable for current use cases. LANG and LC were cargo-culted in as they are honoured by OpenSSHd. Separately note that I didn't check the BSDs telnet client (which I think is still present in all BSDs) for being (hopefully not) willing And you could want to check the telnet client in InetUtils, now that we know this package missed telnet[d] security fixes in general. This was CVE-2005-0488 (and CVE-2005-1205 on Windows).

"Certain BSD-based Telnet clients, including those used on Solaris and SuSE Linux, allow remote malicious Telnet servers to read sensitive command."

The daemon now clears the inherited environment (preserving PATH and TERM, respectively, if present) before calling telnetdsetup(). LDPRELOAD=/lib64/libhardenedmalloc.so (although /etc/ld.so.preload is a more reliable way to do this when practical to do it globally).

exorciseenv() and leave the inetd/tcpd supplied environment intact for telnetd (or some site-specific wrapper) to inherit. +++ b/telnetd/state.c @@ -1495,10 +1495,18 @@ suboption (void) case NEWENVVAR: case ENVUSERVAR: ... } / end of case TELOPTNEWENVIRON /

Some code duplication here. Not new with these changes, but could be worth moving to a new function e.g. setenvvarifallowed(). Agreed. I'll implement setenvvarifallowed() instead. +/ A default whitelist for environment variables. / +static const char allowedenvvars[] = { + "USER", + "LOGNAME", + "TERM", + "LANG", + "LC", + NULL +};

Can make not only the strings but also the pointers const:

static const char const allowedenvvars[] = {

so that both may end up in a read-only section. OK, .rodata it is. +int +isenvvarallowed (const char var, const char val) +{ + const char p; + int allowed = 0; + + for (p = allowedenvvars; p; p++) + { + if (fnmatch (p, var, FNMNOESCAPE) == 0) + { + allowed = 1; + break; + } + } + + if (!allowed) + return 0;

You didn't strictly need the "allowed" variable, you could check p after the loop. But maybe it's more readable the way you wrote it. I'll keep "allowed" for the time being, but I don't mind changing it if there's a clearer way to express this logic. My review above isn't in full context - I only looked at the patches.

End of life: 12/31/2024

End of life: 12/31/2024

An Incorrect Default Permissions vulnerability in saphanabootstrap-formula of SUSE Linux Enterprise Module for SAP Applications 15-SP1, SUSE Linux Enterprise Server for SAP 12-SP5; openSUSE Leap 15.4 allows local attackers to escalate to root by manipulating the sudo configuration that is created. This issue affects: SUSE Linux Enterprise Module for SAP Applications 15-SP1 saphanabootstrap-formula versions prior to 0.13.1+git.1667812208.4db963e. SUSE Linux Enterprise Server for SAP 12-SP5 saphanabootstrap-formula versions prior to 0.13.1+git.1667812208.4db963e. openSUSE Leap 15.4 saphanabootstrap-formula versions prior to 0.13.1+git.1667812208.4db963e.

An Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in libzypp-plugin-appdata of SUSE Linux Enterprise Server for SAP 15-SP3; openSUSE Leap 15.4 allows attackers that can trick users to use specially crafted REPOALIAS, REPOTYPE or REPOMETADATAPATH settings to execute code as root. This issue affects: SUSE Linux Enterprise Server for SAP 15-SP3 libzypp-plugin-appdata versions prior to 1.0.1+git.20180426. openSUSE Leap 15.4 libzypp-plugin-appdata versions prior to 1.0.1+git.20180426.

A Incorrect Default Permissions vulnerability in rmt-server-regsharing service of SUSE Linux Enterprise Server for SAP 15, SUSE Linux Enterprise Server for SAP 15-SP1, SUSE Manager Server 4.1; openSUSE Leap 15.3, openSUSE Leap 15.4 allows local attackers with access to the rmt user to escalate to root. This issue affects: SUSE Linux Enterprise Server for SAP 15 rmt-server versions prior to 2.10. SUSE Linux Enterprise Server for SAP 15-SP1 rmt-server versions prior to 2.10. SUSE Manager Server 4.1 rmt-server versions prior to 2.10. openSUSE Leap 15.3 rmt-server versions prior to 2.10. openSUSE Leap 15.4 rmt-server versions prior to 2.10.

A Incorrect Authorization vulnerability in chkstat of SUSE Linux Enterprise Server 12-SP5; openSUSE Leap 15.3, openSUSE Leap 15.4, openSUSE Leap Micro 5.2 did not consider group writable path components, allowing local attackers with access to a group what can write to a location included in the path to a privileged binary to influence path resolution. This issue affects: SUSE Linux Enterprise Server 12-SP5 permissions versions prior to 20170707. openSUSE Leap 15.3 permissions versions prior to 20200127. openSUSE Leap 15.4 permissions versions prior to 20201225. openSUSE Leap Micro 5.2 permissions versions prior to 20181225.

End of life: 12/7/2023

End of life: 12/7/2023

A UNIX Symbolic Link (Symlink) Following vulnerability in arpwatch of SUSE Linux Enterprise Server 11-SP4-LTSS, SUSE Manager Server 4.0, SUSE OpenStack Cloud Crowbar 9; openSUSE Factory, Leap 15.2 allows local attackers with control of the runtime user to run arpwatch as to escalate to root upon the next restart of arpwatch. This issue affects: SUSE Linux Enterprise Server 11-SP4-LTSS arpwatch versions prior to 2.1a15. SUSE Manager Server 4.0 arpwatch versions prior to 2.1a15. SUSE OpenStack Cloud Crowbar 9 arpwatch versions prior to 2.1a15. openSUSE Factory arpwatch version 2.1a15-169.5 and prior versions. openSUSE Leap 15.2 arpwatch version 2.1a15-lp152.5.5 and prior versions.

A UNIX Symbolic Link (Symlink) Following vulnerability in python-HyperKitty of openSUSE Leap 15.2, Factory allows local attackers to escalate privileges from the user hyperkitty or hyperkitty-admin to root. This issue affects: openSUSE Leap 15.2 python-HyperKitty version 1.3.2-lp152.2.3.1 and prior versions. openSUSE Factory python-HyperKitty versions prior to 1.3.4-5.1.

Heap buffer overflow in UI in Google Chrome on Windows prior to 86.0.4240.183 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page.

An issue was discovered in Xen through 4.14.x allowing x86 guest OS users to cause a denial of service (data corruption), cause a data leak, or possibly gain privileges because an AMD IOMMU page-table entry can be half-updated.

An issue was discovered in Xen through 4.14.x allowing x86 HVM and PVH guest OS users to cause a denial of service (data corruption), cause a data leak, or possibly gain privileges because coalescing of per-page IOMMU TLB flushes is mishandled.

An issue was discovered in Xen through 4.14.x allowing x86 guest OS users to cause a host OS denial of service, achieve data corruption, or possibly gain privileges by exploiting a race condition that leads to a use-after-free involving 2MiB and 1GiB superpages.

Insufficient policy enforcement in ANGLE in Google Chrome prior to 86.0.4240.183 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

Use after free in user interface in Google Chrome prior to 86.0.4240.183 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

A missing rate limit in the Preferred Providers app 1.7.0 allowed an attacker to set the password an uncontrolled amount of times.

Stack buffer overflow in WebRTC in Google Chrome prior to 86.0.4240.183 allowed a remote attacker to potentially exploit stack corruption via a crafted WebRTC packet.

Inappropriate implementation in V8 in Google Chrome prior to 86.0.4240.183 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

In rfb/CSecurityTLS.cxx and rfb/CSecurityTLS.java in TigerVNC before 1.11.0, viewers mishandle TLS certificate exceptions. They store the certificates as authorities, meaning that the owner of a certificate could impersonate any server after a client had added an exception.

Impact If a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption.

Patches We have patched the issue in d58c96946b and will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

Workarounds A potential workaround would be to add a custom Verifier to the model loading code to ensure that no operator reuses tensors as both inputs and outputs. Care should be taken to check all types of inputs (i.e., constant or variable tensors as well as optional tensors).

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been discovered from a variant analysis of GHSA-cvpc-8phh-8f45.

Impact In TensorFlow Lite, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices for the tensors, indexing into an array of tensors that is owned by the subgraph. This results in a pattern of double array indexing when trying to get the data of each tensor: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/lite/kernels/kernelutil.cc#L36

However, some operators can have some tensors be optional. To handle this scenario, the flatbuffer model uses a negative -1 value as index for these tensors: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/lite/c/common.h#L82

This results in special casing during validation at model loading time: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/lite/core/subgraph.cc#L566-L580

Unfortunately, this means that the -1 index is a valid tensor index for any operator, including those that don't expect optional inputs and including for output tensors. Thus, this allows writing and reading from outside the bounds of heap allocated arrays, although only at a specific offset from the start of these arrays.

This results in both read and write gadgets, albeit very limited in scope.

Patches We have patched the issue in several commits (46d5b0852, 00302787b7, e11f5558, cd31fd0ce, 1970c21, and fff2c83). We will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

Workarounds A potential workaround would be to add a custom Verifier to the model loading code to ensure that only operators which accept optional inputs use the -1 special value and only for the tensors that they expect to be optional. Since this allow-list type approach is erro-prone, we advise upgrading to the patched code.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

Impact A crafted TFLite model can force a node to have as input a tensor backed by a nullptr buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one. The runtime assumes that these buffers are written to before a possible read, hence they are initialized with nullptr: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/lite/core/subgraph.cc#L1224-L1227

However, by changing the buffer index for a tensor and implicitly converting that tensor to be a read-write one, as there is nothing in the model that writes to it, we get a null pointer dereference.

Patches We have patched the issue in 0b5662bc and will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360 but was also discovered through variant analysis of GHSA-cvpc-8phh-8f45.

Impact When determining the common dimension size of two tensors, TFLite uses a DCHECK which is no-op outside of debug compilation modes: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/lite/kernels/internal/types.h#L437-L442

Since the function always returns the dimension of the first tensor, malicious attackers can craft cases where this is larger than that of the second tensor. In turn, this would result in reads/writes outside of bounds since the interpreter will wrongly assume that there is enough data in both tensors.

Patches We have patched the issue in 8ee24e7949a20 and will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

Impact To mimic Python's indexing with negative values, TFLite uses ResolveAxis to convert negative values to positive indices. However, the only check that the converted index is now valid is only present in debug builds: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/lite/kernels/internal/reference/reduce.h#L68-L72

If the DCHECK does not trigger, then code execution moves ahead with a negative index. This, in turn, results in accessing data out of bounds which results in segfaults and/or data corruption. Patches We have patched the issue in 2d88f470dea2671b430884260f3626b1fe99830a and will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

Impact In eager mode, TensorFlow does not set the session state. Hence, calling tf.rawops.GetSessionHandle or tf.rawops.GetSessionHandleV2 results in a null pointer dereference: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/sessionops.cc#L45

In the above snippet, in eager mode, ctx->sessionstate() returns nullptr. Since code immediately dereferences this, we get a segmentation fault.

Patches We have patched the issue in 9a133d73ae4b4664d22bd1aa6d654fec13c52ee1 and will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

Impact Changing the TensorFlow's SavedModel protocol buffer and altering the name of required keys results in segfaults and data corruption while loading the model. This can cause a denial of service in products using tensorflow-serving or other inference-as-a-service installments.

We have added fixes to this in f760f88b4267d981e13f4b302c437ae800445968 and fcfef195637c6e365577829c4d67681695956e7d (both going into TensorFlow 2.2.0 and 2.3.0 but not yet backported to earlier versions). However, this was not enough, as #41097 reports a different failure mode.

Patches We have patched the issue in adf095206f25471e864a8e63a0f1caef53a0e3a6 and will release patch releases for all versions between 1.15 and 2.3. Patch releases for versions between 1.15 and 2.1 will also contain cherry-picks of f760f88b4267d981e13f4b302c437ae800445968 and fcfef195637c6e365577829c4d67681695956e7d.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by Shuaike Dong, from Alipay Tian Qian Security Lab && Lab for Applied Security Research, CUHK.

Impact The datasplits argument of tf.rawops.StringNGrams lacks validation. This allows a user to pass values that can cause heap overflow errors and even leak contents of memory python >> tf.rawops.StringNGrams(data=["aa", "bb", "cc", "dd", "ee", "ff"], datasplits=[0,8], separator=" ", ngramwidths=[3], leftpad="", rightpad="", padwidth=0, preserveshortsequences=False) StringNGrams(ngrams=<tf.Tensor: shape=(6,), dtype=string, numpy= array([b'aa bb cc', b'bb cc dd', b'cc dd ee', b'dd ee ff', b'ee ff \xf4j\xa7q\x7f\x00\x00q\x00\x00\x00\x00\x00\x00\x00\xd8\x9b~\xa8q\x7f\x00', b'ff \xf4j\xa7q\x7f\x00\x00q\x00\x00\x00\x00\x00\x00\x00\xd8\x9b~\xa8q\x7f\x00 \x9b~\xa8q\x7f\x00\x00p\xf5j\xa7q\x7f\x00\x00H\xf8j\xa7q\x7f\x00\x00\xf0\xf3\xf7\x85q\x7f\x00\x00}\xa6\x00\x00\x00\x00\x00~\xa6\x00\x00\x00\x00\x00\xb0~\xeb\x9bq\x7f\x00'],...

All the binary strings after ee ff are contents from the memory stack. Since these can contain return addresses, this data leak can be used to defeat ASLR.

Patches We have patched the issue in 0462de5b544ed4731aa2fb23946ac22c01856b80 and will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

Impact By controlling the fill argument of tf.strings.asstring, a malicious attacker is able to trigger a format string vulnerability due to the way the internal format use in a printf call is constructed: https://github.com/tensorflow/tensorflow/blob/0e68f4d3295eb0281a517c3662f6698992b7b2cf/tensorflow/core/kernels/asstringop.cc#L68-L74

This can result in unexpected output: python In [1]: tf.strings.asstring(input=[1234], width=6, fill='-') Out[1]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['1234 '], dtype=object)> In [2]: tf.strings.asstring(input=[1234], width=6, fill='+') Out[2]: <tf.Tensor: shape=(1,), dtype=string, numpy=array([' +1234'], dtype=object)> In [3]: tf.strings.asstring(input=[1234], width=6, fill="h") Out[3]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['%6d'], dtype=object)> In [4]: tf.strings.asstring(input=[1234], width=6, fill="d") Out[4]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['12346d'], dtype=object)> In [5]: tf.strings.asstring(input=[1234], width=6, fill="o") Out[5]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['23226d'], dtype=object)> In [6]: tf.strings.asstring(input=[1234], width=6, fill="x") Out[6]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['4d26d'], dtype=object)> In [7]: tf.strings.asstring(input=[1234], width=6, fill="g") Out[7]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['8.67458e-3116d'], dtype=object)> In [8]: tf.strings.asstring(input=[1234], width=6, fill="a") Out[8]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['0x0.00ff7eebb4d4p-10226d'], dtype=object)> In [9]: tf.strings.asstring(input=[1234], width=6, fill="c") Out[9]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['\xd26d'], dtype=object)> In [10]: tf.strings.asstring(input=[1234], width=6, fill="p") Out[10]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['0x4d26d'], dtype=object)> In [11]: tf.strings.asstring(input=[1234], width=6, fill='m') Out[11]: <tf.Tensor: shape=(1,), dtype=string, numpy=array(['Success6d'], dtype=object)>

However, passing in n or s results in segmentation fault.

Patches We have patched the issue in 33be22c65d86256e6826666662e40dbdfe70ee83 and will release patch releases for all versions between 1.15 and 2.3.

We recommend users to upgrade to TensorFlow 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

For more information Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution This vulnerability has been reported by members of the Aivul Team from Qihoo 360.