rm could malfunction under unusual circumstances:

When operating on a relative name longer than 511 bytes,
and (when either processing a directory that is neither writable
nor readable (but still searchable) or when determining whether
to prompt), and encountering an ENOMEM error while forming the
file name, rm would operate on a truncated-to-511-byte name
starting with "[...]" rather than the intended one.
* NEWS: Describe the bugs.
* src/remove.c: Correct two misuses of full_filename:
(full_filename0, xfull_filename): New functions.
(full_filename_): Rewrite to use full_filename0.
(AD_pop_and_chdir): Use xfull_filename, not full_filename.
(write_protected_non_symlink): Likewise.

1 files changed, 11 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index 295ef737f..beda7f860 100644
--- a/NEWS
+++ b/NEWS
@@ -199,6 +199,17 @@ GNU coreutils NEWS                                    -*- outline -*-
   pwd and "readlink -e ." no longer fail unnecessarily when a parent
   directory is unreadable.
 
+  rm (without -f) could prompt when it shouldn't, or fail to prompt
+  when it should, when operating on a full name longer than 511 bytes
+  and getting an ENOMEM error while trying to form the long name.
+
+  rm could mistakenly traverse into the wrong directory under unusual
+  conditions: when a full name longer than 511 bytes specifies a search-only
+  directory, and when forming that name fails with ENOMEM, rm would attempt
+  to open a truncated-to-511-byte name with the first five bytes replaced
+  with "[...]".  If such a directory were to actually exist, rm would attempt
+  to remove it.
+
   "rm -rf /etc/passwd" (run by non-root) now prints a diagnostic.
   Before it would print nothing.