Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
|
12-08-2022, 12:01 PM
|
#181
|
LQ Veteran
Registered: May 2008
Posts: 7,000
|
Quote:
Originally Posted by volkerdi
|
Yes, and given that this is the offending code,
Code:
struct archive_write_filter *f;
f = calloc(1, sizeof(*f));
f->archive = _a;
... I seriously doubt that calloc() would fail to find the space for a single structure, and if it does, then I'd suggest your system health has far bigger issues to worry about than a NULL pointer deref that will trigger a SEGFAULT.
Always best to check your return values, but this really doesn't look CVE worthy.
Last edited by GazL; 12-08-2022 at 12:10 PM.
|
|
|
12-12-2022, 06:36 AM
|
#183
|
LQ Sage
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,673
Original Poster
|
SQLite
CVE-2022-46908
Code:
SQLite through 3.40.0, when relying on --safe for execution of an untrusted CLI script, does not properly
implement the azProhibitedFunctions protection mechanism, and instead allows UDF functions such as WRITEFILE.
https://www.cve.org/CVERecord?id=CVE-2022-46908
|
|
|
12-14-2022, 05:21 AM
|
#184
|
LQ Sage
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,673
Original Poster
|
Xorg & Xwayland
Code:
X.Org Server 21.1.5 was released overnight for a new batch of security vulnerabilities:
CVE-2022-46340, CVE-2022-46341, CVE-2022-46342, CVE-2022-46343, CVE-2022-46344, and CVE-2022-4283.
Similarly, XWayland 22.1.6 is out for mitigating much of the same security issues:
CVE-2022-46340, CVE-2022-46341, CVE-2022-46342, CVE-2022-46343, CVE-2022-46344, and CVE-2022-4283.
https://www.phoronix.com/news/X.Org-Server-Holiday-2022
|
|
4 members found this post helpful.
|
12-16-2022, 06:21 PM
|
#185
|
LQ Sage
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,673
Original Poster
|
SDL 1.2
CVE-2021-33657
Code:
There is a heap overflow problem in video/SDL_pixels.c in SDL (Simple DirectMedia Layer) 2.x to 2.0.18 versions.
By crafting a malicious .BMP file, an attacker can cause the application using this library to crash,
denial of service or Code execution.
https://www.cve.org/CVERecord?id=CVE-2021-33657
Code:
Always create a full 256-entry map in case color values are out of range
Fixes libsdl-org/SDL#5042
Backport of CVE-2021-33657 fix from SDL2
https://github.com/libsdl-org/SDL-1....3141e5f0481ae6
|
|
|
12-20-2022, 11:56 AM
|
#186
|
LQ Sage
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,673
Original Poster
|
Dolphin
Revert "portalize drag urls"
Code:
This reverts commit 8d7e600f.
While this revert unfortunately removes Dolphin's ability to copy to
sandboxed applications, the bugs being temporarily fixed by this seem
more important. See the bugs mentioned below for details.
Especially copy-pasting needs to work flawlessly for an application
like Dolphin. After the revert this will either work correctly or – in
the case of sandboxed applications – not at all.
https://invent.kde.org/system/dolphin/-/commit/c8aed8ac
|
|
1 members found this post helpful.
|
12-20-2022, 02:23 PM
|
#187
|
Slackware Maintainer
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,714
|
Quote:
Originally Posted by marav
SQLite
CVE-2022-46908
Code:
SQLite through 3.40.0, when relying on --safe for execution of an untrusted CLI script, does not properly
implement the azProhibitedFunctions protection mechanism, and instead allows UDF functions such as WRITEFILE.
https://www.cve.org/CVERecord?id=CVE-2022-46908
|
From the SQLite Forum:
Quote:
(8) By Larry Brasfield (larrybr) on 2022-12-16 01:09:04 in reply to 6 [link] [source]
Keith's prediction on the next release timing is about right, or maybe not. Releases are always dependent upon satisfactory testing, branch coverage results, and a trial period where interested users can try pre-release versions.
The fix mentioned above is on the trunk branch and will therefore appear in the next release. And, as mentioned, it is always available from the repository.
As others have mentioned, this is not considered a serious bug. The intention behind the feature, which was not quite met due to that bug, is to allow people who get CLI scripts from others, who may not fully trust those others, to run the scripts without having to study them for untoward side-effects.
There are few, if any, people outside of the SQLite development team who have reason to be running strange CLI scripts. The -safe feature arose for their convenience. It was nearly an unpublished feature. Those who run strange CLI scripts, or any other kind of code from outside, non-vetted sources, assume the risk flowing from do so. This is a very different sort of risk than is presented by exploitable malfunctions in the core SQLite library. Calling this one a "CVE" is yet another degradation of the CVE system's value.
|
|
|
3 members found this post helpful.
|
01-04-2023, 03:43 PM
|
#191
|
Slackware Maintainer
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,714
|
Quote:
Originally Posted by marav
|
Not to go off on a rant here, but this first one is, in my humble opinion, a bug rather than a security issue.
The second one is described in the CVE as a "Heap-based Buffer Overflow" but looking at the commit is another (similar) pedestrian out of bounds read, and also is not a security issue.
It's hard to know what to do with things like this. Guess that's what happens when you pay CVE bounties and people fuzz the heck out of something looking for the low hanging fruit.
|
|
4 members found this post helpful.
|
01-04-2023, 03:53 PM
|
#192
|
LQ Sage
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,673
Original Poster
|
Quote:
Originally Posted by volkerdi
Not to go off on a rant here, but this first one is, in my humble opinion, a bug rather than a security issue.
The second one is described in the CVE as a "Heap-based Buffer Overflow" but looking at the commit is another (similar) pedestrian out of bounds read, and also is not a security issue.
It's hard to know what to do with things like this. Guess that's what happens when you pay CVE bounties and people fuzz the heck out of something looking for the low hanging fruit.
|
As it's not the first not, and probably not the last
The best thing to do, then, is to leave the Vim CVEs aside, and let you upgrade from time to time
|
|
|
01-06-2023, 07:18 PM
|
#194
|
LQ Sage
Registered: Sep 2018
Location: Gironde
Distribution: Slackware
Posts: 5,673
Original Poster
|
libX11 1.8.3
Revert "Update XPutBackEvent() to support clients that put back unpadded events"
Code:
This reverts commit d6d6cba9.
The reverted commit intended to fix the problem where an unpadded X
event struct is passed into XPutBackEvent, by creating a padded struct
with _XEventToWire and _XWireToEvent. However, _XWireToEvent updates the
last sequence number in Display, which may cause xlib to complain about
lost sequence numbers.
IMO, the problem that commit tried to solve is a bug in the client
library, and workaround it inside Xlib is bad practice, especially given
the problem it caused. Plus, the offender cited in the original commit
message, freeglut, has already fixed this problem.
Fixes: #176 #174
https://gitlab.freedesktop.org/xorg/...fe2c47f0e56dee
|
|
1 members found this post helpful.
|
All times are GMT -5. The time now is 01:55 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|