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"
