bash: Update to 4.3.42

Signed-off-by: Marcel Denia <naoir@gmx.net>

4 files changed, 156 insertions, 1 deletions

diff --git a/utils/bash/Makefile b/utils/bash/Makefile
index 9586da5c5..b424c24ea 100644
--- a/utils/bash/Makefile
+++ b/utils/bash/Makefile
@@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk
 BASE_VERSION:=4.3
 
 PKG_NAME:=bash
-PKG_VERSION:=$(BASE_VERSION).39
+PKG_VERSION:=$(BASE_VERSION).42
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(BASE_VERSION).tar.gz
diff --git a/utils/bash/patches/140-upstream-bash43-040.patch b/utils/bash/patches/140-upstream-bash43-040.patch
new file mode 100644
index 000000000..a329d37f3
--- /dev/null
+++ b/utils/bash/patches/140-upstream-bash43-040.patch
@@ -0,0 +1,38 @@
+			     BASH PATCH REPORT
+			     =================
+
+Bash-Release:	4.3
+Patch-ID:	bash43-040
+
+Bug-Reported-by:	Jean Delvare <jdelvare@suse.de>
+Bug-Reference-ID:	<20150609180231.5f463695@endymion.delvare>
+Bug-Reference-URL:	http://lists.gnu.org/archive/html/bug-bash/2015-06/msg00033.html
+
+Bug-Description:
+
+There is a memory leak that occurs when bash expands an array reference on
+the rhs of an assignment statement.
+
+Patch (apply with `patch -p0'):
+
+--- a/subst.c
++++ b/subst.c
+@@ -5782,7 +5782,7 @@ expand_arrayref:
+       /* XXX - does this leak if name[@] or name[*]? */
+       if (pflags & PF_ASSIGNRHS)
+         {
+-          temp = array_variable_name (name, &tt, (int *)0);
++          var = array_variable_part (name, &tt, (int *)0);
+           if (ALL_ELEMENT_SUB (tt[0]) && tt[1] == ']')
+ 	    temp = array_value (name, quoted|Q_DOUBLE_QUOTES, 0, &atype, &ind);
+ 	  else
+--- a/patchlevel.h
++++ b/patchlevel.h
+@@ -25,6 +25,6 @@
+    regexp `^#define[ 	]*PATCHLEVEL', since that's what support/mkversion.sh
+    looks for to find the patch level (for the sccs version string). */
+ 
+-#define PATCHLEVEL 39
++#define PATCHLEVEL 40
+ 
+ #endif /* _PATCHLEVEL_H_ */
diff --git a/utils/bash/patches/141-upstream-bash43-041.patch b/utils/bash/patches/141-upstream-bash43-041.patch
new file mode 100644
index 000000000..75fdace42
--- /dev/null
+++ b/utils/bash/patches/141-upstream-bash43-041.patch
@@ -0,0 +1,67 @@
+			     BASH PATCH REPORT
+			     =================
+
+Bash-Release:	4.3
+Patch-ID:	bash43-041
+
+Bug-Reported-by:	Hanno Böck <hanno@hboeck.de>
+Bug-Reference-ID:	<20150623131106.6f111da9@pc1>, <20150707004640.0e61d2f9@pc1>
+Bug-Reference-URL:	http://lists.gnu.org/archive/html/bug-bash/2015-06/msg00089.html,
+			http://lists.gnu.org/archive/html/bug-bash/2015-07/msg00018.html
+
+Bug-Description:
+
+There are several out-of-bounds read errors that occur when completing command
+lines where assignment statements appear before the command name.  The first
+two appear only when programmable completion is enabled; the last one only
+happens when listing possible completions.
+
+Patch (apply with `patch -p0'):
+
+--- a/bashline.c
++++ b/bashline.c
+@@ -1468,10 +1468,23 @@ attempt_shell_completion (text, start, e
+ 
+       os = start;
+       n = 0;
++      was_assignment = 0;
+       s = find_cmd_start (os);
+       e = find_cmd_end (end);
+       do
+ 	{
++	  /* Don't read past the end of rl_line_buffer */
++	  if (s > rl_end)
++	    {
++	      s1 = s = e1;
++	      break;
++	    }
++	  /* Or past point if point is within an assignment statement */
++	  else if (was_assignment && s > rl_point)
++	    {
++	      s1 = s = e1;
++	      break;
++	    }
+ 	  /* Skip over assignment statements preceding a command name.  If we
+ 	     don't find a command name at all, we can perform command name
+ 	     completion.  If we find a partial command name, we should perform
+--- a/lib/readline/complete.c
++++ b/lib/readline/complete.c
+@@ -689,6 +689,8 @@ printable_part (pathname)
+ 
+   if (temp == 0 || *temp == '\0')
+     return (pathname);
++  else if (temp[1] == 0 && temp == pathname)
++    return (pathname);
+   /* If the basename is NULL, we might have a pathname like '/usr/src/'.
+      Look for a previous slash and, if one is found, return the portion
+      following that slash.  If there's no previous slash, just return the
+--- a/patchlevel.h
++++ b/patchlevel.h
+@@ -25,6 +25,6 @@
+    regexp `^#define[ 	]*PATCHLEVEL', since that's what support/mkversion.sh
+    looks for to find the patch level (for the sccs version string). */
+ 
+-#define PATCHLEVEL 40
++#define PATCHLEVEL 41
+ 
+ #endif /* _PATCHLEVEL_H_ */
diff --git a/utils/bash/patches/142-upstream-bash43-042.patch b/utils/bash/patches/142-upstream-bash43-042.patch
new file mode 100644
index 000000000..bf1546be9
--- /dev/null
+++ b/utils/bash/patches/142-upstream-bash43-042.patch
@@ -0,0 +1,50 @@
+			     BASH PATCH REPORT
+			     =================
+
+Bash-Release:	4.3
+Patch-ID:	bash43-042
+
+Bug-Reported-by:	Nathan Neulinger <nneul@neulinger.org>
+Bug-Reference-ID:	<558EFDF2.7060402@neulinger.org>
+Bug-Reference-URL:	http://lists.gnu.org/archive/html/bug-bash/2015-06/msg00096.html
+
+Bug-Description:
+
+There is a problem when parsing command substitutions containing `case'
+commands within pipelines that causes the parser to not correctly identify
+the end of the command substitution.
+
+Patch (apply with `patch -p0'):
+
+--- a/parse.y
++++ b/parse.y
+@@ -3708,6 +3708,8 @@ eof_error:
+ /*itrace("parse_comsub:%d: lex_inword -> 1 ch = `%c' (%d)", line_number, ch, __LINE__);*/
+ 	      tflags |= LEX_INWORD;
+ 	      lex_wlen = 0;
++	      if (tflags & LEX_RESWDOK)
++		lex_rwlen = 0;
+ 	    }
+ 	}
+ 
+--- a/y.tab.c
++++ b/y.tab.c
+@@ -6020,6 +6020,8 @@ eof_error:
+ /*itrace("parse_comsub:%d: lex_inword -> 1 ch = `%c' (%d)", line_number, ch, __LINE__);*/
+ 	      tflags |= LEX_INWORD;
+ 	      lex_wlen = 0;
++	      if (tflags & LEX_RESWDOK)
++		lex_rwlen = 0;
+ 	    }
+ 	}
+ 
+--- a/patchlevel.h
++++ b/patchlevel.h
+@@ -25,6 +25,6 @@
+    regexp `^#define[ 	]*PATCHLEVEL', since that's what support/mkversion.sh
+    looks for to find the patch level (for the sccs version string). */
+ 
+-#define PATCHLEVEL 41
++#define PATCHLEVEL 42
+ 
+ #endif /* _PATCHLEVEL_H_ */