I noticed in my logs, that clamd is not running. Just before clamd probably died (no response later) without any messages, there I found this in the logs: Aug 10 12:48:45 atoth kernel: PAX: size overflow detected in function tcp_recvmsg net/ipv4/tcp.c:1696 Aug 10 12:48:45 atoth kernel: Pid: 27387, comm: clamd Not tainted 3.4.7-hardened #1 Aug 10 12:48:45 atoth kernel: Call Trace: Aug 10 12:48:45 atoth kernel: [<000d8dc9>] ? report_size_overflow+0x29/0x40 Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<006110a8>] ? tcp_recvmsg+0x388/0xbd0 Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<006325e9>] ? inet_recvmsg+0x89/0xb0 Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<005466c5>] ? sock_recvmsg+0xe5/0x120 Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00548e2f>] ? sys_recvfrom+0xdf/0x170 Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00548ef7>] ? sys_recv+0x37/0x40 Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<0054991c>] ? sys_socketcall+0x2fc/0x500 Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00002000>] ? 0x1fff Aug 10 12:48:45 atoth kernel: [<00808000>] ? evergreen_startup+0xb50/0x1100 [radeon] Aug 10 12:48:45 atoth kernel: [<0075f351>] ? syscall_call+0x7/0xb Aug 10 12:48:45 atoth kernel: [<00808000>] ? evergreen_startup+0xb50/0x1100 [radeon] Aug 10 12:48:45 atoth kernel: [<0075f371>] ? restore_all_pax+0xc/0xc I'm using an ATI Radeon R200 QL [Radeon 8500 LE]. No problems with the graphics. The network communication continued to be OK, no outage. I haven't even noticed the incident. (mmap BUG while doing a restart showed up again: I haven't seen that for ages, but it was around for some time in the past when I had to switch to conservative journaling to prevent data loss...) I'm also running squid with squidclamav, which nowdays uses c-icap. After clamd died, c-icap started throwing things like this upon every couple of minutes: Aug 10 12:48:48 atoth kernel: PAX: From <IP address>: execution attempt in: (null), 00000000-00000000 00000000 Aug 10 12:48:48 atoth kernel: PAX: terminating task: /usr/libexec/c-icap(c-icap):4172, uid/euid: 131/131, PC: 00000022, SP: 59bea450 Aug 10 12:48:48 atoth kernel: PAX: bytes at PC: ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Aug 10 12:48:48 atoth kernel: PAX: bytes at SP-4: 00000022 0000000e 59bea45c 59bea4dc 0000000e 00000000 00000080 00000000 00000000 00000000 00000000 4d135edd 59bea528 00000000 00000008 59bea518 4d13a165 00000000 14b07338 4d13060d 4d145fbc I guess I may also file a c-icap bug as well. Although c-icap recovered from the issue without any need for intervention, it shouldn't try to do null execution attempts upon failure of clamd it relies on. Reproducible: Always
Okay can you attach the following: 1) your config file 2) your bzImage 3) you vmlinux, top level of the /usr/src directory 4) you System.map 5) emerge --info Does this happen with gentoo-sources or vanilla-sources 3.4.7?
Created attachment 321142 [details] Config file
(In reply to comment #1) > Okay can you attach the following: > > 1) your config file > > 2) your bzImage > > 3) you vmlinux, top level of the /usr/src directory > > 4) you System.map > > 5) emerge --info > > Does this happen with gentoo-sources or vanilla-sources 3.4.7? For 2.), 3.) and 4.) please browse to http://atoth.sote.hu/~atoth/blueness, because the bug tracking system denied the attachments due to exceeding size limits. Also please let me know if those files are no longer needed in order to let me remove them. Please note, that there are previous reports of tcp_recvmsg size overflow on kernels 3.2.23-grsec and 3.4.4-grsec. http://forums.grsecurity.net/viewtopic.php?f=1&t=2991 http://forums.grsecurity.net/viewtopic.php?f=3&t=2992 Ephox told there he'll fix it in the next plugin version. It seems it's still not fixed in 3.4.7. Previously I was instructed to use a single place for error reporting, and this time I started with gentoo bugzilla. That's why I didn't posted the same issue on grsecurity.net. I cannot tell if it happens with vanilla or gentoo-sources because of two reasons. One reason is that I only boot grsecurity enabled kernels on the system in production. The other reason is, that the only symptom was that clamd died, but I cannot reproduce the error. Therefore I would see the error message about the problem happening without a PAX-less kernel. 5.) emerge --info: Portage 2.1.10.65 (hardened/linux/x86, gcc-4.6.3, glibc-2.15-r2, 3.4.7-hardened i686) ================================================================= System uname: Linux-3.4.7-hardened-i686-AMD_Athlon-TM-_MP_2600+-with-gentoo-2.1 Timestamp of tree: Wed, 08 Aug 2012 09:00:01 +0000 ccache version 3.1.7 [disabled] app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/ccache: 3.1.7 dev-util/cmake: 2.8.7-r5 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.10.5 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.6.3::<unknown repository>, 1.7.9-r2, 1.8.5-r3, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.22.90 sys-devel/gcc: 4.5.4, 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) sys-libs/glibc: 2.15-r2 Repositories: gentoo x-portage hardened-dev anarchy x-overlay ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -mtune=athlon-mp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/mozilla/defaults/pref /usr/share/gnupg/qualified.txt /var/bind /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=i686 -mtune=athlon-mp -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-march=i686 -O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles metadata-transfer news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch xattr" FFLAGS="-march=i686 -O2 -pipe" GENTOO_MIRRORS="http://gentoo.inf.elte.hu/ http://gentoo.inode.at/" LANG="hu_HU.utf8" LC_ALL="hu_HU.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="hu en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /var/lib/layman/hardened-development /var/lib/layman/anarchy /home/atoth/public_html/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="32bit 3dnow 3dnowext 7zip GNU R X X509 Xaw3d a52 aac aalib acl acpi action_modeswitch aiglx aio aisleriot alaw alsa amr aotuv apache2 apng applet archive ares asf atahpt atmo audio audiofile avcodec avformat bash-completion bazaar bcmath bdf berkdb bind binfilter bitbang_spi bitmap-fonts bittorrent blas bluetooth bonobo boost branding browserplugin bugzilla buspirate_spi bzip2 cairo calendar canvas caps cdaudio cdda cddax cddb cdio cdparanoia cdr cdrom celt cgi chardet charmap checkpath cheese clamdtop cli client clutter color colord consolekit contentcache context contrib corefonts coverage cracklib cramfs crashreporter crypt css ctype cue cups curl curlwrappers cvs cxx dba dbm dbus dcmtk ddate dediprog deskbar detex devhelp device-mapper dga dhcp dia dicom dirac disassembler discard-path divx divx4linux djbfft djvu dlloader dmi dnsrbl doc-pdf dot dri drkaiser dselect dtmf dts dv dvbpsi dvd dvdnav dvdr dvdread dvi dvi2tty dvipdfm eap-sim ecap edd eds elf emerald enca enchant encode enscript epiphany epoll epspdf equalizer evo exif expat extensions extra extrafilters extras faac faad fallback fam fame fat fax fbosd ffmpeg fftw fileinfo filter-aaaa finger firefox firefox-bookmarks flac flash flatfile flickr floppy fltk follow-xff fontconfig fontforge foomaticdb force-cgi-redirect fortran fpx ftdi ftp g3dvl g722 g729 gadu gajim galago gallium gbm gconf gd gdb gdbm gdl gdu gedit geoip geoloc gftp gif gimp gimpprint ginac git glade glchess gles glibc gme gmedia gmp gnet gnome gnome-keyring gnome-screensaver gnumeric gold gopher gpac gpg gphoto2 gpm graphics graphicsmagick graphviz groupwise gs gsf gsl gsm gstreamer gtalk gtk gtk2 gtk3 gtkhtml gudev guile h224 h281 h323 hardened hash hdf5 hpcups hpijs html http hub hwdb icap-client iconv icu id3 id3tag idle idn iksemel ilbc imagemagick imap imlib inherit-graph inifile inkjar inode internal intl introspection ipc iplayer iplsrc iptc ipv6 irc irda ivr jabber jadetex java java-internal java6 javascript jemalloc jingle jpeg jpeg2k jpgraph jrtplib json kate kdrive keymap kpathsea ladspa lame lapack latex latex3 lcms ldb libass libburn libcaca libffi libgda libkms libnl libnotify libplot libsamplerate libssh2 libtar libv4l2 libvisual lightning llvm lm_sensors lock logging logitech-mouse loop-aes lua lxde lyx lzma lzo lzw m17n-lib mad map math matroska mbox mcal mclib md5sum mdev meanwhile memlimit mercurial mhash midi mikmod milter ming mjpeg mktemp mmap mmx mmxext mng mod mode-owner modemmanager modules motif mozbranding mozcalendar mp2 mp3 mp4 mpeg mpeg1 mpeg2 mplayer mudflap multinetwork musepack mysql mysqli nautilus ncurses nemesi netlink network networking networkmanager new-login nic3com nicintel nicintel_spi nicnatsemi nicrealtek nifti nlpsolver nls nntp nokia nopop3d nptl nsplugin nss ntfs numpy nut nuv oav ocr odbc odk ofx ogg oggvorbis ogm ogp_spi oidentd oil onaccess opencore-amr openct opendbx openexr opengl openmp openssl openvg optimisememory otr overload pam pam_chroot pam_ssh pam_timestamp pango passwd passwdqc paste64 pasteafter pax_kernel pccts pcmcia pcntl pcre pcsc-lite pda pdf pdfannotextractor pdfimport pdo pear perl phar php pic pidgin playlist plotutils plugin-autowep plugin-btscan plugin-dot15d4 plugin-ptw plugin-spectools plugins png pnm policykit pony_spi posix postproc postscript ppds pppd prefixaq prevent-removal projectm pstricks publishers pvr python python2 qhull qt3support quicktime quota quotas rar rc5 rcs readline realmedia reflection reiserfs remoteosd replytolist rle rss rtc rtf ruby18 ruby19 rule_generator samba sasl satamv satasii sbc scanner scenarios schroedinger science scp screen scripting sdl sdl-sound sdlgfx secure-delete seed sendmail sendto sensord serprog session sftplogging shared-dricore shared-glapi shm short-touchpad-timeout showlistmodes showtabbar sid sidebar sieve silc sip sipim skins slang smbsharemodes smime smp sms smtp sndfile soap socialweb sockets sound soundex soundtouch sourceview sox sparse speex spell spoof sqlite3 srt srtp sse sse2check ssh ssl ssp sspall startup-notification stats stun subtitles subversion sudoku suhosin svg svnserve swat switcher swscale syslog system-sqlite systray sysvipc t1lib taglib tagwriting tcl tcltk tcpd templates terminal tetex tex4ht tga themes theora thin threads threadsafe thunar thunderbird tidy tiff tilepath timidity tk tlen tokenizer toolbar tools topicisnuhost totem tracker transcode trayicon truetype truetype-fonts twolame type1-fonts type3 udev udis86 udisks ulaw underscores unicode unlock-notify usb userlocales usermod utils v4l v4l2 vala valgrind vcd vcdinfo vcdx video virus-scan vista visualization vlc vlm volpack vorbis vtk vxml wav wavplay webgl webkit webm webp webrtc-aec wifi wiki wildcards wimax win32codecs winscp wma wmf wmp wps wxwidgets wxwindows x264 x86 xattr xcap xcb xchatdccserver xetex xforms xine xmedcon xml xml2 xmlreader xmlrpc xmlwriter xmp xnest xorg xpm xps xscreensaver xsl xulrunner xv xvfb xvid xvmc yahoo zeitgeist zip zlib zvbi" ALSA_CARDS="cmipci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias auth_digest version filter ident charset_lite asis dbd authn_dbd proxy proxy_ajp proxy_balancer proxy_connect proxy_http imagemap cgid substitute" APACHE2_MPMS="worker" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CURL_SSL="nss" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="keyboard mouse acecad evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="hu en" PHP_TARGETS="php5-3 php5-4" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="epson epson2 gt68xx ma1509 mustek mustek_usb mustek_usb2 plustek snapscan umax" USERLAND="GNU" VIDEO_CARDS="radeon v4l modesetting r200" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Hi, 3.4.7 contains the old plugin version, I released a new version yesterday, you can find it in the latest grsec versions (20120811 or 20120812).
(In reply to comment #4) > Hi, 3.4.7 contains the old plugin version, I released a new version > yesterday, you can find it in the latest grsec versions (20120811 or > 20120812). Thx Emese! I'm sorry for my mistake, that I wrote "he". I usually cycle kernels each week. Next week I'm sure it'll be a kernel with the new plugin version.
The latest patchset are in the tree with: hardened-sources-3.5.1-r1 = vanilla-3.5.1 + genpatches-3.5-1 + grsecurity-2.9.1-3.5.1-201208112021 hardened-sources-3.2.27 = vanilla-3.2.27 + genpatches-3.2-16 + grsecurity-2.9.1-3.2.27-201208120907 hardened-sources-2.6.32-r121 = vanilla-2.6.32.59 + genpatches-2.6.32-48 + grsecurity-2.9.1-2.6.32.59-201208120916
Here I got another one today using hardened-sources-3.5.1-r2: PAX: size overflow detected in function tcp_recvmsg net/ipv4/tcp.c:1808 Pid: 4990, comm: squid Not tainted 3.5.1-hardened-r2 #1 Call Trace: [<000ddb99>] ? report_size_overflow+0x29/0x40 [<0062f3e9>] ? tcp_recvmsg+0xb99/0xc90 [<00002296>] ? lru_deactivate_pvecs+0x16/0x40 [<00003ffe>] ? do_overflow+0x3e/0x70 [<00003ffe>] ? do_overflow+0x3e/0x70 [<00650479>] ? inet_recvmsg+0x89/0xb0 [<00003ffe>] ? do_overflow+0x3e/0x70 [<00003ffe>] ? do_overflow+0x3e/0x70 [<00560012>] ? sock_aio_read+0x112/0x130 [<00003ffe>] ? do_overflow+0x3e/0x70 [<00003ffe>] ? do_overflow+0x3e/0x70 [<00003ffe>] ? do_overflow+0x3e/0x70 [<000d853e>] ? do_sync_read+0xce/0x110 [<00003ffe>] ? do_overflow+0x3e/0x70 [<002322b0>] ? security_file_permission+0x90/0xb0 [<00003ffe>] ? do_overflow+0x3e/0x70 [<00003ffe>] ? do_overflow+0x3e/0x70 [<000d8c22>] ? rw_verify_area+0x72/0x130 [<00003ffe>] ? do_overflow+0x3e/0x70 [<00003ffe>] ? do_overflow+0x3e/0x70 [<000d91ad>] ? vfs_read+0x13d/0x190 [<000d923c>] ? sys_read+0x3c/0x70 [<0077ec91>] ? syscall_call+0x7/0xb [<00003ffe>] ? do_overflow+0x3e/0x70 This time it killed squid. I did some normal network activity using the proxy (downloading UBCD...). I think the issue isn't fixed by 3.5.1-r2. Although I see, that 3.5.2 is already in the tree, so I'll give it a spin when I have time.
The current 3.5.2 contains the same plugin version as 3.5.1. Could you try to reproduce the bug with the latest grsec (20120820)?
(In reply to comment #8) > The current 3.5.2 contains the same plugin version as 3.5.1. Could you try > to reproduce the bug with the latest grsec (20120820)? I cannot reliably reproduce the bug. It takes days to observe an occurrence. All I can do is to compile a kernel with the suggested version of the patch, sit and stare. I'm on holiday, so I'll have some time for an out-of-order kernel upgrade.
I think I'm hitting the same bug:- Aug 21 15:42:53 dangentoo kernel: [626897.154706] PAX: size overflow detected in function tcp_recvmsg net/ipv4/tcp.c:1696 Aug 21 15:42:53 dangentoo kernel: [626897.154710] Pid: 22172, comm: ssh Not tainted 3.4.5-hardened #3 Aug 21 15:42:53 dangentoo kernel: [626897.154713] Call Trace: Aug 21 15:42:53 dangentoo kernel: [626897.154720] [<ffffffff810c1048>] ? report_size_overflow+0x29/0x33 Aug 21 15:42:53 dangentoo kernel: [626897.154725] [<ffffffff812d29b9>] ? tcp_recvmsg+0x663/0x974 Aug 21 15:42:53 dangentoo kernel: [626897.154730] [<ffffffff812ed7ba>] ? inet_recvmsg+0x5f/0x73 Aug 21 15:42:53 dangentoo kernel: [626897.154734] [<ffffffff8128a9ae>] ? __sock_recvmsg+0x3f/0x90 Aug 21 15:42:53 dangentoo kernel: [626897.154738] [<ffffffff8128aac6>] ? sock_aio_read+0xc7/0xdb Aug 21 15:42:53 dangentoo kernel: [626897.154742] [<ffffffff810bc405>] ? do_sync_read+0xc6/0xff Aug 21 15:42:53 dangentoo kernel: [626897.154747] [<ffffffff810bcca1>] ? vfs_read+0x10c/0x16f Aug 21 15:42:53 dangentoo kernel: [626897.154750] [<ffffffff810bcd4f>] ? sys_read+0x4b/0x71 Aug 21 15:42:53 dangentoo kernel: [626897.154755] [<ffffffff813133d9>] ? system_call_fastpath+0x18/0x1d I think I can reliably reproduce this by copying a large file with rsync over ssh. I'm happy to recompile my kernel with a new version of grsec if you let me know what ebuild to use or how to update this plugin in my sources :)
(In reply to comment #10) > I'm happy to recompile my kernel with a new version of grsec if you let me > know what ebuild to use or how to update this plugin in my sources :) Hi :) You can find here the latest grsec (for kernel version 3.5.2): http://grsecurity.net/~spender/grsecurity-2.9.1-3.5.2-201208222031.patch
(In reply to comment #11) > (In reply to comment #10) > > I'm happy to recompile my kernel with a new version of grsec if you let me > > know what ebuild to use or how to update this plugin in my sources :) > > Hi :) You can find here the latest grsec (for kernel version 3.5.2): > http://grsecurity.net/~spender/grsecurity-2.9.1-3.5.2-201208222031.patch Can you try the latest hardened-sources which I just added to the tree: hardened-sources-3.5.2-r3
I've compiled with this new ebuild and will test a few rsync's over the next few days and I'll let you know how I get on :)
(In reply to comment #11) > (In reply to comment #10) > > I'm happy to recompile my kernel with a new version of grsec if you let me > > know what ebuild to use or how to update this plugin in my sources :) > > Hi :) You can find here the latest grsec (for kernel version 3.5.2): > http://grsecurity.net/~spender/grsecurity-2.9.1-3.5.2-201208222031.patch I've patched hardened-sources-3.5.2 with an incremental patch to bump grsecurity to 201208222031 a couple of days ago - as it was requested. I'm running this kernel for days without a tcp_recvmsg overflow event. However I don't have a reliable method to reproduce the bug: previously various daemons triggered it. So I hope Dan Weeks can explicitly confirm, that the issue has been solved with the latest kernels using rsync. Thanks: Dwokfur
Confirmed on hardened-sources-3.4.5 on multiple x86_64 machines, with different daemons. Takes not too big a workload to happen. The most recent example: PAX: size overflow detected in function tcp_recvmsg net/ipv4/tcp.c:1696 Pid: 12762, comm: ssh Not tainted 3.4.5-hardened #1 Call Trace: [<ffffffff810a9175>] ? report_size_overflow+0x29/0x33 [<ffffffff813460de>] ? tcp_recvmsg+0xac6/0xe9f [<ffffffff8136249e>] ? inet_recvmsg+0x8a/0xa0 [<ffffffff813030e1>] ? sock_aio_read+0x10f/0x127 [<ffffffff810a1c36>] ? do_sync_read+0xcc/0x109 [<ffffffff810a245f>] ? vfs_read+0x12e/0x1de [<ffffffff810a281e>] ? sys_read+0x4b/0x78 [<ffffffff813b2428>] ? system_call_fastpath+0x18/0x1d Also look here: https://bugs.gentoo.org/show_bug.cgi?id=433000 Maybe we could push out and stable 3.4.5-r1 over the current stable 3.4.5, if upstream has a fix?
(In reply to comment #15) > Maybe we could push out and stable 3.4.5-r1 over the current stable 3.4.5, > if upstream has a fix? we've fixed it already but not for 3.4 which we no longer support.
> we've fixed it already but not for 3.4 which we no longer support. Which kernel versions exactly have this fix? Is only 3.5.* fixed or also 3.2.* kernels?
(In reply to comment #16) > we've fixed it already but not for 3.4 which we no longer support. ..mask it maybe?
No Go with 3.5.2-r3 just got this in my logs this morning. Aug 28 10:14:31 dangentoo kernel: [ 4995.192359] PAX: size overflow detected in function tcp_recvmsg net/ipv4/tcp.c:1756 cicus.538_439 (max) Aug 28 10:14:31 dangentoo kernel: [ 4995.192365] Pid: 3652, comm: ssh Not tainted 3.5.2-hardened-r3 #1 Aug 28 10:14:31 dangentoo kernel: [ 4995.192367] Call Trace: Aug 28 10:14:31 dangentoo kernel: [ 4995.192378] [<ffffffff810c46c9>] ? report_size_overflow+0x37/0x41 Aug 28 10:14:31 dangentoo kernel: [ 4995.192384] [<ffffffff812dc39a>] ? tcp_recvmsg+0x499/0xb68 Aug 28 10:14:31 dangentoo kernel: [ 4995.192388] [<ffffffff812f7aee>] ? inet_recvmsg+0x5f/0x73 Aug 28 10:14:31 dangentoo kernel: [ 4995.192392] [<ffffffff81292b9b>] ? __sock_recvmsg+0x3f/0x90 Aug 28 10:14:31 dangentoo kernel: [ 4995.192395] [<ffffffff81292cb3>] ? sock_aio_read+0xc7/0xdb Aug 28 10:14:31 dangentoo kernel: [ 4995.192399] [<ffffffff810bfc0d>] ? do_sync_read+0xc6/0xff Aug 28 10:14:31 dangentoo kernel: [ 4995.192405] [<ffffffff8116dab2>] ? file_has_perm+0x6d/0x78 Aug 28 10:14:31 dangentoo kernel: [ 4995.192408] [<ffffffff810c0493>] ? vfs_read+0x10c/0x16f Aug 28 10:14:31 dangentoo kernel: [ 4995.192411] [<ffffffff810c0541>] ? sys_read+0x4b/0x71 Aug 28 10:14:31 dangentoo kernel: [ 4995.192416] [<ffffffff8131d9d9>] ? system_call_fastpath+0x18/0x1d Aug 28 10:14:31 dangentoo kernel: [ 4995.192420] [<ffffffff8131da00>] ? sysret_check+0x1d/0x58
*** Bug 433000 has been marked as a duplicate of this bug. ***
I have detect_hung_tasks compiled into my kernel, I don't know if this output is useful: Aug 28 10:17:16 dangentoo kernel: [ 5160.156062] INFO: task ssh:3652 blocked for more than 120 seconds. Aug 28 10:17:16 dangentoo kernel: [ 5160.156065] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Aug 28 10:17:16 dangentoo kernel: [ 5160.156067] ssh D ffff8800c92beae0 0 3652 3651 0x00000080 Aug 28 10:17:16 dangentoo kernel: [ 5160.156072] ffff8800c92beae0 0000000000000046 0000000000000000 ffff880116a8aac0 Aug 28 10:17:16 dangentoo kernel: [ 5160.156076] 000000000000dc00 ffff8800c92bef00 ffff8800c92bef00 000000000000dc00 Aug 28 10:17:16 dangentoo kernel: [ 5160.156080] ffff8800c92beae0 000000000000dc00 000000000000dc00 000000000000dc00 Aug 28 10:17:16 dangentoo kernel: [ 5160.156084] Call Trace: Aug 28 10:17:16 dangentoo kernel: [ 5160.156093] [<ffffffff81297427>] ? __lock_sock+0x64/0x88 Aug 28 10:17:16 dangentoo kernel: [ 5160.156097] [<ffffffff810443bd>] ? wake_up_bit+0x28/0x28 Aug 28 10:17:16 dangentoo kernel: [ 5160.156101] [<ffffffff8104b709>] ? need_resched+0x17/0x24 Aug 28 10:17:16 dangentoo kernel: [ 5160.156104] [<ffffffff812974a1>] ? lock_sock_nested+0x20/0x31 Aug 28 10:17:16 dangentoo kernel: [ 5160.156108] [<ffffffff812dcf04>] ? tcp_close+0x18/0x306 Aug 28 10:17:16 dangentoo kernel: [ 5160.156111] [<ffffffff812f9001>] ? inet_release+0x73/0x7c Aug 28 10:17:16 dangentoo kernel: [ 5160.156114] [<ffffffff8129370b>] ? sock_release+0x1c/0x7a Aug 28 10:17:16 dangentoo kernel: [ 5160.156117] [<ffffffff8129378b>] ? sock_close+0x22/0x26 Aug 28 10:17:16 dangentoo kernel: [ 5160.156121] [<ffffffff810c15c4>] ? fput+0xfa/0x1e1 Aug 28 10:17:16 dangentoo kernel: [ 5160.156126] [<ffffffff810be3b6>] ? filp_close+0x5d/0x65 Aug 28 10:17:16 dangentoo kernel: [ 5160.156130] [<ffffffff8102e627>] ? put_files_struct+0x65/0xc3 Aug 28 10:17:16 dangentoo kernel: [ 5160.156133] [<ffffffff8102e984>] ? do_exit+0x27a/0x792 Aug 28 10:17:16 dangentoo kernel: [ 5160.156136] [<ffffffff8102f173>] ? do_group_exit+0x76/0xa0 Aug 28 10:17:16 dangentoo kernel: [ 5160.156140] [<ffffffff810c46d3>] ? report_size_overflow+0x41/0x41 Aug 28 10:17:16 dangentoo kernel: [ 5160.156143] [<ffffffff812dc39a>] ? tcp_recvmsg+0x499/0xb68 Aug 28 10:17:16 dangentoo kernel: [ 5160.156146] [<ffffffff812f7aee>] ? inet_recvmsg+0x5f/0x73 Aug 28 10:17:16 dangentoo kernel: [ 5160.156149] [<ffffffff81292b9b>] ? __sock_recvmsg+0x3f/0x90 Aug 28 10:17:16 dangentoo kernel: [ 5160.156152] [<ffffffff81292cb3>] ? sock_aio_read+0xc7/0xdb Aug 28 10:17:16 dangentoo kernel: [ 5160.156155] [<ffffffff810bfc0d>] ? do_sync_read+0xc6/0xff Aug 28 10:17:16 dangentoo kernel: [ 5160.156160] [<ffffffff8116dab2>] ? file_has_perm+0x6d/0x78 Aug 28 10:17:16 dangentoo kernel: [ 5160.156163] [<ffffffff810c0493>] ? vfs_read+0x10c/0x16f Aug 28 10:17:16 dangentoo kernel: [ 5160.156166] [<ffffffff810c0541>] ? sys_read+0x4b/0x71 Aug 28 10:17:16 dangentoo kernel: [ 5160.156169] [<ffffffff8131d9d9>] ? system_call_fastpath+0x18/0x1d Aug 28 10:17:16 dangentoo kernel: [ 5160.156173] [<ffffffff8131da00>] ? sysret_check+0x1d/0x58 Let me know if there is anything else you want me to try :)
(In reply to comment #17) > > we've fixed it already but not for 3.4 which we no longer support. > > Which kernel versions exactly have this fix? Is only 3.5.* fixed or also > 3.2.* kernels? we fix all series we maintain (at the moment 2.6.32/3.2/3.5) but i don't know how gentoo tracks them, i think 3.5 is usually updated within a day or so but the others may not be.
(In reply to comment #22) > (In reply to comment #17) > > > we've fixed it already but not for 3.4 which we no longer support. > > > > Which kernel versions exactly have this fix? Is only 3.5.* fixed or also > > 3.2.* kernels? > > we fix all series we maintain (at the moment 2.6.32/3.2/3.5) but i don't > know how gentoo tracks them, i think 3.5 is usually updated within a day or > so but the others may not be. The entire set is updated within a few days. The stabilization lags about one month. It looks like I will be stabilized a 3.5 soon and dropping all 3.4's from the tree.
(In reply to comment #19) > No Go with 3.5.2-r3 just got this in my logs this morning. > > Aug 28 10:14:31 dangentoo kernel: [ 4995.192359] PAX: size overflow detected > in function tcp_recvmsg net/ipv4/tcp.c:1756 cicus.538_439 (max) > Aug 28 10:14:31 dangentoo kernel: [ 4995.192365] Pid: 3652, comm: ssh Not > tainted 3.5.2-hardened-r3 #1 Hi, could you send (or attach) your kernel config and vmlinux to me, please? Which gcc version do you use?
Created attachment 322509 [details] Dan kernel config
I've sent Emese my kernel because its too large to attach. My gcc version is:- gcc (Gentoo Hardened 4.5.4 p1.0, pie-0.4.7) 4.5.4
(In reply to comment #19) > Aug 28 10:14:31 dangentoo kernel: [ 4995.192359] PAX: size overflow detected > in function tcp_recvmsg net/ipv4/tcp.c:1756 cicus.538_439 (max) This bug will be fixed in the next PaX version.
*** Bug 433001 has been marked as a duplicate of this bug. ***
(In reply to comment #27) > This bug will be fixed in the next PaX version. this has been out for a few days now, can you guys check if you can still reproduce the problem?
(In reply to comment #29) > (In reply to comment #27) > > This bug will be fixed in the next PaX version. > > this has been out for a few days now, can you guys check if you can still > reproduce the problem? I just committed the latest patchset. Please test. hardened-sources-3.5.4 ~ grsecurity-2.9.1-3.5.4-201209171824 hardened-sources-3.2.29 ~ grsecurity-2.9.1-3.2.29-201209171824 hardened-sources-2.6.32-59-r129 ~ grsecurity-2.9.1-2.6.32.59-201209171823
3.2.29 is fine here
I'm hoping to be able to provide feedback for 3.5.4 tomorrow
I cannot reproduce this bug with 3.5.4 :)
Okay looks good to me too. Closing. Reopen if this bug pops up again.
(In reply to comment #34) > Okay looks good to me too. Closing. Reopen if this bug pops up again. Since the bug is present in our stable version, I'd say to stabilize the fixed version.
(In reply to comment #35) > (In reply to comment #34) > > Okay looks good to me too. Closing. Reopen if this bug pops up again. > > Since the bug is present in our stable version, I'd say to stabilize the > fixed version. ago, yes i know. but i'm sure this kernel contains as many fixes as it contains new bugs. the new bugs are unknown, and potentially bad. time will tell if the tradeoff is worth it as people use and test this latest version. in the mean time, turn off CONFIG_PAX_SIZE_OVERFLOW.
(In reply to comment #36) > ago, yes i know. but i'm sure this kernel contains as many fixes as it > contains new bugs. the new bugs are unknown, and potentially bad. time will > tell if the tradeoff is worth it as people use and test this latest version. out of curiosity, what's the normal roadmap for stabilization? just asking it because as far as i see, by the time you'll decide to stabilize 3.5, we may very well have stopped supporting it altogether since 3.6 will be out soon. at this rate it sounds like there'll never be enough time to stabilize the latest kernel ;).
(In reply to comment #37) > out of curiosity, what's the normal roadmap for stabilization? just asking > it because as far as i see, by the time you'll decide to stabilize 3.5, we > may very well have stopped supporting it altogether since 3.6 will be out > soon. at this rate it sounds like there'll never be enough time to stabilize > the latest kernel ;). Usually the package should be in tree for at least 30days with no regression. This is not the rule of the security bugs and there could be exception like when there is a bugfix version and we strictly need of that version immediately. For the kernel(gentoo-sources) I didn't see the rule of the 30days.
(In reply to comment #37) > (In reply to comment #36) > > ago, yes i know. but i'm sure this kernel contains as many fixes as it > > contains new bugs. the new bugs are unknown, and potentially bad. time will > > tell if the tradeoff is worth it as people use and test this latest version. > > out of curiosity, what's the normal roadmap for stabilization? just asking > it because as far as i see, by the time you'll decide to stabilize 3.5, we > may very well have stopped supporting it altogether since 3.6 will be out > soon. at this rate it sounds like there'll never be enough time to stabilize > the latest kernel ;). There are problems with following our usual 30 day roadmap when it comes to hardened-sources 1) with normal packages, there's usually a few configure options and so we think in terms of the package as either having a bug or not. with the kernel, the configuration space (and hardware space) is huge and there are always problems to be found somewhere. if its a corner case, or there's a workaround, i try to stick to the 30 day rule. if it is urgent, then i stabilize more quickly. 2) the rate at which you and brad push out patches is much faster than our stabilization. i always try to push out the latest, wait to see what bugs come up, and then decide which is a good candidate for the next stabilization. at any given time, there are at least two older versions marked stable and a bunch of newer version marked testing. anyone who really needs the latest can just locally mark it as stable and use it. this seems to me to be the best compromise. take a look at the following for which hardened-sources are marked stable and which are marked testing: http://packages.gentoo.org/package/sys-kernel/hardened-sources since our numbering scheme and yours is different, take a look at the changelog for the mapping between our versions and brad's http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-kernel/hardened-sources/ChangeLog?view=log
This should have been closed long ago.
