On Sat, Feb 18, 2023 at 04:12:08PM +0100, Otto Moerbeek wrote:
> Hi,
>
> these recent sshd double free issue prompted me to look at malloc
> again. I have something bigger brewing, but this diff makes sure the
> to be cleaned chunks (via freezero() or malloc_conceal) particpate in
> the delayed
Thanks Crystal. If somebody wants to commit this, it is OK gnezdo@
Crystal Kolipe writes:
> The iskmemdev function checks for minor number 14 in addition to 0 and 1 on
> the following archs:
>
> amd64, arm64, i386, and riscv64
>
> Device 2, 14 was traditionally /dev/io, which we don't support
Greetings. I am soliciting feedback on a patch to detect and mitigate
uncontrolled ACPI GPE interrupt storms.
Rationale: There have been a number of threads in the recent past on bugs@ and
misc@ with acpi0 spinning a CPU at 100% [1][2][3][4]. The immediate cause is
likely a buggy BIOS and its
I do not expect users to find that field, or play around with it
if they don't know what they do. It's "hidden" in wsconsctl for a
reason. And plainly, I had no time for the wsconsctl part.
On 2/23/23 17:25, joshua stein wrote:
> On Thu, 23 Feb 2023 at 17:05:53 +0100, Tobias Heider wrote:
>>
On Thu, Feb 23, 2023 at 10:25:15AM -0600, joshua stein wrote:
> On Thu, 23 Feb 2023 at 17:05:53 +0100, Tobias Heider wrote:
> > Wow, thank you for looking into this! I've used your version for a few days
> > now and it works really well for me (on a m2 macbook air). I actually think
> > the
On Thu, 23 Feb 2023 at 17:05:53 +0100, Tobias Heider wrote:
> Wow, thank you for looking into this! I've used your version for a few days
> now and it works really well for me (on a m2 macbook air). I actually think
> the default works so well that we can default to 0 for param 143.
>
> IMO we
On Tue, Feb 21, 2023 at 08:10:36PM +0100, Ulf Brosziewski wrote:
> This diff is an extension of Tobias Heider's proposal, which aims at
> providing "Apple-like" button inputs on clickpads. I have added some
> things in order to approximate the behaviour of other input drivers.
>
> It's a quick
Hi,
The basic idea is simple: one of the reasons the recent sshd bug is
potentially exploitable is that a (erroneously) freed malloc chunk
gets re-used in a different role. My malloc has power of two chunk
sizes and so one page of chunks holds many different types of
allocations. Userland malloc
Now that the tricky bits are done, here's my suggestion for simplifying
parse_load_crl_from_mft() after claudio's latest commit.
Since we now explicitly want to look in both locations in all cases, it
seems cleanest to drop the loop altogether and to call the function
twice, once for each
