[UBUNTU 20.04] s390x: z13 wcsncmp implementation segfaults if n=1
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Triaged
|
Medium
|
Skipper Bug Screeners | |||
glibc (Ubuntu) | Status tracked in Oracular | |||||
Focal |
Triaged
|
Low
|
Unassigned | |||
Jammy |
Triaged
|
Medium
|
Unassigned | |||
Noble |
Triaged
|
Medium
|
Unassigned | |||
Oracular |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
The >=z13 wcsncmp implementation segfaults if n=1 and there is only one character (equal on both strings) before the page end. Then it loads and compares one character and misses to check n again. The following load fails.
This issue was reported here:
Bug 31934 - wcsncmp crash on s390x on vlbb instruction
https:/
And fixed upstream (first in glibc 2.40):
s390x: Fix segfault in wcsncmp [BZ #31934]
https:/
This Fix was cherry-picked to the current branches glibc 2.32-39:
- 2.39: commit 5c46e6b66636be0
- 2.38: commit 712453634c8efd7
- 2.37: commit 340ca2d51483716
- 2.36: commit a70c55a91b2b361
- 2.35: commit c7cd62653850135
- 2.34: commit 87fa7bfb84895bb
- 2.33: commit 5f08d1df2c07904
- 2.32: commit 5ad449c398a845a
In case somebody needs the fix for older glibc releases (issue was introduced with glibc 2.23), feel free to just cherry-pick it. Note, that the file was moved from sysdeps/
tags: | added: architecture-s39064 bugnameltc-207895 severity-medium targetmilestone-inin--- |
Changed in ubuntu: | |
assignee: | nobody → Skipper Bug Screeners (skipper-screen-team) |
affects: | ubuntu → linux (Ubuntu) |
tags: | added: rls-nn-incoming |
Changed in glibc (Ubuntu Noble): | |
importance: | Undecided → Medium |
Changed in glibc (Ubuntu Focal): | |
importance: | Undecided → Medium |
Changed in glibc (Ubuntu Jammy): | |
importance: | Undecided → Medium |
Changed in glibc (Ubuntu Oracular): | |
status: | New → In Progress |
Changed in glibc (Ubuntu Focal): | |
status: | New → Triaged |
Changed in glibc (Ubuntu Jammy): | |
status: | New → Triaged |
Changed in glibc (Ubuntu Focal): | |
importance: | Medium → Low |
Changed in glibc (Ubuntu Noble): | |
status: | New → Triaged |
tags: | added: foundations-todo |
tags: | removed: rls-nn-incoming |
Changed in ubuntu-z-systems: | |
status: | New → Triaged |
Hello and thanks for having reported this, actually shared this with us.
Is there a simple reproducer or test case that could be used to provoke the segfault and with that to verify that it got fixed with the commit included?