grsecurity forums

by **timbgo** » Thu Jan 26, 2017 11:23 pm

title: PAX: overwritten function pointer or return address, bans portage!
---
This first post may only be necessary if further analysis will need to be performed, so it is clear in what state the compromised system is kept for a few more weeks longer.

For the discussion on the Call Trace and the BUG in question and the PAX_RAP in (some) action, go to the next post.
---

Code: Select all: Jan 26 13:11:49 g5n kernel: [24570.397442] grsec: (admin:S:/) exec of /sbin/losetup (losetup /dev/loop1 /mnt/some-where/dd_170123_g0n.JIC/170123_g0n_sda4.dd ) by /sbin/losetup[bash:29221] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3997] uid/euid:0/0 gid/egid:0/0 Jan 26 13:11:57 g5n kernel: [24577.820950] grsec: (admin:S:/) exec of /sbin/blockdev (blockdev --setro /dev/loop1 ) by /sbin/blockdev[bash:29224] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3997] uid/euid:0/0 gid/egid:0/0 Jan 26 13:11:59 g5n kernel: [24579.808741] grsec: (admin:S:/) exec of /sbin/blockdev (blockdev --getro /dev/loop1 ) by /sbin/blockdev[bash:29226] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3997] uid/euid:0/0 gid/egid:0/0 Jan 26 13:12:13 g5n kernel: [24594.256370] grsec: (admin:S:/) exec of /bin/mount (mount /dev/loop1 /mnt/170123_g0n-r/ ) by /bin/mount[bash:29227] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3997] uid/euid:0/0 gid/egid:0/0 Jan 26 13:12:13 g5n kernel: [24594.341678] grsec: (:::kernel::::S:/) exec of /bin/kmod (/sbin/modprobe -q -- fs-crypto_LUKS grsec_modharden_fs ) by /bin/kmod[kworker/u8:4:29229] uid/euid:0/0 gid/egid:0/0, parent /[kworker/u8:4:29105] uid/euid:0/0 gid/egid:0/0 Jan 26 13:12:26 g5n kernel: [24607.496953] grsec: (admin:S:/) exec of /sbin/cryptsetup (cryptsetup luksOpen /dev/loop1 170123_g0n-r ) by /sbin/cryptsetup[bash:29231] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3997] uid/euid:0/0 gid/egid:0/0 Jan 26 13:12:37 g5n kernel: [24618.251423] grsec: (admin:S:/) exec of /bin/mount (mount /dev/mapper/170123_g0n-r /mnt/170123_g0n-r/ ) by /bin/mount[bash:29245] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3997] uid/euid:0/0 gid/egid:0/0 Jan 26 13:12:38 g5n kernel: [24618.617938] EXT4-fs (dm-3): INFO: recovery required on readonly filesystem Jan 26 13:12:38 g5n kernel: [24618.617940] EXT4-fs (dm-3): write access unavailable, cannot proceed

You get that if you perform these (and have grsecurity installed and
configured, which if you don't, you may be, IMO, missing some points about
Linux, or do not care at all about security; the latter is many people), this
is from my bash history:

Code: Select all: 686 losetup /dev/loop1 /mnt/some-where/dd_170123_g0n.JIC/170123_g0n_sda4.dd 687 blockdev --setro /dev/loop1 688 blockdev --getro /dev/loop1 689 mount /dev/loop1 /mnt/170123_g0n-r/ 690 cryptsetup luksOpen /dev/loop1 170123_g0n-r 691 mount /dev/mapper/170123_g0n-r /mnt/170123_g0n-r/

And the last command said this much on the command line:

Code: Select all: # mount /dev/mapper/170123_g0n-r /mnt/170123_g0n-r/ mount: /dev/mapper/170123_g0n-r is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/mapper/170123_g0n-r, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. #

I use the above method of mounting RO when I need (or like) to have
identifiable dd dumps of my system (quick note: after recovery the MD5 hash of
that dumped partition will not be the one of the time it was taken). Because
that is the system partion, the "/" partition, comprising /var /tmp /usr
/home, in short: complete system except /boot, the file:

Code: Select all: # ls -l /mnt/some-where/dd_170123_g0n.JIC/170123_g0n_sda4.dd -rw-r--r-- 1 root root 71167246848 2017-01-23 20:18 /mnt/some-where/dd_170123_g0n.JIC/170123_g0n_sda4.dd #

Likely, I'll have to mount it RW, else I won't be able to access the contents
of it (I'm not an expert).

But I'm not going to do that in this Air-Gapped system. Because I don't know
if there is any risk involved. Certainly mounting a system RW is not the same
as mounting it RO... I just don't know if there would be any risk involved.
And with my Air-Gapped I practice extreme caution...

So I moved the medium where that image is stored into the same-hardware clone
of this Air-Gapped system, and did a simpler procedure than above, I did this:

Code: Select all: # cryptsetup luksOpen /mnt/sdg1/dd_Add/dd_170123_g0n.JIC/170123_g0n_sda4.dd 170123_g0n-r # mount /dev/mapper/170123_g0n-r /mnt/170123_g0n-r/

And...:

Code: Select all: Jan 26 14:13:03 g0n kernel: [21695.817744] grsec: (admin:S:/) exec of /bin/mount (mount /mnt/sdg1/dd_Add/dd_170123_g0n.JIC/170123_g0n_sda4.dd /mnt/170123_g0n-r/ ) by /bin/mount[bash:5463] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:4245] uid/euid:0/0 gid/egid:0/0 Jan 26 14:13:04 g0n kernel: [21696.483879] grsec: (:::kernel::::S:/) exec of /bin/kmod (/sbin/modprobe -q -- fs-crypto_LUKS grsec_modharden_fs ) by /bin/kmod[kworker/u8:1:5468] uid/euid:0/0 gid/egid:0/0, parent /[kworker/u8:1:5418] uid/euid:0/0 gid/egid:0/0 Jan 26 14:13:26 g0n kernel: [21718.947863] grsec: (admin:S:/) exec of /sbin/cryptsetup (cryptsetup luksOpen /mnt/sdg1/dd_Add/dd_170123_g0n.JIC/170123_g0n_sda4.dd 170123_g0n-r ) by /sbin/cryptsetup[bash:5469] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:4245] uid/euid:0/0 gid/egid:0/0 Jan 26 14:14:16 g0n kernel: [21768.433008] grsec: (admin:S:/) exec of /bin/mount (mount /dev/mapper/170123_g0n-r /mnt/170123_g0n-r/ ) by /bin/mount[bash:5482] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:4245] uid/euid:0/0 gid/egid:0/0 Jan 26 14:14:17 g0n kernel: [21769.724488] EXT4-fs (dm-2): recovery complete Jan 26 14:14:17 g0n kernel: [21769.778511] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) Jan 26 14:14:17 g0n kernel: [21769.778556] grsec: (admin:S:/) mount of /dev/mapper/170123_g0n-r to /mnt/170123_g0n-r by /bin/mount[mount:5482] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:4245] uid/euid:0/0 gid/egid:0/0

...And that's what happened there.

And now it works fine here in Air-Gapped, mounting it RO:

Code: Select all: g5n ~ # losetup /dev/loop1 /mnt/sdg1/dd_Add/dd_170123_g0n.JIC/170123_g0n_sda4.dd g5n ~ # ^C g5n ~ # blockdev --setro /dev/loop1 g5n ~ # blockdev --getro /dev/loop1 1 g5n ~ # cryptsetup luksOpen /dev/loop1 170123_g0n-r Enter passphrase for /mnt/sdg1/dd_Add/dd_170123_g0n.JIC/170123_g0n_sda4.dd: g5n ~ # mount /dev/mapper/170123_g0n-r /mnt/170123_g0n-r/ mount: /dev/mapper/170123_g0n-r is write-protected, mounting read-only g5n ~ #

If anyone on the upward curve of learning Linux is struggling with these
above, I wrote about it years ago now at:
Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion
https://forums.gentoo.org/viewtopic-t-999436.html
where go to PART 2.

I'm only using now the methods of how Air-Gapping (linked from that Gentoo
topic) and backup/cloning is done, to analyze what happened with my system
which at the time of the compromise (three days ago now! --and counting, only
started to write--, boy, did it caught me by surprise! and did I work to
improve things in my systems since! I never even went online since!)...

To analyze what happened with my system which at the time of the compromise
was at the place of the clone (I mean it's the same machine) that I used to
recover the ext4 filesystem, which recover I didn't want to do in the
Air-Gapped system.

(You figure now, I hope, that the cloned system, deploying the methods that I
use, is fully recoverable.)

by **timbgo** » Thu Jan 26, 2017 11:28 pm

title: PAX: overwritten function pointer or return address, bans portage!
---

In short, what happened is, the main worker/maintainer/installer, the kind and loving lassie at the heart of of Gentoo FOSS GNU Linux, the Portage, got banned by PAX. Have a look:

Code: Select all: Jan 23 09:29:02 g0n kernel: [573011.427220] ------------[ cut here ]------------ Jan 23 09:29:02 g0n kernel: [573011.427262] kernel BUG at mm/memory.c:1660! Jan 23 09:29:02 g0n kernel: [573011.427292] PAX: overwritten function pointer or return address detected: 0000 [#1] PREEMPT SMP Jan 23 09:29:02 g0n kernel: [573011.427351] Modules linked in: Jan 23 09:29:02 g0n kernel: [573011.427375] CPU: 0 PID: 3239 Comm: x86_64-pc-linux Not tainted 4.8.17-hardened-r1-170115_11 #1 Jan 23 09:29:02 g0n kernel: [573011.427429] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P2.60 11/11/2013 Jan 23 09:29:02 g0n kernel: [573011.427490] task: ffff8803c828dc40 task.stack: ffffc90005fd0000 Jan 23 09:29:02 g0n kernel: [573011.427528] RIP: 0010:[<ffffffff81170ffb>] [<ffffffff81170ffb>] vm_insert_pfn_prot+0x44/0xbc Jan 23 09:29:02 g0n kernel: [573011.427586] RSP: 0000:ffffc90005fd3cf8 EFLAGS: 00010246 Jan 23 09:29:02 g0n kernel: [573011.427620] RAX: 0000000004044431 RBX: ffff8803c8cca000 RCX: 8000000000000025 Jan 23 09:29:02 g0n kernel: [573011.427664] RDX: 0000000000000020 RSI: 000003a12adfc000 RDI: ffff8803c8cca000 Jan 23 09:29:02 g0n kernel: [573011.427708] RBP: ffffc90005fd3d18 R08: 0000000000000000 R09: ffff8803c828e5d8 Jan 23 09:29:02 g0n kernel: [573011.427752] R10: ffffc90005fd3eb0 R11: 000003a12a312650 R12: 00000000000024c5 Jan 23 09:29:02 g0n kernel: [573011.427796] R13: 000003a12adfc000 R14: 0000000000000000 R15: 0000000000000000 Jan 23 09:29:02 g0n kernel: [573011.427868] FS: 000003a12adc1740(0000) GS:ffff88041fc00000(0000) knlGS:0000000000000000 Jan 23 09:29:02 g0n kernel: [573011.427918] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 23 09:29:02 g0n kernel: [573011.427954] CR2: 000003a12adfc080 CR3: 000000000219d000 CR4: 00000000000006f0 Jan 23 09:29:02 g0n kernel: [573011.427998] Stack: Jan 23 09:29:02 g0n kernel: [573011.428012] 8000000000000025 ffff8803c8cca000 ffffc90005fd3d98 ffffc90005fd3e28 Jan 23 09:29:02 g0n kernel: [573011.428064] ffffc90005fd3d40 ffffffff8117109f ffff8803c8cca000 000003a12adfc000 Jan 23 09:29:02 g0n kernel: [573011.428116] 00000000000024c5 ffffc90005fd3d60 ffffffff81001895 ffffc90005fd3d98 Jan 23 09:29:02 g0n kernel: [573011.428168] Call Trace: Jan 23 09:29:02 g0n kernel: [573011.428188] [<ffffffff8117109f>] vm_insert_pfn+0x2c/0x3c Jan 23 09:29:02 g0n kernel: [573011.428227] [<ffffffff81001895>] vvar_fault+0x5f/0x84 Jan 23 09:29:02 g0n kernel: [573011.428264] [<ffffffff811747da>] special_mapping_fault+0x4b/0xae Jan 23 09:29:02 g0n kernel: [573011.428307] [<ffffffff8116da62>] __do_fault+0x93/0xe5 Jan 23 09:29:02 g0n kernel: [573011.428344] [<ffffffff81171949>] handle_mm_fault+0x434/0x944 Jan 23 09:29:02 g0n kernel: [573011.428385] [<ffffffff81081e88>] __do_page_fault+0x202/0x3ea Jan 23 09:29:02 g0n kernel: [573011.428426] [<ffffffff81081e88>] ? __do_page_fault+0x202/0x3ea Jan 23 09:29:02 g0n kernel: [573011.428467] [<ffffffff810820bf>] do_page_fault+0x20/0x30 Jan 23 09:29:02 g0n kernel: [573011.428506] [<ffffffff81ba9722>] page_fault+0x22/0x30 Jan 23 09:29:02 g0n kernel: [573011.428542] Code: 8b 03 48 89 c2 81 e2 00 04 00 10 75 02 0f 0b 48 81 fa 00 04 00 10 75 02 0f 0b f6 c4 04 74 0e 48 89 c2 83 e2 28 48 83 fa 20 75 02 <0f> 0b a9 00 00 00 10 74 0e 4c 89 e7 e8 1e bf ff ff 85 c0 74 02 Jan 23 09:29:02 g0n kernel: [573011.428785] RIP [<ffffffff81170ffb>] vm_insert_pfn_prot+0x44/0xbc Jan 23 09:29:02 g0n kernel: [573011.428830] RSP <ffffc90005fd3cf8> Jan 23 09:29:02 g0n kernel: [573011.435006] ---[ end trace 1f4c0a12fd251556 ]--- Jan 23 09:29:02 g0n kernel: [573011.435009] grsec: banning user with uid 250 until system restart for suspicious kernel crash

The "user with uid 250" is Miss Portage Herself! (And you bet grsec held its promise to ban Her!) See:

Code: Select all: # cat /etc/passwd | grep 250 portage:x:250:250:portage:/var/tmp/portage:/bin/false #

Looking at during what task it happened, and remembering that I tried to updated that machine (test-update only, the real updated is in the Air-Gapped, from which other clone-system are derived), I see:

Code: Select all: # ls -ltr /mnt/170123_g0n-r/root/ | grep emerge -rw-r--r-- 1 root root 2439 2017-01-18 02:57 emerge_noscript_1484704583 -rw-r--r-- 1 root root 708 2017-01-23 08:39 emerge-tuDN_world_1485157127 -rw-r--r-- 1 root root 33237 2017-01-23 08:50 emerge-tuDN_world_1485157653 -rw-r--r-- 1 root root 10489406 2017-01-23 09:29 emerge-tuDN_libixion_1485157907 -rw-r--r-- 1 root root 3218 2017-01-23 09:29 emerge-r_1485160173 -rw-r--r-- 1 root root 3742 2017-01-23 09:34 emerge-tuDN_libixion_1485160283 -rw-r--r-- 1 root root 2126 2017-01-23 09:46 emerge-tuDN_libixion_1485160852 -rw-r--r-- 1 root root 2134 2017-01-23 09:47 emerge-tuDN_libixion_1485161210 -rw-r--r-- 1 root root 2125 2017-01-23 09:50 emerge-tuDN_libixion_1485161367 -rw-r--r-- 1 root root 2127 2017-01-23 09:51 emerge-tuDN_libixion_1485161437 #

So, I'll try and show you what it was...

But first, to make it more understandable, it was about failing to update texlive, as there is a thread on gentoo-user mailing list, where I (this is from the same system log):

Code: Select all: Jan 23 17:34:19 g0n postfix/smtp[9992]: A9AC92A3: to=<[email protected]>, relay=xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]:587, delay=0.28, delays=0.07/0.02/0.18/0.01, dsn=2.0.0, status=sent (250 OK id=1cVhZA-0005vs-Nh) Jan 23 17:34:19 g0n postfix/smtp[9992]: name_mask: resource Jan 23 17:34:19 g0n postfix/smtp[9992]: name_mask: software Jan 23 17:34:19 g0n postfix/smtp[9992]: disposing SASL state information Jan 23 17:34:19 g0n postfix/qmgr[4007]: A9AC92A3: removed

sent this email:

trouble updating texlive
https://lists.gt.net/gentoo/user/322062#322062

at that time (CET).

This one:

Code: Select all: -rw-r--r-- 1 root root 10489406 2017-01-23 09:29 emerge-tuDN_libixion_1485157907

contains (just excerpts of it I'll be pasting in):

Code: Select all: ... >>> Emerging (21 of 34) app-arch/tar-1.29-r3::gentoo * tar-1.29.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking tar-1.29.tar.bz2 to /var/tmp/portage/app-arch/tar-1.29-r3/work >>> Source unpacked in /var/tmp/portage/app-arch/tar-1.29-r3/work >>> Preparing source in /var/tmp/portage/app-arch/tar-1.29-r3/work/tar-1.29 ... * Applying tar-1.29-extract-pathname-bypass-upstream.patch ... [ ok ] * Applying tar-1.29-add-files.patch ... [ ok ] >>> Source prepared. ...

Code: Select all: ... checking for getcwd... yes checking for readlink... yes checking for realpath... * The ebuild phase 'configure' has been killed by signal 9. >>> Failed to emerge app-arch/tar-1.29-r3, Log file: >>> '/var/log/portage/app-arch:tar-1.29-r3:20170123-082847.log' These are the packages that would be merged, in reverse order: Calculating dependencies *** Resuming merge... ... done! [ebuild R ] app-office/libreoffice-5.2.4.2::gentoo USE="branding cups gstreamer gtk (-aqua) -bluetooth -coinmp -collada -dbus -debug -eds (-firebird) -gltf -gnome -googledrive -gtk3 -java -jemalloc -kde -libressl -mysql -odk -pdfimport -postgres -quickstarter (-telepathy) {-test} -vlc" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_4 -python2_7 -python3_5" PYTHON_TARGETS="python2_7 python3_4 -python3_5" 0 KiB ...

Code: Select all: ... [blocks B ] media-gfx/graphicsmagick[imagemagick] ("media-gfx/graphicsmagick[imagemagick]" is blocking media-gfx/imagemagick-6.9.7.4) Total: 78 packages (69 upgrades, 4 new, 2 in new slots, 3 reinstalls), Size of downloads: 437,368 KiB Conflict: 4 blocks (4 unsatisfied) !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: ...

And the recalculating the dependencies led here to, strangely 78 packages needing to upgrade (and failing for the texlive reason as in the gentoo-user MK thread linked), while there were already 20 apparently correctly merged packages out of 34 at the onset of the portage's work. Ummh!

The point, however is that the Call Trace happened at the time of that portage's incompleted session, compare:

Code: Select all: -rw-r--r-- 1 root root 10489406 2017-01-23 09:29 emerge-tuDN_libixion_1485157907

to:

Code: Select all: Jan 23 09:29:02 g0n kernel: [573011.427220] ------------[ cut here ]------------ Jan 23 09:29:02 g0n kernel: [573011.427262] kernel BUG at mm/memory.c:1660!

And I did try more of emerging, for twenty more minutes:

Code: Select all: -rw-r--r-- 1 root root 3742 2017-01-23 09:34 emerge-tuDN_libixion_1485160283 -rw-r--r-- 1 root root 2126 2017-01-23 09:46 emerge-tuDN_libixion_1485160852 -rw-r--r-- 1 root root 2134 2017-01-23 09:47 emerge-tuDN_libixion_1485161210 -rw-r--r-- 1 root root 2125 2017-01-23 09:50 emerge-tuDN_libixion_1485161367 -rw-r--r-- 1 root root 2127 2017-01-23 09:51 emerge-tuDN_libixion_1485161437

...But it would always fail, excerpts only pasting, from emerge-tuDN_libixion_1485160283:

Code: Select all: These are the packages that would be merged, in reverse order: Calculating dependencies ..... done! [nomerge ] x11-libs/gtk+-2.24.31-r1:2::gentoo USE="vim-syntax (-aqua) -cups -examples -introspection {-test} -xinerama" ABI_X86="32 (64) (-x32)" ... [ebuild U ] app-eselect/eselect-mesa-0.0.10-r1::gentoo [0.0.10::gentoo] 0 KiB Total: 4 packages (4 upgrades), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Running pre-merge checks for sys-devel/llvm-3.9.1-r1 * Checking for at least 1100 MiB disk space at "/var/tmp/portage/sys-devel/llvm-3.9.1-r1/temp" ... [ ok ] >>> Emerging (1 of 4) app-eselect/eselect-mesa-0.0.10-r1::gentoo * eselect-mesa-0.0.10.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * The ebuild phase 'unpack' has been killed by signal 9. ... These are the packages that would be merged, in reverse order: Calculating dependencies *** Resuming merge... ... done! [nomerge ] x11-libs/gtk+-2.24.31-r1:2::gentoo USE="vim-syntax (-aqua) -cups -examples -introspection {-test} -xinerama" ABI_X86="32 (64) (-x32)" ... >>> Emerging (1 of 3) sys-devel/llvm-3.9.1-r1::gentoo * llvm-3.9.1.src.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * llvm-3.9.0_rc3-manpages.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * Checking for at least 1100 MiB disk space at "/var/tmp/portage/sys-devel/llvm-3.9.1-r1/temp" ... [ ok ] * The ebuild phase 'unpack' has been killed by signal 9.

Likewise also the:

Code: Select all: emerge-tuDN_libixion_1485160852 emerge-tuDN_libixion_1485161210 emerge-tuDN_libixion_1485161367 emerge-tuDN_libixion_1485161437

Well, after that, I didn't connect much to the internet (and of course, I wasn't, I never am, online while I set portage to work), I only sent a two or three emails, so just minutes online after that fine work (probably fine, as it usually is such) by grsecurity/PAX.

But I didn't notice any serious other malfunctioning, and I can also tell that I compared the shutdown with normal shutdowns logged previously, which I perform as GRADM-enabled user shutdown, and noticed minimal, or no, misbehavior... So not sure why the system appear corrupted... Maybe I didn't wait longer, but pressed the the reset button on the hardware? I don't remember at this time (but I think that I didn't).

Be it as it may, I did the search for the apparent carrier used by the culprit functionality:

Code: Select all: # grep -r vm_insert_pfn_prot /usr/include/ #

( nothing found )

And:

Code: Select all: # grep -r vm_insert_pfn_prot /mnt/170123_g0n-r/usr/ ...

finds some.

However, I decided I'd devide those that it finds per kernel, because this
search:

Code: Select all: # grep -r vm_insert_pfn_prot /mnt/170123_g0n-r/usr/ | grep -v '\/usr\/src' #

is empty.

So I grep'd like this:

Code: Select all: # for i in $(ls -1d /mnt/170123_g0n-r/usr/src/linux-4.*) ; do j=$(echo $i | sed 's$/mnt/170123_g0n-r/usr/src/$$'|sed 's/://'); echo $j ; grep -r vm_insert_pfn_prot $i >> /some/where/Gen_170123_compromise_2.txt_ADD_${j} ; done ;

And I got founds in these files:

Code: Select all: # ls -l /some/where/Gen_170123_compromise_2.txt_ADD_linux* -rw-r--r-- 1 root root 0 2017-01-26 18:10 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.4.8-hardened-r1 -rw-r--r-- 1 root root 1396 2017-01-26 18:11 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.12 -rw-r--r-- 1 root root 1813 2017-01-26 18:11 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.12-hardened-r1 -rw-r--r-- 1 root root 1759 2017-01-26 18:12 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.14-hardened -rw-r--r-- 1 root root 1759 2017-01-26 18:12 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.15-hardened -rw-r--r-- 1 root root 1813 2017-01-26 18:12 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.15-hardened-r1 -rw-r--r-- 1 root root 1813 2017-01-26 18:13 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.15-hardened-r2 -rw-r--r-- 1 root root 1759 2017-01-26 18:13 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.16-hardened -rw-r--r-- 1 root root 2578 2017-01-26 18:14 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.17-hardened-r1 -rw-r--r-- 1 root root 1380 2017-01-26 18:15 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.9.0 -rw-r--r-- 1 root root 1380 2017-01-26 18:15 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.9.1 -rw-r--r-- 1 root root 1380 2017-01-26 18:15 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.9.3 -rw-r--r-- 1 root root 2067 2017-01-26 18:17 /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.9.4 #

And here's just the probably relevant one (the kernel that was active at the
time):

# cat /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.17-hardened-r1 :

Code: Select all: Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/arch/x86/boot/compressed/vmlinux.bin matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/.tmp_vmlinux1 matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/mm/built-in.o matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/mm/memory.o matches /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/mm/memory.c: return vm_insert_pfn_prot(vma, addr, pfn, vma->vm_page_prot); /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/mm/memory.c: * vm_insert_pfn_prot - insert single pfn into user vma with specified pgprot /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/mm/memory.c: * vm_insert_pfn_prot should only be used if using multiple VMAs is /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/mm/memory.c:int vm_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr, /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/mm/memory.c:EXPORT_SYMBOL(vm_insert_pfn_prot); Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/vmlinux matches /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/Module.symvers:0xb74c5f0d vm_insert_pfn_prot vmlinux EXPORT_SYMBOL /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/System.map:000000002c400060 A __rap_hash_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/System.map:ffffffff81170fb7 T vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/System.map:ffffffff821f7610 R __ksymtab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/System.map:ffffffff82213160 r __kcrctab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/System.map:ffffffff82222f48 r __kstrtab_vm_insert_pfn_prot Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/vmlinux.o matches /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/include/linux/mm.h:int vm_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr, Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/.tmp_vmlinux2 matches /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/.tmp_System.map:000000002c400060 A __rap_hash_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/.tmp_System.map:ffffffff81170fb7 T vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/.tmp_System.map:ffffffff821f7610 R __ksymtab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/.tmp_System.map:ffffffff82213160 r __kcrctab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.17-hardened-r1/.tmp_System.map:ffffffff82222f48 r __kstrtab_vm_insert_pfn_prot

And maybe just two or three more, for completeness:
# cat /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.8.16-hardened :

Code: Select all: Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/arch/x86/boot/compressed/vmlinux.bin matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/.tmp_vmlinux1 matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/mm/built-in.o matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/mm/memory.o matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/vmlinux matches /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/Module.symvers:0xb74c5f0d vm_insert_pfn_prot vmlinux EXPORT_SYMBOL /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/System.map:000000002c400060 A __rap_hash_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/System.map:ffffffff81170e4a T vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/System.map:ffffffff821f55a0 R __ksymtab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/System.map:ffffffff822110f0 r __kcrctab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/System.map:ffffffff82220ed8 r __kstrtab_vm_insert_pfn_prot Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/vmlinux.o matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/.tmp_vmlinux2 matches /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/.tmp_System.map:000000002c400060 A __rap_hash_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/.tmp_System.map:ffffffff81170e4a T vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/.tmp_System.map:ffffffff821f55a0 R __ksymtab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/.tmp_System.map:ffffffff822110f0 r __kcrctab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.8.16-hardened/.tmp_System.map:ffffffff82220ed8 r __kstrtab_vm_insert_pfn_prot

# cat /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.9.3 :

Code: Select all: Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.3/arch/x86/boot/compressed/vmlinux.bin matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.3/.tmp_vmlinux1 matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.3/mm/built-in.o matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.3/mm/memory.o matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.3/vmlinux matches /mnt/170123_g0n-r/usr/src/linux-4.9.3/Module.symvers:0x5715c3b8 vm_insert_pfn_prot vmlinux EXPORT_SYMBOL /mnt/170123_g0n-r/usr/src/linux-4.9.3/System.map:ffffffff8112a81a T vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.3/System.map:ffffffff81e59f30 r __ksymtab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.3/System.map:ffffffff81e75c40 r __kcrctab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.3/System.map:ffffffff81e85977 r __kstrtab_vm_insert_pfn_prot Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.3/vmlinux.o matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.3/.tmp_vmlinux2 matches /mnt/170123_g0n-r/usr/src/linux-4.9.3/.tmp_System.map:ffffffff8112a81a T vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.3/.tmp_System.map:ffffffff81e59f30 r __ksymtab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.3/.tmp_System.map:ffffffff81e75c40 r __kcrctab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.3/.tmp_System.map:ffffffff81e85977 r __kstrtab_vm_insert_pfn_prot

# cat /some/where/Gen_170123_compromise_2.txt_ADD_linux-4.9.4 :

Code: Select all: Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.4/arch/x86/boot/compressed/vmlinux.bin matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.4/.tmp_vmlinux1 matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.4/mm/built-in.o matches Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.4/mm/memory.o matches /mnt/170123_g0n-r/usr/src/linux-4.9.4/mm/memory.c: return vm_insert_pfn_prot(vma, addr, pfn, vma->vm_page_prot); /mnt/170123_g0n-r/usr/src/linux-4.9.4/mm/memory.c: * vm_insert_pfn_prot - insert single pfn into user vma with specified pgprot /mnt/170123_g0n-r/usr/src/linux-4.9.4/mm/memory.c: * vm_insert_pfn_prot should only be used if using multiple VMAs is /mnt/170123_g0n-r/usr/src/linux-4.9.4/mm/memory.c:int vm_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr, /mnt/170123_g0n-r/usr/src/linux-4.9.4/mm/memory.c:EXPORT_SYMBOL(vm_insert_pfn_prot); Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.4/vmlinux matches /mnt/170123_g0n-r/usr/src/linux-4.9.4/Module.symvers:0x5715c3b8 vm_insert_pfn_prot vmlinux EXPORT_SYMBOL /mnt/170123_g0n-r/usr/src/linux-4.9.4/System.map:ffffffff8112a81a T vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.4/System.map:ffffffff81e59f20 r __ksymtab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.4/System.map:ffffffff81e75c30 r __kcrctab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.4/System.map:ffffffff81e85967 r __kstrtab_vm_insert_pfn_prot Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.4/vmlinux.o matches /mnt/170123_g0n-r/usr/src/linux-4.9.4/include/linux/mm.h:int vm_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr, Binary file /mnt/170123_g0n-r/usr/src/linux-4.9.4/.tmp_vmlinux2 matches /mnt/170123_g0n-r/usr/src/linux-4.9.4/.tmp_System.map:ffffffff8112a81a T vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.4/.tmp_System.map:ffffffff81e59f20 r __ksymtab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.4/.tmp_System.map:ffffffff81e75c30 r __kcrctab_vm_insert_pfn_prot /mnt/170123_g0n-r/usr/src/linux-4.9.4/.tmp_System.map:ffffffff81e85967 r __kstrtab_vm_insert_pfn_prot

I vaguely understand (not precisely because I'm still at the basics of C) that:

Code: Select all: ... kernel BUG at mm/memory.c:1660! ... PAX: overwritten function pointer or return address detected

is a serious issue. The mm/memory.c is pretty central. And the issue is about some corruption/intrusion or some such...

And I have much more to learn before I understand what exactly that function and its associates do... (likely vm is for [v]irtual [m]achine, but the rest...). And return address is about the PAX_RAP [1] (which in non-paid-for-support grsecurity --my case-- is only at demo protection, due to licensing issues with the gcc plugins that it deploys). But how all of this happened is too complex for me at this time.

And being my installation at the demo protection level in regardt to PAX_RAP, the question is also what else the attacking functionality could have used, which defenceless other structure --or whatever to call them-- of my machine...

OTOH, I feel that this issue shows I've been using grsecurity hardening correctly, and that Gentoo is delivering it correctly. The attacking functionality could apparently only use weaknesses that could not be covered, for the above mentioned licensing issues, in the grsecurity hardening deployment.

Little comfort though... How do I protect my system in those weaknesses that are left exposed? No finances here, I'm poor as a church mouse... And also I love FOSS, and dream --very little more than only dream-- of contributing to FOSS, in return for all that I get from FOSS...

And how did it happened that those functions were used for the overwriting of pointer(s)/address(es)?

My fault, of course, is that, I think, I forgot to run "make clean" or "make mrproper" in those kernel sources... Won't be happening any more, not that easily after this.

Also, the compromise is not from the Gentoo distribution, well not directly at least. Because, at that same time I was doing the same kind of emerge'ing, delayed at first, to see how the test-emerging would fare, in the Air-Gapped, and there wasn't any kind of errors whatsoever. However, the Air-Gapped does not see any internet and anything that I bring from the internet comes to my cloned machines first, and into it only after careful inspection, hash comparison and things...

Of course, I ended up finishing the update on the Air-Gapped only, and in this cloned machine there is no trace of anything related to the "kernel BUG at mm/memory.c" as my method dd overwrites the entire system partitions (the one showed, and the /boot).

Anybody can tell what this was?

The dd dump of the system partitions will be available for more analysis for a few weeks longer from now.

Regards,
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)

---
[1] the PAX_RAP from my kernel in this cloned machine:

Code: Select all: .config - Linux/x86 4.8.17-hardened-r2 Kernel Configuration → Security options → Grsecurity → Customize Configuration → PaX → Miscellaneous hardening features → Search (PAX_RAP) ┌────────────────────────────────────── Search Results ───────────────────────────────────────┐ │ Symbol: PAX_RAP [=y] │ │ Type : boolean │ │ Prompt: Prevent code reuse attacks │ │ Location: │ │ -> Security options │ │ -> Grsecurity │ │ -> Grsecurity (GRKERNSEC [=y]) │ │ -> Customize Configuration │ │ -> PaX │ │ (1) -> Miscellaneous hardening features │ │ Defined at security/Kconfig:1049 │ │ Depends on: GRKERNSEC [=y] && X86_64 [=y] && GCC_PLUGINS [=y] │ │ │ │ │

Code: Select all: │ CONFIG_PAX_RAP: │ │ │ │ By saying Y here the kernel will check indirect control transfers │ │ in order to detect and prevent attacks that try to hijack control │ │ flow by overwriting code pointers. │ │ │ │ If you have an amd64 processor that does not support SMEP then you │ │ must also enable a KERNEXEC code pointer instrumentation method │ │ (see PAX_KERNEXEC_PLUGIN). │ │ │ │ Note that binary modules cannot be instrumented by this approach. │ │ │ │ Note that the implementation requires a gcc with plugin support, │ │ i.e., gcc 4.5 or newer. You may need to install the supporting │ │ headers explicitly in addition to the normal gcc package. │ │ │ │ Symbol: PAX_RAP [=y] │ │ Type : boolean │ │ Prompt: Prevent code reuse attacks │ │ Location: │ │ -> Security options │ │ -> Grsecurity │ │ -> Grsecurity (GRKERNSEC [=y]) │ │ -> Customize Configuration │ │ -> PaX │ │ -> Miscellaneous hardening features │ │ Defined at security/Kconfig:1049 │ │ Depends on: GRKERNSEC [=y] && X86_64 [=y] && GCC_PLUGINS [=y] │ │ │ │ │ │ │

by **PaX Team** » Fri Jan 27, 2017 10:43 pm

this is a kernel BUG triggering in some memory management code, not a RAP violation per se (in the 4.9 patch i've fixed the reporting so there'll be no more confusion). can you reproduce this with a vanilla kernel?

by **timbgo** » Sat Jan 28, 2017 1:49 am

PaX Team wrote:this is a kernel BUG triggering in some memory management code, not a RAP violation per se (in the 4.9 patch i've fixed the reporting so there'll be no more confusion). can you reproduce this with a vanilla kernel?

Thanks for replying! I'll try. Give me some time (you know I'm slow and not very reliable, even though I try to be :-)

)

by **timbgo** » Sun Jan 29, 2017 9:40 am

( PaX Team, I'm not writing only for you, I also want newbies to understand. Pls. allow! )

I was thinking about how I should try and reproduce this, and it's not clear to me.

In the first place, if you look up the first post of mine: viewtopic.php?f=3&t=4653&p=16881#p16868 , however few people use this method, it is, from my experience, a very well working Air-Gapped cloning method, on (here at least) two distinct (but also possible to apply to only one machine, only much more work). Two distinct machines but of same model hardware (esp. motherboard).

One machine is the Air-Gapped, the other, this one, is the always temporary clone. and while on this one that I send and receive mail from, and in which I go online, the bug was somehow put to work, still, during exact same procedures (the Gentoo Portage's emerge command updating all the packages on both of the two distinct machined), still those same procedures/processes/jobs/tasks, none of them in no way triggered that same bug in the Air-Gapped machine...

This cloned machine that I'm writing this from and using which, when I finish writing it, I'll be posting this to:
< this topic that you're reading >
PAX: overwritten function pointer or return address, bans portage!
viewtopic.php?f=3&t=4653
, is now being updated, after I cloned it from clean Air-Gapped machine where the bug did not apear, but in which I was instead perfectly able to finish updating my system the Gentoo way. I had cloned it from my Air-Gapped master, because, as I wrote, my

cloned system, deploying the methods that I use, is fully recoverable

and that implies that I cloned it as a copy of the master equal to it in every single bit.

I had cloned it before I posted in that first post:
Thu Jan 26, 2017 11:23 pm

And I was wondering how do I try to reproduce this bug?

Maybe in this following way:

I have been updating my Air-Gapped since this morning. And it's nearing completion. The Air-Gapped will be up to date in about one more hour.

I thought, given that hardened-sources are still at 4.8 (so the reporting that you fixed is not in Gentoo's patched kernels yet), that I would try test-emerge'ing this system as well (or should I call it temporary emerging; namely it gets completely wiped out upon cloning from Air-Gapped).

And I'm doing it.

And this is the kernels available in updated portage in Gentoo, at this time.

Code: Select all: # ls -l /usr/portage/sys-kernel/hardened-sources/ total 376 -rw-r--r-- 1 portage portage 47449 2016-12-17 02:21 ChangeLog -rw-r--r-- 1 portage portage 112069 2015-11-09 04:28 ChangeLog-2011 -rw-r--r-- 1 portage portage 103203 2015-11-09 04:28 ChangeLog-2013 -rw-r--r-- 1 portage portage 81136 2015-11-09 05:11 ChangeLog-2015 -rw-r--r-- 1 portage portage 1273 2016-04-30 19:51 hardened-sources-4.4.8-r1.ebuild -rw-r--r-- 1 portage portage 1273 2016-10-26 10:18 hardened-sources-4.7.10.ebuild -rw-r--r-- 1 portage portage 1273 2016-10-18 03:09 hardened-sources-4.7.6.ebuild -rw-r--r-- 1 portage portage 1274 2017-01-28 21:27 hardened-sources-4.8.17-r2.ebuild -rw-r--r-- 1 portage portage 9949 2017-01-28 21:27 Manifest -rw-r--r-- 1 portage portage 774 2016-01-25 00:06 metadata.xml # ls -l /usr/portage/sys-kernel/vanilla-sources/ total 256 -rw-r--r-- 1 portage portage 48866 2016-12-18 21:57 ChangeLog -rw-r--r-- 1 portage portage 104895 2015-11-09 04:28 ChangeLog-2013 -rw-r--r-- 1 portage portage 43787 2015-11-09 05:11 ChangeLog-2015 -rw-r--r-- 1 portage portage 12914 2017-01-26 17:13 Manifest -rw-r--r-- 1 portage portage 642 2016-01-25 00:06 metadata.xml -rw-r--r-- 1 portage portage 433 2016-10-22 02:14 vanilla-sources-3.10.104.ebuild -rw-r--r-- 1 portage portage 433 2016-12-18 21:57 vanilla-sources-3.12.69.ebuild -rw-r--r-- 1 portage portage 433 2016-11-20 13:26 vanilla-sources-3.16.39.ebuild -rw-r--r-- 1 portage portage 433 2017-01-19 16:06 vanilla-sources-3.18.47.ebuild -rw-r--r-- 1 portage portage 433 2016-11-20 13:26 vanilla-sources-3.2.84.ebuild -rw-r--r-- 1 portage portage 433 2016-10-28 11:57 vanilla-sources-3.4.113.ebuild -rw-r--r-- 1 portage portage 433 2017-01-19 16:06 vanilla-sources-4.1.38.ebuild -rw-r--r-- 1 portage portage 433 2017-01-26 17:13 vanilla-sources-4.4.45.ebuild -rw-r--r-- 1 portage portage 433 2017-01-10 09:46 vanilla-sources-4.8.17.ebuild -rw-r--r-- 1 portage portage 433 2017-01-26 17:13 vanilla-sources-4.9.6.ebuild #

This is what currently shows if I issue the command:

# eselect kernel list

Code: Select all: Available kernel symlink targets: [1] linux-4.4.8-hardened-r1 [2] linux-4.8.17-hardened-r1 [3] linux-4.8.17-hardened-r2 * [4] linux-4.9.4 [5] linux-4.9.5

And when I update (of course: if I manage to update my whole system) there will be added the 4.9.6 kernel:

Code: Select all: [6] linux-4.9.6

( UPDATE: This has happened before my posting of this text. )

While preparing this text, I've updated 7 of 43 packages, but some are of longer compilation times...

( UPDATE: Some 30 packages installed before my posting of this text. )

Also, I wasn't much online since. So the bug might not be triggered... And the compilation might go smoothly as in the Air-Gapped, because the system is still pretty clean...

( Pretty clean... But if they have some of those thingies ready that fix --for them-- some of my firmware... it could still happen... In my long years of fighting for my complete control of my own systems I have seen even my hardware, such as of two distinct pieces of same model hardware, one fail strangely, and it was always the piece that was exposed to the internet, never the one in the quiet and calm Air-Gapped... )

And if the bug fails to show up, if you think it would make sense to try, I can resuscitate the system where the bug showed, it wil be to the bit exact same as when I reported the bug...

I can do that by dd'ing it onto these online system partitions from the images that I had taken of it back then, and boot into linux-4.9.5 vanilla kernel, and see if the bug shows up...

Lots of compilations here, Gentoo is really a rolling distribution, it changes very fast...

Only the hardened-sources have been slow to update to 4.9, and I don't know why. Really not blaming any of the developers that do the work in the hardened, far from!

What I know is the kernel is security-wise, still being laid ruin to, by its benevolent dictator, and there's little chance to get the kernel right with that leader deciding the way (you know, the one for whom all bugs are just normal bugs, security bugs no different than any other bugs). And newbies are being led to believe the NSA Linux is a good thing... Default for hardening in even Gentoo! Did I say NSA Linux? Oh, I meant SELinux, sorry!

Regards!

grsecurity forums

PAX: overwritten function pointer or return address, bans portage!

PAX: overwritten function pointer or return address, bans portage!

Re: PAX: overwritten function pointer or return address, bans portage!

Re: PAX: overwritten function pointer or return address, bans portage!

Re: PAX: overwritten function pointer or return address, bans portage!

Re: PAX: overwritten function pointer or return address, bans portage!