CVE-2022-47952

lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because "Failed to open" often indicates that a file does not exist, whereas "does not refer to a network namespace path" often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that "we will report back to the user that the open() failed but the user has no way of knowing why it failed"; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.

Containers are insulated areas inside a system, which have their own namespace for filesystem, network, PID, IPC, CPU and memory allocation and which can be created using the Control Group and Namespace features included in the Linux kernel.

Security Fix(es):

lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because "Failed to open" often indicates that a file does not exist, whereas "does not refer to a network namespace path" often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that "we will report back to the user that the open() failed but the user has no way of knowing why it failed"; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.(CVE-2022-47952)

Containers are insulated areas inside a system, which have their own namespace for filesystem, network, PID, IPC, CPU and memory allocation and which can be created using the Control Group and Namespace features included in the Linux kernel.

Security Fix(es):

lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because "Failed to open" often indicates that a file does not exist, whereas "does not refer to a network namespace path" often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that "we will report back to the user that the open() failed but the user has no way of knowing why it failed"; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.(CVE-2022-47952)

Containers are insulated areas inside a system, which have their own namespace for filesystem, network, PID, IPC, CPU and memory allocation and which can be created using the Control Group and Namespace features included in the Linux kernel.

Security Fix(es):

lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because "Failed to open" often indicates that a file does not exist, whereas "does not refer to a network namespace path" often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that "we will report back to the user that the open() failed but the user has no way of knowing why it failed"; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.(CVE-2022-47952)

lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because "Failed to open" often indicates that a file does not exist, whereas "does not refer to a network namespace path" often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that "we will report back to the user that the open() failed but the user has no way of knowing why it failed"; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.

This update for lxc fixes the following issues:

lxc was updated to 6.0.2:

The LXC team is pleased to announce the release of LXC 6.0.2! This is the second bugfix release for LXC 6.0 which is supported until June 2029.

As usual this bugfix releases focus on stability and hardening.

• Some of the highlights for this release are:

  • Reduced log level on some common messages
  • Fix compilation error on aarch64

• Detailed changelog

  • Remove unused function
  • idmap: Lower logging level of newXidmap tools to INFO
  • Exit 0 when there's no error
  • doc: Fix definitions of get_config_path and set_config_path
  • README: Update security contact
  • fix possible clang compile error in AARCH

Update to 6.0.1:

The LXC team is pleased to announce the release of LXC 6.0.1! This is the first bugfix release for LXC 6.0 which is supported until June 2029.

As usual this bugfix releases focus on stability and hardening.

• Highlights

  • Fixed some build tooling issues
  • Fixed startup failures on system without IPv6 support
  • Updated AppArmor rules to avoid potential warnings

Update to 6.0.0:

The LXC team is pleased to announce the release of LXC 6.0 LTS! This is the result of two years of work since the LXC 5.0 release and is the sixth LTS release for the LXC project. This release will be supported until June 2029.

• New multi-call binary�

  A new tools-multicall=true configuration option can be used to produce a single lxc binary which can then have all other lxc-XYZ commands be symlinked to. This allows for a massive disk space reduction, particularly useful for embedded platforms.

• Add a set_timeout function to the library

  A new set_timeout function is available on the main lxc_container struct and allow for setting a global timeout for interactions with the LXC monitor. Prior to this, there was no timeout, leading to potential deadlocks as there's also no way to cancel an monitor request. As a result of adding this new symbol to the library, we have bumped the liblxc symbol version to 1.8.0.

• LXC bridge now has IPV6 enabled

  The default lxcbr0 bridge now comes with IPv6 enabled by default, using an IPv6 ULA subnet. Support for uid/gid selection in lxc-usernsexec The lxc-usernsexec tool now has both -u and -g options to control what resulting UID and GID (respectively) the user wishes to use (defaulting to 0/0).

• Improvements to lxc-checkconfig

  lxc-checkconfig now only shows the version if lxc-start is present (rather than failing). Additionally, it's seen a number of other cosmetic improvements as well as now listing the maximum number of allowed namespaces for every namespace type.

• Support for squashfs OCI images

  The built-in oci container template can now handle squashfs compressed OCI images through the use of atomfs.

• Switched from systemd's dbus to dbus-1

  LXC now uses libdbus-1 for DBus interactions with systemd rather than using libsystemd. The reason for this change is that libdbus-1 is readily available for static builds.

• Removed Upstart support

  Support for the Upstart init system has finally been removed from LXC. This shouldn't really affect anyone at this stage and allowed for cleaning up some logic and config files from our repository.

These are all security issues fixed in the liblxc-devel-5.0.2-1.1 package on the GA media of openSUSE Tumbleweed.

Maher Azzouzi discovered that LXC did not correctly handle logging certain failure messages. An attacker could possibly use this issue to leak sensitive information. This issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS and Ubuntu 24.04 LTS. (CVE-2022-47952)

Sam Sanoop discovered that LXC did not correctly handle certain forms of user authorization. An attacker could possibly use this issue to cause a denial of service. (CVE-2026-39402)