similar to: CVE-2018-14634 and kernel-debuginfo ?

On Tue, Sep 25, 2018 at 11:48 AM Zube <Zube at stat.colostate.edu> wrote: > > The current mitigation for CVE-2018-14634 is a systemtap script > mentioned here: > > https://access.redhat.com/security/cve/cve-2018-14634 > > It also mentions that one can build a kernel module to distribute > to other machines, but in any case one needs the corresponding > debuginfo

I'm trying to debug what I believe to be a kernel bug (https://lists.centos.org/pipermail/centos-devel/2016-March/014463.html) and I'm trying to set up systemtap for that. I'm trying to set up systemtap on kernel 3.18.21-17.el6.x86_64 (Xen 4.4.3-10.el6) and it requires the kernel-debuginfo package, however I cannot find anywhere package kernel-debuginfo-3.18.21-17.el6.x86_64.rpm. In

On 7 March 2016 at 14:42, Johnny Hughes <johnny at centos.org> wrote: > On 03/03/2016 01:22 PM, Thanos Makatos wrote: >> I'm trying to debug what I believe to be a kernel bug >> (https://lists.centos.org/pipermail/centos-devel/2016-March/014463.html) >> and I'm trying to set up systemtap for that. >> >> I'm trying to set up systemtap on kernel

Hi! I'm trying systemtap on CentOS 6.2 kernel-2.6.32-220.23.1.el6.x86_64. My problem is that I can't find kernel-debuginfo... corresponding to my kernel version. The systemtap docs suggest rebuilding the kernel from sources, but it looks like I will have to install my own kernel, which is not acceptable on the production machine. Where can I find the debuginfo for the latest CentOS

I want to use systemtap on a 5.3 system but cannot find supporting kernel-PAE-debuginfo or kernel-debuginfo-common packages. Am I being a noob, or do these not exist for the PAE kernel? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20101202/82cc98b8/attachment-0002.html>

On Sat Oct 22 08:20:24 PM, Valeri Galtsev wrote: > I should have said CentOS 7. Older ones (CentOS 6 and 5) are not vulnerable. https://bugzilla.redhat.com/show_bug.cgi?id=1384344 Comment #35 points to a link that doesn't depend on /proc/self/mem and claims to work on CentOS 6 and 5. I'm not quite sure what I should be looking for when I run the program, though. I do hope Redhat

On 03/03/2016 01:22 PM, Thanos Makatos wrote: > I'm trying to debug what I believe to be a kernel bug > (https://lists.centos.org/pipermail/centos-devel/2016-March/014463.html) > and I'm trying to set up systemtap for that. > > I'm trying to set up systemtap on kernel 3.18.21-17.el6.x86_64 (Xen > 4.4.3-10.el6) and it requires the kernel-debuginfo package, however I

Ok, I got blktrace installed, but I also have some blktrace system taps that I want to test out, but it seems I need to have the kernel debug info installed to get systemtap working. Anyone know where the CentOS kernel-debuginfo RPMs are located? Ross S. W. Walker Information Systems Manager Medallion Financial, Corp. 437 Madison Avenue 38th Floor New York, NY 10022 Tel: (212) 328-2165 Fax:

Never had much trouble building on the Mac until this round. Trying to build 7.4p1 with openssl 1.0.2j on a MacOSX 10.12.2/3 machine. gcc --version returns clang-800.0.42.1. This is the latest Xcode. Builds fine. Upon running sshd, it seg faults with this in the logs: assertion failed 16C67: libsystem_trace.dynlib+76912 [5BD4ECD4-75CA-38EA-AF5C-B481C15955F8]: 0x0 If I run the tests, it

Good Day. In June, I posted a small query under the Subject of _odd smbpasswd / smbclient error from Linux to Solaris_ Briefly, a Solaris sparc server running 3.0.25a would not accept passwords from the Linux smbclient program if the password was 9 characters or greater. Instead, one would get this: session setup failed: NT_STATUS_LOGON_FAILURE but it worked fine with the Solaris sparc

Please use the systemtap script( https://paste.fedoraproject.org/paste/EGDa0ErwX0LV3y-gBYpfNA) to check which process is invoking remove xattr calls. It prints the pid, tid and arguments of all removexattr calls. I have checked for these fops at the protocol/client and posix translators. To run the script .. 1) install systemtap and dependencies. 2) install glusterfs-debuginfo 3) change the path

Ram, If you see it again, you can use this. I am going to send out a patch for the code path which can lead to removal of gfid/volume-id tomorrow. On Mon, Jul 10, 2017 at 5:19 PM, Sanoj Unnikrishnan <sunnikri at redhat.com> wrote: > Please use the systemtap script(https://paste.fedoraproject.org/paste/ > EGDa0ErwX0LV3y-gBYpfNA) to check which process is invoking remove xattr

On Tue, Oct 25, 2016 at 4:06 AM, Christian Anthon <anthon at rth.dk> wrote: > What is the best approach on centos 6 to mitigate the problem is > officially patched? As far as I can tell Centos 6 is vulnerable to attacks > using ptrace. > > There is a mitigation described here > > https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13 > > which doesn't fix the

Thanks for the swift turn around. Will try this out and let you know. Thanks and Regards, Ram From: Pranith Kumar Karampuri [mailto:pkarampu at redhat.com] Sent: Monday, July 10, 2017 8:31 AM To: Sanoj Unnikrishnan Cc: Ankireddypalle Reddy; Gluster Devel (gluster-devel at gluster.org); gluster-users at gluster.org Subject: Re: [Gluster-devel] gfid and volume-id extended attributes lost Ram,

Hi, Even though I am not running a centos.plus kernel yum wants to install the kernel-debuginfo for it. # yum install --disablerepo=\* --enablerepo=base-debuginfo kernel-debuginfo Loaded plugins: fastestmirror, refresh-packagekit Setting up Install Process Loading mirror speeds from cached hostfile Resolving Dependencies --> Running transaction check ---> Package kernel-debuginfo.x86_64

Hello all, According to [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64: "Debuginfo packages are also being signed and pushed. Yum configs shipped in the new release file will have all the context required for debuginfo to be available on every CentOS Linux install." Specifically, I'm looking for kernel-debuginfo-3.10.0-229.1.2.el7.x86_64, but the latest debuginfo

Ram, I sent https://review.gluster.org/17765 to fix the possibility in bulk removexattr. But I am not sure if this is indeed the reason for this issue. On Mon, Jul 10, 2017 at 6:30 PM, Ankireddypalle Reddy <areddy at commvault.com> wrote: > Thanks for the swift turn around. Will try this out and let you know. > > > > Thanks and Regards, > > Ram > > *From:*

Hi! On C7 I enabled the debuginfo repo and ran: debuginfo-install glibc-2.17-55.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.11.3-49.el7.x86_64 libcom_err-1.42.9-4.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 openssl-libs-1.0.1e-34.el7_0.4.x86_64 pcre-8.32-12.el7.x86_64 xz-libs-5.1.2-8alpha.el7.x86_64 zlib-1.2.7-13.el7.x86_64 Loaded plugins: fastestmirror, langpacks Loading mirror speeds

Hi all, This patch, though large, simply moves lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp and include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h. Why? Because this module has nothing to do with analysis. It simply defines an interface to the debug info MDNodes. In fact, the lib/VMCore/AsmWriter.cpp file performs a layering violation, because it calculates the DWARF tag

On Jun 27, 2012, at 4:20 PM, Eric Christopher wrote: > > On Jun 27, 2012, at 4:08 PM, Bill Wendling <wendling at apple.com> wrote: > >> Hi all, >> >> This patch, though large, simply moves lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp and include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h. >> >> Why? Because this module has