Bug 911404 - builtin trap might cause use of uninitialized memory
Summary: builtin trap might cause use of uninitialized memory
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondrej Oprala
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-14 22:25 UTC by Mark Wielaard
Modified: 2016-02-01 02:08 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-04-01 08:30:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
bash-4.2-set_signal_handler.patch (1.95 KB, patch)
2013-02-14 22:25 UTC, Mark Wielaard
no flags Details | Diff

Description Mark Wielaard 2013-02-14 22:25:49 UTC
Created attachment 697433 [details]
bash-4.2-set_signal_handler.patch

Description of problem:

Using the builtin command trap might cause use of uninitialized array original_signals[] values.

Version-Release number of selected component (if applicable):

bash-4.2.42-3.fc18.x86_64

How reproducible:

Always.

Steps to Reproduce:

$ valgrind --track-origins=yes -q bash -c 'trap'
==21281== Conditional jump or move depends on uninitialised value(s)
==21281==    at 0x4541B6: get_all_original_signals (trap.c:619)
==21281==    by 0x477CD4: trap_builtin (trap.def:136)
==21281==    by 0x42F73E: execute_builtin.isra.2 (execute_cmd.c:4121)
==21281==    by 0x431882: execute_simple_command (execute_cmd.c:4546)
==21281==    by 0x432882: execute_command_internal (execute_cmd.c:747)
==21281==    by 0x46F304: parse_and_execute (evalstring.c:319)
==21281==    by 0x41D6F8: run_one_command (shell.c:1325)
==21281==    by 0x41C46C: main (shell.c:698)
==21281==  Uninitialised value was created by a stack allocation
==21281==    at 0x45679A: set_signal_handler (sig.c:665)
==21281== 
trap -- '' SIGRTMAX

This happens when set_signal_handler () is called for a signal that cannot be set with sigaction (). (This will always be the case with for examples SIGKILL and SIGSTOP.) In such cases set_signal_handler () will return random garbage which might be stored and compared as in the above case.

The simplest fix is to return SIG_DFL in such cases to indicate the default signal handler is (still) in place.

Comment 1 Fedora Admin XMLRPC Client 2013-10-07 11:47:51 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Fedora End Of Life 2013-12-21 11:24:31 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Mark Wielaard 2013-12-21 16:57:38 UTC
This is still an issue with bash-4.2.45-4.fc20.x86_64
Please note that there is a patch to resolve the issue as attachment #1 [details]

Comment 4 Ondrej Oprala 2014-01-03 06:07:08 UTC
Thanks for the report.
However, it seems you only attached the patch for the spec file, but not the fix itself.

Comment 5 Mark Wielaard 2014-01-03 09:03:19 UTC
(In reply to Ondrej Oprala from comment #4)
> Thanks for the report.
> However, it seems you only attached the patch for the spec file, but not the
> fix itself.

That is weird, if I look at the detailed diff view:
https://bugzilla.redhat.com/attachment.cgi?id=697433&action=diff
it isn't there.

But if I look at the "raw" patch:
https://bugzilla.redhat.com/attachment.cgi?id=697433
it is...?

Anyway, the actual patch is just a oneliner (plus a comment):

diff --git a/bash-4.2-set_signal_handler.patch b/bash-4.2-set_signal_handler.patch
new file mode 100644
index 0000000..8c89f5b
--- /dev/null
+++ b/bash-4.2-set_signal_handler.patch
@@ -0,0 +1,12 @@
+--- bash-4.2/sig.c.orig	2013-02-14 22:59:31.611024868 +0100
++++ bash-4.2/sig.c	2013-02-14 23:01:37.272562990 +0100
+@@ -668,6 +668,9 @@
+   act.sa_handler = handler;
+   act.sa_flags = 0;
+ 
++  /* If sigaction () fails, assume original handler was the default one. */
++  oact.sa_handler = SIG_DFL;
++
+   /* XXX - bash-4.2 */
+   /* We don't want a child death to interrupt interruptible system calls, even
+      if we take the time to reap children */

Comment 6 Ondrej Oprala 2014-04-01 08:30:45 UTC
This issue should now be fixed in bash-4.3, where the signal handling has been redone.

Comment 7 Mark Wielaard 2014-05-13 13:49:49 UTC
It is fixed indeed. Thanks.


Note You need to log in before you can comment on or make changes to this bug.