https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 18:30:35 +0000 https://cve.radiocsirt.org/vuln/bdu:2020-05795 bdu:2020-05795 https://cve.radiocsirt.org/vuln/bdu:2020-05795 https://cve.radiocsirt.org/vuln/certfr-2020-avi-637 certfr-2020-avi-637 https://cve.radiocsirt.org/vuln/certfr-2020-avi-637 https://cve.radiocsirt.org/vuln/euvd-2026-168675 EUVD-2026-168675 https://cve.radiocsirt.org/vuln/euvd-2026-168675 https://cve.radiocsirt.org/vuln/fkie_cve-2020-16120 <p>Overlayfs did not properly perform permission checking when copying up files in an overlayfs and could be exploited from within a user namespace, if, for example, unprivileged user namespaces were allowed. It was possible to have a file not readable by an unprivileged user to be copied to a mountpoint controlled by the user, like a removable device. This was introduced in kernel version 4.19 by commit d1d04ef (&#34;ovl: stack file ops&#34;). This was fixed in kernel version 5.8 by commits 56230d9 (&#34;ovl: verify permissions in ovl_path_open()&#34;), 48bd024 (&#34;ovl: switch to mounter creds in readdir&#34;) and 05acefb (&#34;ovl: check permission to open real file&#34;). Additionally, commits 130fdbc (&#34;ovl: pass correct flags for opening real directory&#34;) and 292f902 (&#34;ovl: call secutiry hook in ovl_real_ioctl()&#34;) in kernel 5.8 might also be desired or necessary. These additional commits introduced a regression in overlay mounts within user namespaces which prevented access to files with ownership outside of the user namespace. This regression was mitigated by subsequent commit b6650da (&#34;ovl: do not fail because of O_NOATIMEi&#34;) in kernel 5.11.</p> <p>Overlayfs did not properly perform permission checking when copying up files in an overlayfs and could be exploited from within a user namespace, if, for example, unprivileged user namespaces were allowed. It was possible to have a file not readable by an unprivileged user to be copied to a mountpoint controlled by the user, like a removable device. This was introduced in kernel version 4.19 by commit d1d04ef (&#34;ovl: stack file ops&#34;). This was fixed in kernel version 5.8 by commits 56230d9 (&#34;ovl: verify permissions in ovl_path_open()&#34;), 48bd024 (&#34;ovl: switch to mounter creds in readdir&#34;) and 05acefb (&#34;ovl: check permission to open real file&#34;). Additionally, commits 130fdbc (&#34;ovl: pass correct flags for opening real directory&#34;) and 292f902 (&#34;ovl: call secutiry hook in ovl_real_ioctl()&#34;) in kernel 5.8 might also be desired or necessary. These additional commits introduced a regression in overlay mounts within user namespaces which prevented access to files with ownership outside of the user namespace. This regression was mitigated by subsequent commit b6650da (&#34;ovl: do not fail because of O_NOATIMEi&#34;) in kernel 5.11.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2020-16120 https://cve.radiocsirt.org/vuln/ghsa-q6jw-34cj-733v <p>Overlayfs did not properly perform permission checking when copying up files in an overlayfs and could be exploited from within a user namespace, if, for example, unprivileged user namespaces were allowed. It was possible to have a file not readable by an unprivileged user to be copied to a mountpoint controlled by the user, like a removable device. This was introduced in kernel version 4.19 by commit d1d04ef (&#34;ovl: stack file ops&#34;). This was fixed in kernel version 5.8 by commits 56230d9 (&#34;ovl: verify permissions in ovl_path_open()&#34;), 48bd024 (&#34;ovl: switch to mounter creds in readdir&#34;) and 05acefb (&#34;ovl: check permission to open real file&#34;). Additionally, commits 130fdbc (&#34;ovl: pass correct flags for opening real directory&#34;) and 292f902 (&#34;ovl: call secutiry hook in ovl_real_ioctl()&#34;) in kernel 5.8 might also be desired or necessary. These additional commits introduced a regression in overlay mounts within user namespaces which prevented access to files with ownership outside of the user namespace. This regression was mitigated by subsequent commit b6650da (&#34;ovl: do not fail because of O_NOATIMEi&#34;) in kernel 5.11.</p> <p>Overlayfs did not properly perform permission checking when copying up files in an overlayfs and could be exploited from within a user namespace, if, for example, unprivileged user namespaces were allowed. It was possible to have a file not readable by an unprivileged user to be copied to a mountpoint controlled by the user, like a removable device. This was introduced in kernel version 4.19 by commit d1d04ef (&#34;ovl: stack file ops&#34;). This was fixed in kernel version 5.8 by commits 56230d9 (&#34;ovl: verify permissions in ovl_path_open()&#34;), 48bd024 (&#34;ovl: switch to mounter creds in readdir&#34;) and 05acefb (&#34;ovl: check permission to open real file&#34;). Additionally, commits 130fdbc (&#34;ovl: pass correct flags for opening real directory&#34;) and 292f902 (&#34;ovl: call secutiry hook in ovl_real_ioctl()&#34;) in kernel 5.8 might also be desired or necessary. These additional commits introduced a regression in overlay mounts within user namespaces which prevented access to files with ownership outside of the user namespace. This regression was mitigated by subsequent commit b6650da (&#34;ovl: do not fail because of O_NOATIMEi&#34;) in kernel 5.11.</p> https://cve.radiocsirt.org/vuln/ghsa-q6jw-34cj-733v https://cve.radiocsirt.org/vuln/gsd-2020-16120 gsd-2020-16120 https://cve.radiocsirt.org/vuln/gsd-2020-16120 https://cve.radiocsirt.org/vuln/msrc_cve-2020-16120 msrc_CVE-2020-16120 https://cve.radiocsirt.org/vuln/msrc_cve-2020-16120 https://cve.radiocsirt.org/vuln/opensuse-su-2020:1906-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2020:1906-1 https://cve.radiocsirt.org/vuln/suse-su-2020:3122-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2020:3122-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2020-16120 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:16.04:LTS: linux-aws-hwe, Ubuntu:16.04:LTS: linux-azure, Ubuntu:16.04:LTS: linux-gcp, Ubuntu:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 69 more</p> <p>Overlayfs did not properly perform permission checking when copying up files in an overlayfs and could be exploited from within a user namespace, if, for example, unprivileged user namespaces were allowed. It was possible to have a file not readable by an unprivileged user to be copied to a mountpoint controlled by the user, like a removable device. This was introduced in kernel version 4.19 by commit d1d04ef (&#34;ovl: stack file ops&#34;). This was fixed in kernel version 5.8 by commits 56230d9 (&#34;ovl: verify permissions in ovl_path_open()&#34;), 48bd024 (&#34;ovl: switch to mounter creds in readdir&#34;) and 05acefb (&#34;ovl: check permission to open real file&#34;). Additionally, commits 130fdbc (&#34;ovl: pass correct flags for opening real directory&#34;) and 292f902 (&#34;ovl: call secutiry hook in ovl_real_ioctl()&#34;) in kernel 5.8 might also be desired or necessary. These additional commits introduced a regression in overlay mounts within user namespaces which prevented access to files with ownership outside of the user namespace. This regression was mitigated by subsequent commit b6650da (&#34;ovl: do not fail because of O_NOATIMEi&#34;) in kernel 5.11.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:16.04:LTS: linux-aws-hwe, Ubuntu:16.04:LTS: linux-azure, Ubuntu:16.04:LTS: linux-gcp, Ubuntu:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 69 more</p> <p>Overlayfs did not properly perform permission checking when copying up files in an overlayfs and could be exploited from within a user namespace, if, for example, unprivileged user namespaces were allowed. It was possible to have a file not readable by an unprivileged user to be copied to a mountpoint controlled by the user, like a removable device. This was introduced in kernel version 4.19 by commit d1d04ef (&#34;ovl: stack file ops&#34;). This was fixed in kernel version 5.8 by commits 56230d9 (&#34;ovl: verify permissions in ovl_path_open()&#34;), 48bd024 (&#34;ovl: switch to mounter creds in readdir&#34;) and 05acefb (&#34;ovl: check permission to open real file&#34;). Additionally, commits 130fdbc (&#34;ovl: pass correct flags for opening real directory&#34;) and 292f902 (&#34;ovl: call secutiry hook in ovl_real_ioctl()&#34;) in kernel 5.8 might also be desired or necessary. These additional commits introduced a regression in overlay mounts within user namespaces which prevented access to files with ownership outside of the user namespace. This regression was mitigated by subsequent commit b6650da (&#34;ovl: do not fail because of O_NOATIMEi&#34;) in kernel 5.11.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2020-16120 https://cve.radiocsirt.org/vuln/vde-2025-053 <p>Coreutils: heap overflow in split --line-bytes with very long lines Unprivileged overlay + shiftfs read access Nano: running `chmod` and `chown` on the filename allows malicious user to replace the emergency file with a malicious symlink to a root-owned file SSL_select_next_proto buffer overread Remote Code Execution in pypa/setuptools</p> <p>Coreutils: heap overflow in split --line-bytes with very long lines Unprivileged overlay + shiftfs read access Nano: running `chmod` and `chown` on the filename allows malicious user to replace the emergency file with a malicious symlink to a root-owned file SSL_select_next_proto buffer overread Remote Code Execution in pypa/setuptools</p> https://cve.radiocsirt.org/vuln/vde-2025-053 https://cve.radiocsirt.org/vuln/wid-sec-w-2022-1762 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um beliebigen Programmcode auszuführen, einen Denial of Service zu verursachen oder Informationen offenzulegen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um beliebigen Programmcode auszuführen, einen Denial of Service zu verursachen oder Informationen offenzulegen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2022-1762