Bug 2186291 (CVE-2023-29580)

Summary:	CVE-2023-29580 yasm: segmentation violation in yasm_expr_create() in libyasm/expr.c
Product:	[Other] Security Response	Reporter:	Pedro Sampaio <psampaio>
Component:	vulnerability	Assignee:	Nobody <nobody>
Status:	NEW ---	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	fjansen, nickc, sipoyare
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2186293, 2186292, 2186871, 2186872
Bug Blocks:	2186271

Description Pedro Sampaio 2023-04-12 17:27:51 UTC

yasm 1.3.0.55.g101bc was discovered to contain a segmentation violation via the component yasm_expr_create at /libyasm/expr.c.

References:
https://github.com/yasm/yasm/issues/215
https://github.com/z1r00/fuzz_vuln/blob/main/yasm/segv/yasm_expr_create/readmd.md

Comment 1 Pedro Sampaio 2023-04-12 17:28:07 UTC

Created yasm tracking bugs for this issue:

Affects: epel-all [bug 2186293]
Affects: fedora-all [bug 2186292]

Comment 4 Siddhesh Poyarekar 2023-04-14 18:27:35 UTC

Why is this a security issue? Assemblers are not a service and shouldn't be required to accept untrusted input.  Admittedly this is in a library, which may in theory be used to implement services, but I can't imagine this being a safe thing to do regardless of this bug.

Comment 5 Pedro Sampaio 2023-04-14 21:09:21 UTC

(In reply to Siddhesh Poyarekar from comment #4)
> Why is this a security issue? Assemblers are not a service and shouldn't be
> required to accept untrusted input.  Admittedly this is in a library, which
> may in theory be used to implement services, but I can't imagine this being
> a safe thing to do regardless of this bug.

As far as I can see, this CVE was not assigned by us, but by Mitre and since it was published, we have to file the bug nonetheless. Any requests to reject this CVE ID have to be directed to Mitre via cveform:

https://cveform.mitre.org/