New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PATCH] pp_syscall: "I32 retval" truncates the returned value #12248
Comments
From oleg@redhat.comHello, I noticed today that syscall(9, ...) (mmap) doesn't work for me. The problem is obvious, pp_syscall() uses I32 for retval and the The one-liner below should fix the problem. I am not sure where And btw, thanks to all perl developers for perl ;) Oleg. --- a/pp_sys.c if (PL_tainting) { |
From @cpansproutOn Wed Jul 04 05:56:04 2012, oleg@redhat.com wrote:
Thank you. Applied as f9344c9. I don’t supposed it’s possible to -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
@cpansprout - Status changed from 'open' to 'resolved' |
From blgl@stacken.kth.seQuoth Oleg Nesterov:
Note that this doesn't help if the syscall function itself is declared as int syscall(int, ...); which is not unheard of. /Bo Lindbergh |
From oleg@redhat.comFather, I do not know if it is OK to reply to perlbug-followup@perl.org, On 07/04, Father Chrysostomos via RT wrote:
Well, please see below. Not sure it is the best... So. The test-case assumes 64-bit linux, otherwise it won't work. It exploits the fact that vdso is mmapped at "high" address which It does mremap(vdso_addr, 1, 1, 0) which is "nop" but should return Btw, "-w" complains: Hexadecimal number > 0xffffffff non-portable at ... a bit annoying on 64-bit systems... Not sure why Perl_grok_hex() Oleg. #!/usr/bin/perl -w sub find_vdso() my $vdso_addr = find_vdso || die 'not 64-bit linux?'; my $ret = syscall 25, # __NR_mremap $ret == $vdso_addr or die "FAILED\n"; |
From oleg@redhat.comOn 07/04, Bo Lindbergh via RT wrote:
Sure, this change is not needed in this case, but it doesn't hurt? If you meant that libc itself can be buggy (so that the library Or I misunderstood your point? Oleg. |
From @cpansproutOn Thu Jul 05 02:15:16 2012, oleg@redhat.com wrote:
Thank you. I’ll have to adjust this a bit to turn it into a test. Does There is a possibility that another OS might have a plain file called So we should skip early if $^O is not appropriate. -- Father Chrysostomos |
From oleg@redhat.comOn 07/08, Father Chrysostomos via RT wrote:
Yes,
Yes, yes, sure. Bu just in case, please note $^O eq 'linux' is not enough. The test-case assumes 64-bit linux and perl should be compiled Oleg. |
From @cpansproutOn Wed Jul 11 03:57:53 2012, oleg@redhat.com wrote:
This line accounts for that, does it not? my $vdso_addr = find_vdso || die 'not 64-bit linux?'; Please try out the attached patch, based on your script. If it works I don’t have access to a 32-bit linux system, so I am unable to test the -- Father Chrysostomos |
From @cpansproutFrom 9640580f6072df9034acabf7e8f167839751bccd Mon Sep 17 00:00:00 2001 Based on a script provided by Oleg Nesterov. Inline Patchdiff --git a/MANIFEST b/MANIFEST
index 18088ca..541b4d9 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -5340,6 +5340,7 @@ t/op/sub.t See if subroutines work
t/op/svleak.t See if stuff leaks SVs
t/op/switch.t See if switches (given/when) work
t/op/symbolcache.t See if undef/delete works on stashes with functions
+t/op/syscall-113980.t Test that bug #113980 is fixed
t/op/sysio.t See if sysread and syswrite work
t/op/taint.t See if tainting works
t/op/threads_create.pl Ancillary file for t/op/threads.t
diff --git a/t/op/syscall-113980.t b/t/op/syscall-113980.t
new file mode 100644
index 0000000..342997b
--- /dev/null
+++ b/t/op/syscall-113980.t
@@ -0,0 +1,26 @@
+#!/usr/bin/perl -w
+BEGIN { chdir 't'; require './test.pl' }
+use strict;
+
+skip_all "not linux" unless $^O eq 'linux';
+
+sub find_vdso()
+{
+ open my $maps, '<', '/proc/self/maps'
+ or skip_all "/proc/self/maps: $!";
+ no warnings 'portable';
+ /^(.*?)-.*\[vdso\]$/ and return hex $1 for <$maps>;
+}
+
+my $vdso_addr = find_vdso || skip_all 'not 64-bit linux?';
+
+plan 1;
+
+my $ret = syscall 25, # __NR_mremap
+ $vdso_addr, # old_addr
+ 1, # old_len
+ 1, # new_len
+ 0, # flags
+ 0; # new_addr (unused)
+
+is $ret, $vdso_addr, "syscall retval is not truncated"; |
From @nwc10On Wed, Jul 25, 2012 at 11:15:01PM -0700, Father Chrysostomos via RT wrote:
I get this failure on an x86 system: $ ./perl -I../lib op/syscall-113980.t for information: $ cat /proc/self/maps The sparc linux build is still ongoing... I've not yet tried coaxing a build with -m32 on x86_64 Nicholas Clark |
From @cpansproutOn Thu Jul 26 09:19:42 2012, nicholas wrote:
Thank you. That means the skip is not being triggered. Do you know how Obviously calling stime is no good, even if it only works under root. -- Father Chrysostomos |
From @nwc10On Thu, Jul 26, 2012 at 09:59:49AM -0700, Father Chrysostomos via RT wrote:
However, the 4 core MIPs box is faster. And on it, $ ./perl -I../lib op/syscall-113980.t
... -Accflags=-m32 -Aldflags=-m32 -Alddlflags=-m32\ -shared [and I don't know why I need to add -shared - is the hints file buggy?] $ ./perl -I../lib op/syscall-113980.t (output of ./perl -pe0 /proc/self/maps >maps attached)
No, I don't for sure. I think if one is sure it's Linux, run uname -m eg $ uname -m vs $ uname -m I think all the 64 bit architectures happen to match /64$/ But as the above demonstrates, it would need to be a 64 bit process on a 64
For starters, I think skip it if running as root. But I'm not confident how safe or reliable this sort of thing is ever going Nicholas Clark |
From @cpansproutOn Thu Jul 26 12:03:15 2012, nicholas wrote:
I think we just have to leave this untested. -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Thu Jul 26 12:03:15 2012, nicholas wrote:
I think we just have to leave this untested. -- Father Chrysostomos |
From @nwc10On Thu, Jul 26, 2012 at 12:18:01PM -0700, Father Chrysostomos via RT wrote:
Yes, I suspect so too. Nicholas Clark |
Migrated from rt.perl.org#113980 (status was 'resolved')
Searchable as RT113980$
The text was updated successfully, but these errors were encountered: