Re: Buffer overflow detected by REDZONE with linuxulator
Quoting Alexander Best (from Wed, 09 Sep 2009 19:01:31 +0200 (CEST)): hi there, CCing emulation@, this is better suited there. Full quote for the benefit of the emulation@ readers. Please drop hackers@ on reply. Thanks. i've installed emulators/linux_dist-gentoo-stage3 and grabbed a snapshot from the ltp git repository (http://ltp.sourceforge.net/). as expected some tests failed because i'm using compat.linux.osrelease: 2.6.16 which is still missing a few linux syscalls, ipcs and ioctls. Are you interested to help update the corresponding FreeBSD wiki page? If yes, register there and we can hand out write access. however i also noticed REDZONE reporting buffer overflows. i'm only a user and not a developer so i don't know if the ltp is to be blamed or if the problem lies within the linuxulator. Probably the later... i'm running 9.0-CURRENT (r196879). as i mentioned before i'm using 2.6 linux kernel emulation. here are the buffer overflow reports: Is your system running in 32bit or 64bit mode? Do you know which ltp-tests cause those messages to appear? Bye, Alexander. Sep 9 14:12:42 otaku kernel: REDZONE: Buffer overflow detected. 9 bytes corrupted after 0xcc28c483 (3 bytes allocated). Sep 9 14:12:42 otaku kernel: Allocation backtrace: Sep 9 14:12:42 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a Sep 9 14:12:42 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 Sep 9 14:12:42 otaku kernel: #2 0xc07428b8 at linux_getsockaddr+0x48 Sep 9 14:12:42 otaku kernel: #3 0xc0742eb8 at linux_socketcall+0x178 Sep 9 14:12:42 otaku kernel: #4 0xc0772f56 at syscall+0x2a6 Sep 9 14:12:42 otaku kernel: #5 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:12:42 otaku kernel: Free backtrace: Sep 9 14:12:42 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a Sep 9 14:12:42 otaku kernel: #1 0xc05bc32d at free+0x5d Sep 9 14:12:42 otaku kernel: #2 0xc0742ef0 at linux_socketcall+0x1b0 Sep 9 14:12:42 otaku kernel: #3 0xc0772f56 at syscall+0x2a6 Sep 9 14:12:42 otaku kernel: #4 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:20:08 otaku kernel: REDZONE: Buffer overflow detected. 4 bytes corrupted after 0xcc2538ea (106 bytes allocated). Sep 9 14:20:08 otaku kernel: Allocation backtrace: Sep 9 14:20:08 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a Sep 9 14:20:08 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 Sep 9 14:20:08 otaku kernel: #2 0xc063a902 at unp_connect+0x162 Sep 9 14:20:08 otaku kernel: #3 0xc063d6c9 at uipc_connect+0x49 Sep 9 14:20:08 otaku kernel: #4 0xc062fde2 at soconnect+0x52 Sep 9 14:20:08 otaku kernel: #5 0xc0638eb6 at kern_connect+0x96 Sep 9 14:20:08 otaku kernel: #6 0xc0742c7b at linux_connect+0x3b Sep 9 14:20:08 otaku kernel: #7 0xc0742f22 at linux_socketcall+0x1e2 Sep 9 14:20:08 otaku kernel: #8 0xc0772f56 at syscall+0x2a6 Sep 9 14:20:08 otaku kernel: #9 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:20:08 otaku kernel: Free backtrace: Sep 9 14:20:08 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a Sep 9 14:20:08 otaku kernel: #1 0xc05bc32d at free+0x5d Sep 9 14:20:08 otaku kernel: #2 0xc063bfb2 at uipc_detach+0x242 Sep 9 14:20:08 otaku kernel: #3 0xc0632a7e at sofree+0x22e Sep 9 14:20:08 otaku kernel: #4 0xc0632f26 at soclose+0x386 Sep 9 14:20:08 otaku kernel: #5 0xc0617c49 at soo_close+0x29 Sep 9 14:20:08 otaku kernel: #6 0xc0598b13 at _fdrop+0x43 Sep 9 14:20:08 otaku kernel: #7 0xc059ab90 at closef+0x290 Sep 9 14:20:08 otaku kernel: #8 0xc059af22 at kern_close+0x102 Sep 9 14:20:08 otaku kernel: #9 0xc059b09a at close+0x1a Sep 9 14:20:08 otaku kernel: #10 0xc0772f56 at syscall+0x2a6 Sep 9 14:20:08 otaku kernel: #11 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:20:09 otaku kernel: REDZONE: Buffer overflow detected. 4 bytes corrupted after 0xccc653ea (106 bytes allocated). Sep 9 14:20:09 otaku kernel: Allocation backtrace: Sep 9 14:20:09 otaku kernel: #0 0xc0709aaa at redzone_setup+0x3a Sep 9 14:20:09 otaku kernel: #1 0xc05bc673 at malloc+0x1c3 Sep 9 14:20:09 otaku kernel: #2 0xc063a902 at unp_connect+0x162 Sep 9 14:20:09 otaku kernel: #3 0xc063d6c9 at uipc_connect+0x49 Sep 9 14:20:09 otaku kernel: #4 0xc062fde2 at soconnect+0x52 Sep 9 14:20:09 otaku kernel: #5 0xc0638eb6 at kern_connect+0x96 Sep 9 14:20:09 otaku kernel: #6 0xc0742c7b at linux_connect+0x3b Sep 9 14:20:09 otaku kernel: #7 0xc0742f22 at linux_socketcall+0x1e2 Sep 9 14:20:09 otaku kernel: #8 0xc0772f56 at syscall+0x2a6 Sep 9 14:20:09 otaku kernel: #9 0xc07568b0 at Xint0x80_syscall+0x20 Sep 9 14:20:09 otaku kernel: Free backtrace: Sep 9 14:20:09 otaku kernel: #0 0xc0709a3a at redzone_check+0x17a Sep 9 14:20:09 otaku kernel: #1 0xc05bc32d at free+0x5d Sep 9 14:20:09 otaku kernel: #2 0xc063bfb2 at uipc_detach+0x242 Sep 9 14:20:09 otaku kernel: #3 0xc0632a7e at sofree+0x22e Sep 9 14:20:09 otaku kernel: #4 0xc0632f26 at soclose+0x386 Sep 9 14:20:09 otaku kernel: #5 0xc0617c49 at soo_close+0x29 Sep 9 14:20:09 otaku kernel: #6 0xc0598b13 at _fdrop+0x43 Sep 9 14:20:09 otaku
7.1 panicked removing namecache entry from cache
Hi, Today we had vfs related panic on 7.1-RELEASE-p5. Does anybody have any idea? Might it have already been fixed in later versions? Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07fd34b stack pointer = 0x28:0xe6a97bc8 frame pointer = 0x28:0xe6a97bdc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 49 (vnlru) trap number = 12 panic: page fault cpuid = 2 Uptime: 11h19m41s Physical memory: 3059 MB Dumping 275 MB: 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc07910a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0791379 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0aa7bcc in trap_fatal (frame=0xe6a97b88, eva=0) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0aa7e50 in trap_pfault (frame=0xe6a97b88, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0aa880c in trap (frame=0xe6a97b88) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0a8e67b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc07fd34b in cache_zap (ncp=0xcc33783c) at /usr/src/sys/kern/vfs_cache.c:276 #8 0xc07fd57c in cache_purge (vp=0xc890533c) at /usr/src/sys/kern/vfs_cache.c:613 #9 0xc080df18 in vgonel (vp=0xc890533c) at /usr/src/sys/kern/vfs_subr.c:2545 #10 0xc081174d in vnlru_free (count=270) at /usr/src/sys/kern/vfs_subr.c:870 #11 0xc0811ddc in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:733 #12 0xc076cc19 in fork_exit (callout=0xc0811cf0 , arg=0x0, frame=0xe6a97d38) at /usr/src/sys/kern/kern_fork.c:804 #13 0xc0a8e6f0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 267 static void 268 cache_zap(ncp) 269 struct namecache *ncp; 270 { 271 struct vnode *vp; 272 273 mtx_assert(&cache_lock, MA_OWNED); 274 CTR2(KTR_VFS, "cache_zap(%p) vp %p", ncp, ncp->nc_vp); 275 vp = NULL; 276 LIST_REMOVE(ncp, nc_hash); 277 LIST_REMOVE(ncp, nc_src); 278 if (LIST_EMPTY(&ncp->nc_dvp->v_cache_src)) { 279 vp = ncp->nc_dvp; 280 numcachehv--; 281 } 282 if (ncp->nc_vp) { 283 TAILQ_REMOVE(&ncp->nc_vp->v_cache_dst, ncp, nc_dst); 284 ncp->nc_vp->v_dd = NULL; 285 } else { 286 TAILQ_REMOVE(&ncneg, ncp, nc_dst); 287 numneg--; 288 } 289 numcache--; 290 cache_free(ncp); 291 if (vp) 292 vdrop(vp); 293 } 603 void 604 cache_purge(vp) 605 struct vnode *vp; 606 { 607 608 CTR1(KTR_VFS, "cache_purge(%p)", vp); 609 CACHE_LOCK(); 610 while (!LIST_EMPTY(&vp->v_cache_src)) 611 cache_zap(LIST_FIRST(&vp->v_cache_src)); 612 while (!TAILQ_EMPTY(&vp->v_cache_dst)) 613 cache_zap(TAILQ_FIRST(&vp->v_cache_dst)); 614 vp->v_dd = NULL; 615 CACHE_UNLOCK(); 616 } (kgdb) fr 8 #8 0xc07fd57c in cache_purge (vp=0xc890533c) at /usr/src/sys/kern/vfs_cache.c:613 613 struct namecache *ncp, *nnp; (kgdb) p *vp $1 = {v_type = VREG, v_tag = 0xc0b37e38 "ufs", v_op = 0xc0bfbdc0, v_data = 0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xcc342450, tqe_prev = 0xcc31e350}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = {le_next = 0x0, le_prev = 0xc65e99fc}, v_hash = 6643674, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xcc33783c, tqh_last = 0xcc33784c}, v_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = { lk_object = {lo_name = 0xc0b37e38 "ufs", lo_type = 0xc0b37e38 "ufs", lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 0xc0c42d10, lk_flags = 262208, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 51, lk_lockholder = 0xc64bf8c0, lk_newlock = 0x0}, v_interlock = {lock_object = { lo_name = 0xc0b418b9 "vnode interlock", lo_type = 0xc0b418b9 "vnode interlock", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0xc8905394, v_holdcnt = 1, v_usecount = 0, v_iflag = 128, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0xcc30acf0, tqe_prev = 0xc0c4f3ac}, v_bufobj = { bo_mtx = 0xc89053c4, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xc8905400}, bv_root =
ZFS group ownership
I don't know if this is the correct list to discuss this matter, if not I apologize in advance. I've always understood group ownership as a way to allow members of the same group to operate on files / folders which belong to that group, while leaving out others. Let's suppose to have a directory /root/test (UFS file system) I do this: cd /root chmod -R 770 test chown -R www:www test (I use group www as an example, since it's already present on a base system) My user "gferro" also belongs to group www and has umask 007 su - gferro touch qweq mkdir asda If I watch now the file and directory I've just created: --- %ls -la total 6 drwxrwx--- 3 www www512 Sep 12 13:39 . drwxr-xr-x 4 rootwheel 512 Sep 12 13:02 .. drwxrwx--- 2 gferro www512 Sep 12 13:39 asda -rw-rw 1 gferro www 0 Sep 12 13:38 qweq --- I see that both belongs to group www, even though gferro's base group is "gferro": --- id gferro uid=1001(gferro) gid=1001(gferro) groups=1001(gferro),80(www) --- This means that all those user's who belong to group "www" will be able to work with the files and directories I've created. Now I try to do the same on a zfs partition on the same machine This is what I see with ls --- ls -la total 4 drwxrwx--- 3 www www 4 Sep 12 13:43 . drwxr-xr-x 4 rootwheel 4 Sep 12 13:43 .. drwxrwx--- 2 gferro gferro 2 Sep 12 13:43 asda -rw-rw 1 gferro gferro 0 Sep 12 13:43 qweq --- As you can see, both file and directory belongs now to "gferro" and not "www". This means that other users won't even be able to read my files / dir, let alone modify them. What I ask now is: is this a bug or a feature? How can I achieve my goal in ZFS, that is allowing members of the same group to operate with the files / dirs they create? Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ZFS group ownership
I don't know if this is the correct list to discuss this matter, if not I apologize in advance. I've always understood group ownership as a way to allow members of the same group to operate on files / folders which belong to that group, while leaving out others. Let's suppose to have a directory /root/test (UFS file system) I do this: cd /root chmod -R 770 test chown -R www:www test (I use group www as an example, since it's already present on a base system) My user "gferro" also belongs to group www and has umask 007 su - gferro touch qweq mkdir asda If I watch now the file and directory I've just created: --- %ls -la total 6 drwxrwx--- 3 www www512 Sep 12 13:39 . drwxr-xr-x 4 rootwheel 512 Sep 12 13:02 .. drwxrwx--- 2 gferro www512 Sep 12 13:39 asda -rw-rw 1 gferro www 0 Sep 12 13:38 qweq --- I see that both belongs to group www, even though gferro's base group is "gferro": --- id gferro uid=1001(gferro) gid=1001(gferro) groups=1001(gferro),80(www) --- This means that all those user's who belong to group "www" will be able to work with the files and directories I've created. Now I try to do the same on a zfs partition on the same machine This is what I see with ls --- ls -la total 4 drwxrwx--- 3 www www 4 Sep 12 13:43 . drwxr-xr-x 4 rootwheel 4 Sep 12 13:43 .. drwxrwx--- 2 gferro gferro 2 Sep 12 13:43 asda -rw-rw 1 gferro gferro 0 Sep 12 13:43 qweq --- As you can see, both file and directory belongs now to "gferro" and not "www". This means that other users won't even be able to read my files / dir, let alone modify them. What I ask now is: is this a bug or a feature? How can I achieve my goal in ZFS, that is allowing members of the same group to operate with the files / dirs they create? Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ZFS group ownership
I don't know if this is the correct list to discuss this matter, if not I apologize in advance. I've always understood group ownership as a way to allow members of the same group to operate on files / folders which belong to that group, while leaving out others. Let's suppose to have a directory /root/test (UFS file system) I do this: cd /root chmod -R 770 test chown -R www:www test (I use group www as an example, since it's already present on a base system) My user "gferro" also belongs to group www and has umask 007 su - gferro touch qweq mkdir asda If I watch now the file and directory I've just created: --- %ls -la total 6 drwxrwx--- 3 www www512 Sep 12 13:39 . drwxr-xr-x 4 rootwheel 512 Sep 12 13:02 .. drwxrwx--- 2 gferro www512 Sep 12 13:39 asda -rw-rw 1 gferro www 0 Sep 12 13:38 qweq --- I see that both belongs to group www, even though gferro's base group is "gferro": --- id gferro uid=1001(gferro) gid=1001(gferro) groups=1001(gferro),80(www) --- This means that all those user's who belong to group "www" will be able to work with the files and directories I've created. Now I try to do the same on a zfs partition on the same machine This is what I see with ls --- ls -la total 4 drwxrwx--- 3 www www 4 Sep 12 13:43 . drwxr-xr-x 4 rootwheel 4 Sep 12 13:43 .. drwxrwx--- 2 gferro gferro 2 Sep 12 13:43 asda -rw-rw 1 gferro gferro 0 Sep 12 13:43 qweq --- As you can see, both file and directory belongs now to "gferro" and not "www". This means that other users won't even be able to read my files / dir, let alone modify them. What I ask now is: is this a bug or a feature? How can I achieve my goal in ZFS, that is allowing members of the same group to operate with the files / dirs they create? Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ZFS group ownership
On 09/12/2009 04:49 AM, Giulio Ferro wrote: [...] > How can I achieve my goal in ZFS, that is allowing members of the same > group to operate with the files / dirs they create? Does setting the setgid bit on the directory have any effect? -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
Re: ZFS group ownership
On Sat, 12 Sep 2009, Giulio Ferro wrote: I don't know if this is the correct list to discuss this matter, if not I apologize in advance. freebsd-questions might have been better, but I don't think you're too far off. It wasn't necessary to post three times though :) [On UFS, files are created with the same group as the directory that contains them. On ZFS, they are created with the primary group of the user who creates them.] What I ask now is: is this a bug or a feature? Both, I think :) The behavior you describe on UFS (group comes from the directory) is standard for BSD-based systems like FreeBSD. On SysV-based systems, however, the default is that the group comes from the user, as you describe on ZFS. ZFS was originally developed for Solaris, a descendent of SysV, so it's not surprising that it also has this behavior. However, this is at least a documentation bug, since the open(2) man page describes the BSD behavior without mentioning exceptions. How can I achieve my goal in ZFS, that is allowing members of the same group to operate with the files / dirs they create? On SysV, you can get BSD-type behavior by setting the sgid bit on the directory in question, e.g. "chmod g+s dir". Then new files will inherit their group from the directory. I suspect this will work on FreeBSD/ZFS too even though "chmod g+s" on a directory is undocumented. -- Nate Eldredge n...@thatsmathematics.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"