kernel-packages team mailing list archive

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

** Description changed:

  SRU Justification:
  
  Impact: Since v3.15 the link of /proc/<pid>/exe will unconditionally be
  renamed to the previous name of a binary when the filename is short and
  the binary was running. For example foo is a daemon and running while
  dpkg installs a new version. dpkg will unpack as foo.dpkg-new first and
  then rename to foo. After that /proc/<pid>/exe of the running foo daemon
  will point to the (no non-existent) foo.dpkg-new. Which in turn causes
  start-stop-daemon if that is used post-install to fail finding the
  running instance.
  
  Fix: Backport of the following upstream change (which came with v3.17):
-   From d2fa4a8476b911782f7e5167db18770222ac40c3 Mon Sep 17 00:00:00 2001
-   From: Mikhail Efremov <sem@xxxxxxxxxxxx>
-   Date: Wed, 24 Sep 2014 22:14:33 +0400
-   Subject: [PATCH] vfs: Don't exchange "short" filenames unconditionally.
+   From d2fa4a8476b911782f7e5167db18770222ac40c3 Mon Sep 17 00:00:00 2001
+   From: Mikhail Efremov <sem@xxxxxxxxxxxx>
+   Date: Wed, 24 Sep 2014 22:14:33 +0400
+   Subject: [PATCH] vfs: Don't exchange "short" filenames unconditionally.
  
-   Only exchange source and destination filenames
-   if flags contain RENAME_EXCHANGE.
-   In case if executable file was running and replaced by
-   other file /proc/PID/exe should still show correct file name,
-   not the old name of the file by which it was replaced.
+   Only exchange source and destination filenames
+   if flags contain RENAME_EXCHANGE.
+   In case if executable file was running and replaced by
+   other file /proc/PID/exe should still show correct file name,
+   not the old name of the file by which it was replaced.
  
  Testcase: Any binary running that has a short (<= DNAME_INLINE_LEN)
  filename), copy the current binary to <oldname>.new and then move
  <oldname>.new to <oldname>. Now /proc/<pid>/exe of the running process
  points to <oldname>.new wihtout the change but remains to be <oldname>
  with the patch.
  
- 
  break-fix: da1ce0670c14d8380e423a3239e562a1dc15fa9e d2fa4a8476b911782f7e5167db18770222ac40c3
+ break-fix: da1ce0670c14d8380e423a3239e562a1dc15fa9e 3b01fb24b2a8cdfb49511046ad7d6463bdf0ed00

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1396907

Title:
  Uncondicionally exchanging short filenames breaks userspace

Status in “linux” package in Ubuntu:
  Triaged
Status in “linux” source package in Utopic:
  Triaged

Bug description:
  SRU Justification:

  Impact: Since v3.15 the link of /proc/<pid>/exe will unconditionally
  be renamed to the previous name of a binary when the filename is short
  and the binary was running. For example foo is a daemon and running
  while dpkg installs a new version. dpkg will unpack as foo.dpkg-new
  first and then rename to foo. After that /proc/<pid>/exe of the
  running foo daemon will point to the (no non-existent) foo.dpkg-new.
  Which in turn causes start-stop-daemon if that is used post-install to
  fail finding the running instance.

  Fix: Backport of the following upstream change (which came with v3.17):
    From d2fa4a8476b911782f7e5167db18770222ac40c3 Mon Sep 17 00:00:00 2001
    From: Mikhail Efremov <sem@xxxxxxxxxxxx>
    Date: Wed, 24 Sep 2014 22:14:33 +0400
    Subject: [PATCH] vfs: Don't exchange "short" filenames unconditionally.

    Only exchange source and destination filenames
    if flags contain RENAME_EXCHANGE.
    In case if executable file was running and replaced by
    other file /proc/PID/exe should still show correct file name,
    not the old name of the file by which it was replaced.

  Testcase: Any binary running that has a short (<= DNAME_INLINE_LEN)
  filename), copy the current binary to <oldname>.new and then move
  <oldname>.new to <oldname>. Now /proc/<pid>/exe of the running process
  points to <oldname>.new wihtout the change but remains to be <oldname>
  with the patch.

  break-fix: da1ce0670c14d8380e423a3239e562a1dc15fa9e d2fa4a8476b911782f7e5167db18770222ac40c3
  break-fix: da1ce0670c14d8380e423a3239e562a1dc15fa9e 3b01fb24b2a8cdfb49511046ad7d6463bdf0ed00

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1396907/+subscriptions