12 thoughts on - New Glibc For CentOS-6 And CentOS-7 And CVE-2015-7547

• Hi Johnny,

  Thank you as always, Should I be rebooting servers to ensure that all services are using the new glibc?

  sorry for the rookie question, just need some clarification.

  thanks

  Michael

• https://rhn.redhat.com/errata/RHSA-2016-0176.html https://rhn.redhat.com/errata/RHSA-2016-0175.html Please note that the ONLY way this is tested to work is with ALL

  It depends on your environment : it’s adviced to restart the node, but if you can’t, you can list the service[s] that depend on libc and
  (selectively) restart those (like sshd/httpd/postfix/…) on public facing nodes :

  lsof +c0 -d DEL | awk ‘NR==1 || /libc-/ {print $2,$1,$4,$NF}’ | column -t

  Source : https://access.redhat.com/articles/2161461

  –

• I am trying to find conclusive info on whether pre glibc version 2.9
  needs to be of concern. I have some older CentOS-5 machines running some older software, and they currently have glibc 2.5-123 installed. Some technical info i have read on this vulnerability states that the issue was introduced in version 2.9. But other less technical articles mention that older version “could” be vulnerable. Would appreciate any comments from the community on this.

• The easy answer is yes .. glibc requires so many things to be restarted, that is the best bet. Or certainly the easiest.

  Note: in CentOS 7, there is also a kernel update which is rated as Important .. so you should boot to that anyway:
  https://lists.CentOS.org/pipermail/CentOS-announce/2016-February/021705.html

  Here is a good link to figure out what to restart if you don’t want to reboot:

  https://rwmj.wordpress.com/2014/07/10/which-services-need-restarting-after-an-upgrade/

  and there is this thread:
  http://markmail.org/message/dodinyrhwgey35mh

  But generalyl, after a glibc update or a kernel update .. rebooting is easiest and it ensures everything is protected.

• Red Hat says no:
  https://access.redhat.com/security/cve/CVE-2015-7547

  Is it possible they are wrong .. I guess, anything is possible.

  You can test with this:

  https://github.com/fjserna/CVE-2015-7547

• Wow, so, I updated my server (yum update -y) which applied a new kernel and the new glibc among other things, After the update completed it knocked my master PostgreSQL database offline.

  Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database server… Feb 17 13:46:11 db1 pg_ctl: LOG: invalid value for parameter
  “max_stack_depth”: 16384
  Feb 17 13:46:11 db1 pg_ctl: DETAIL: “max_stack_depth” must not exceed
  7680kB. Feb 17 13:46:11 db1 pg_ctl: HINT: Increase the platform’s stack depth limit via “ulimit -s” or local equivalent. Feb 17 13:46:11 db1 pg_ctl: FATAL: configuration file
  “/var/lib/pgsql/data/PostgreSQL.conf” contains errors Feb 17 13:46:16 db1 pg_ctl: pg_ctl: could not start server Feb 17 13:46:16 db1 pg_ctl: Examine the log output. Feb 17 13:46:16 db1 systemd: PostgreSQL.service: control process exited, code=exited status=1
  Feb 17 13:46:16 db1 systemd: Failed to start PostgreSQL database server. Feb 17 13:46:16 db1 systemd: Unit PostgreSQL.service entered failed state. Feb 17 13:46:16 db1 systemd: PostgreSQL.service failed.

  I have kernel parameters specified in /etc/sysctl.conf

  vm.swappiness=0
  vm.overcommit_memory=2
  vm.overcommit_ratio

• Since you are talking about SystemD .. I assume c7.

  In c7 .. there is a symlink to /etc/sysctl.d/99-sysctl.conf to
  /etc/sysctl.conf

  Have you verified your sysctl.conf actually contains those settings still.

  Your best bet on CentOS-7 is to create a new file in /etc/sysctl.d/
  called something like 99-postgres.conf and put youjr mods in there. That way it will never change.

  Also .. verify all the files in /etc/sysctl.d/ and /etc/sysctl.conf are set to this label for selinux:

  unconfined_u:object_r:etc_t:s0

  See this for labeling:
  red.ht/1ooTpiI

  But, /etc/sysctl.conf should still work in CentOS-7.

• Looks like that is working (it seems to be reading your /etc/sysctl.conf file) based on your other post in this thread.

• Here is a good link to figure out what to restart if you don’t want to and there is this thread:
  Contents are still in tact.

  # ll -dZ /etc/sysctl.d drwxr-xr-x. root root system_u:object_r:etc_t:s0 /etc/sysctl.d

  # ll -Z /etc/sysctl.conf
  -rw-r–r–. root root system_u:object_r:system_conf_t:s0 /etc/sysctl.conf

  I tried restorecon -Frv /etc/sysctl* to no avail.

  Should I manually re-label these or is this an issue with the selinux-policy package having the incorrect defaults?

  Thanks,

  Michael

• Hi Johnny,

  Excuse my ignorance, if the sysctl.conf is working then why would my database throw this error still?

  state.

  Should my output from ulimit -a not correspond to my sysctl.conf parameters?

  This server was tested heavily and rebooted tens of times before it moved into production, I can’t understand what has changed other than now I get inconsistent output from

  sysctl -a and ulimit -a. I am quite confident this wasn’t the case before I updated today.

  ulimit -s is definitely not showing the correct parameter that I
  specified in /etc/sysctl.conf.

  Thanks,

  Michael

• Are you not confusing two unrelated things?

  man systemd.exec / LimitSTACK no?

  https://bugzilla.redhat.com/show_bug.cgi?idu0923 may point you further.

  jh

• Hi Jonny,

  A little google and I found my original conversation on here about setting it initially. Sorry for wasting your time on this,

  https://lists.CentOS.org/pipermail/CentOS/2015-August/154290.html

  So, the answer is that the service requires the LimitSTACK=[stack-size-in-bytes]
  in the [Service] section of
  /etc/systemd/system/multi-user.target.wants/PostgreSQL.service

  Thank you!

  Michael