SlackwareThis 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.
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.
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.
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.
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.
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.
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.
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.
(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.
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.
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
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
