Bug 1543405

Summary:	Much newer versions of memcached available
Product:	Red Hat Enterprise Linux 7	Reporter:	John Horne <john.horne>
Component:	memcached	Assignee:	Miroslav Lichvar <mlichvar>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-daemons
Severity:	medium	Docs Contact:
Priority:	low
Version:	7.4	CC:	bpowers, john.horne, mkolaja, thozza, unixi
Target Milestone:	rc	Keywords:	Rebase
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-12-12 14:00:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1471970, 1630905

Description John Horne 2018-02-08 12:10:57 UTC

Description of problem:
Just installed memcached onto a test server. Noticed that it is version 1.4.15.
Looking at the memcached website (https://github.com/memcached/memcached/wiki/ReleaseNotes), and it shows that this version was released over 5 years ago. Since then there have been many releases of memcached (29 of them).
I haven't looked through all the release notes, but I'm sure there are numerous bug fixes over the past 29 releases.

Is it possible that the version of mmecached released by RedHat can be brought a bit more up to date please?


Version-Release number of selected component (if applicable):
memcached-1.4.15-10.el7_3.1.x86_64


How reproducible:
Install memcached; run rpm -q memcached


Steps to Reproduce:
1. Install memcached
2. run 'rpm -q memcached'
3.

Actual results:
Old version of memcached is shown.

Expected results:
A release which is at least reasonably up to date (not over 5 years old).

Additional info:

Comment 2 Miroslav Lichvar 2018-02-14 13:38:33 UTC

Rebasing a package needs to be weighted against possible regressions and backporting fixes may be preferred over rebasing.

Are there any specific bugs that are causing a problem for you or features that you need? Contacting the Red Hat support would help with prioritizing the request.

Comment 3 John Horne 2018-02-14 17:31:31 UTC

We have only just started to look at using memcached on some servers. As such we have hit no bugs at the moment, but would obviously like to avoid doing so!

The concern was the number of releases, and bug fixes (shown in the release notes), and the time (5 years) from the 1.4.15 version to the present. Whilst we wouldn't expect all bug fixes to be backported - no point since providing a new release would do the same - it was felt that the released version (1.4.15) was perhaps just a bit too old.

If there are few bugs reported to RedHat by users, then I guess upgrading for upgrades sake may not be worthwhile. Perhaps we too will be lucky enough not to hit any bugs.

Close this call if you wish, as we have no bug as such to report.

Comment 4 John Horne 2018-03-13 10:41:44 UTC

(In reply to Miroslav Lichvar from comment #2)
> Rebasing a package needs to be weighted against possible regressions and
> backporting fixes may be preferred over rebasing.
> 
> Are there any specific bugs that are causing a problem for you...

Well we've just had our third crash of memcached on a CentOS7 server.

Basic details are:

=====
reason:         memcached killed by SIGSEGV
...
exploitable:
:Likely crash reason: Jump to an invalid address
:Exploitable rating (0-9 scale): 6
...
:[System Logs]:
:Mar 13 09:19:42 cent-4-021 kernel: memcached[26809]: segfault at 0 ip 000055a8c828f1a0 sp 00007f41f6c7da90 error 4 in memcached[55a8c8281000+19000]
=====

Comment 5 Miroslav Lichvar 2018-03-13 10:47:57 UTC

Do you have a reproducer for the crash? Or a coredump that could be used to make a backtrace?

Comment 6 John Horne 2018-03-13 11:07:32 UTC

The output from 'abrt-cli list --since 1520592029' shows:

===========
reason:         memcached killed by SIGSEGV
time:           Tue 13 Mar 2018 09:19:42 GMT
cmdline:        /usr/bin/memcached -u memcached -p 0 -m 1024 -c 1024 -s /run/   memcached/memcached.sock -a 0666 -v
package:        memcached-1.4.15-10.el7_3.1
uid:            990 (memcached)
count:          1
Directory:      /var/spool/abrt/ccpp-2018-03-13-09:19:42-26806
===========


The directory mentioned does contain a coredump. It is 103MB in size though.
If you want me to use gdb on it then you'll need to run through how. (It has been a long time since I used gdb.)

Comment 7 Miroslav Lichvar 2018-03-13 11:19:02 UTC

There is a short howto for generating backtraces:
https://wiki.centos.org/TipsAndTricks/ABRT#head-6ec8c2ca60fa7a4f2e8167a19299ea6d61217df2

Could you please file a new bug for memcached and attach the backtrace there?

Comment 8 John Horne 2018-03-13 13:11:48 UTC

As requested, new bug report filed for the segfault (#1554837).
Backtrace and other info attached to it.

Comment 10 Miroslav Lichvar 2018-07-31 07:02:52 UTC

*** Bug 1594877 has been marked as a duplicate of this bug. ***

Comment 11 Miroslav Lichvar 2018-07-31 07:18:32 UTC

Are there any suggestions to which version we should consider rebasing the memcached package? Some options had their defaults changed in 1.5.0 and also the UDP port was disabled in 1.5.6. I suspect this might cause regressions.

We could revert the defaults back to the pre-1.5.0 values, but I'm not sure if it wouldn't be confusing for users expecting a 1.5.* package to behave like the upstream memcached.

Comment 12 John Horne 2018-08-01 11:26:35 UTC

Perhaps rebase to 1.4.39 for RHEL7 as that version is not affected by CVE-2017-9951, then upgrade to memcached 1.5.x for RHEL8?

Comment 16 Red Hat Bugzilla Rules Engine 2018-12-12 14:00:41 UTC

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.