diff -u pam-1.1.8/debian/changelog pam-1.1.8/debian/changelog
--- pam-1.1.8/debian/changelog
+++ pam-1.1.8/debian/changelog
@@ -1,3 +1,10 @@
+pam (1.1.8-3.1ubuntu3) UNRELEASED; urgency=medium
+
+ * d/applied-patches/pam-limits-nofile-fd-setsize-cap: cap the default
+ soft nofile limit read from pid 1 to FD_SETSIZE.
+
+ -- Robie Basak <robie.basak@ubuntu.com> Tue, 21 Apr 2015 18:26:44 +0000
+
pam (1.1.8-3.1ubuntu2) vivid; urgency=medium
* debian/control:
diff -u pam-1.1.8/debian/patches-applied/series pam-1.1.8/debian/patches-applied/series
--- pam-1.1.8/debian/patches-applied/series
+++ pam-1.1.8/debian/patches-applied/series
@@ -31,0 +32 @@
+pam-limits-nofile-fd-setsize-cap
only in patch2:
unchanged:
--- pam-1.1.8.orig/debian/patches-applied/pam-limits-nofile-fd-setsize-cap
+++ pam-1.1.8/debian/patches-applied/pam-limits-nofile-fd-setsize-cap
@@ -0,0 +1,52 @@
+From: Robie Basak <robie.basak@ubuntu.com>
+Subject: pam_limits: cap the default soft nofile limit read from pid 1 to FD_SETSIZE
+
+Cap the default soft nofile limit read from pid 1 to FD_SETSIZE since
+larger values can cause problems with fd_set overflow and systemd sets
+itself higher.
+
+See:
+https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031446.html
+http://www.outflux.net/blog/archives/2014/06/13/5-year-old-glibc-select-weakness-fixed/
+https://sourceware.org/bugzilla/show_bug.cgi?id=10352
+https://github.com/systemd/systemd/commit/4096d6f5879aef73e20dd7b62a01f447629945b0
+
+Without this patch, the systemd switch in Ubuntu between Utopic and
+Vivid would cause both the soft and hard limits to jump to 65536. See
+systemd commit 4096d6f for an explanation of its behaviour. This change
+in systemd causes PAM to follow systemd's increased limit, which was not
+systemd's intention.
+
+If we want to make such a change to the default distribution soft limit
+in PAM, we should do it deliberately and carefully, not accidentally. A
+change should consider what uses select(2) and (incorrectly) assumes
+that file descriptors will always fit into an fd_set, what
+vulnerabilities or crashes the change could consequently create, and
+whether the protection now present with FORTIFY_SOURCE is suitably
+enabled in all relevant builds.
+
+So this keeps the soft limit at 1024 for now. The hard limit will rise
+to 65536 along with systemd. Anything that knows that it will not be
+buggy with respect to fd_set and FD_SETSIZE, such as by using poll(2) or
+epoll(7) instead of select(2), can always raise the soft limit itself
+without issue.
+
+Last-Update: 2015-04-21
+
+--- a/modules/pam_limits/pam_limits.c
++++ b/modules/pam_limits/pam_limits.c
+@@ -439,6 +439,14 @@ static void parse_kernel_limits(pam_hand
+ pl->limits[i].src_hard = LIMITS_DEF_KERNEL;
+ }
+ fclose(limitsfile);
++
++ /* Cap the default soft nofile limit read from pid 1 to FD_SETSIZE
++ * since larger values can cause problems with fd_set overflow and
++ * systemd sets itself higher. */
++ if (pl->limits[RLIMIT_NOFILE].src_soft == LIMITS_DEF_KERNEL &&
++ pl->limits[RLIMIT_NOFILE].limit.rlim_cur > FD_SETSIZE) {
++ pl->limits[RLIMIT_NOFILE].limit.rlim_cur = FD_SETSIZE;
++ }
+ }
+
+ static int init_limits(pam_handle_t *pamh, struct pam_limit_s *pl, int ctrl)