Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm writing shellcode to exploit a buffer overflow vulnerability on a server. To do so I have port binding shellcode that I send to the server and then I run (from a linux terminal) the command telnet serverAdress 4444 where 4444 is the port which I have opened up. The hope is that I will receive a shell back that I can use to execute commands. However, I always end up with the command

bin/sh: can't access tty; job control turned off

I can't change any of the server code, and I believe the shellcode is correct because I got it from this website ( From my research, it appears that this may have to do with the mode that my terminal is running in (something called interactive mode...or something like that).

All computers involved are linux machines and the machine that I am on is running the latest version of Ubuntu.

Any ideas what this job control error means and how I can fix it?

share|improve this question
up vote 2 down vote accepted

Just remove /dev/console

cd /dev
rm -f console
ln -s ttyS0 console

edit/change the /etc/inittab content



share|improve this answer
Why does this work? – Jon Bringhurst Mar 25 '13 at 14:34
Probably because the console is not allowed by the shell to be a controlling terminal. But I have no idea why that is. – user1147688 May 27 '14 at 13:41
How to make the edit "::askfirst:/bin/sh" to "ttyS0::askfirst:/bin/sh". What commands should be given ? Bcoz it says "/bin/sh: ::askfirst:/bin/sh: not found" – MycrofD Jun 5 '15 at 12:50

This mean that advanced commands such as Ctrl+Z and Ctrl+C are not available, because sh is not writing to a tty, but to a socket. For this reason, sh will not support background processes (command &) and the associated bg/fg/disown/jobs commands. But note that processes forking themselves and closing their inputs will still work.

You might have noticed that if a background jobs tries to read data from the terminal, the shell stops it (as in, SIGSTOP) and informs you that it has paused the process. If the shell does not do so, you have a race condition and what you write may end up in the background process or in the shell. This makes for an interesting and infuriating mess in your shell session.

Either use a more elaborate shellcode that creates a virtual terminal (but that's not a shellcode anymore once that happens), or just be aware that your ugly hack has limitations.

share|improve this answer

I had the same issue in Debian Mate. I just run an fsck from a live usb on dev/sda1 where / directory was installed.

Hope I helped someone

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.