Last updated 30 June 2026

A flaw was found Go's net/http package. Servers using ReverseProxy from net/http in the Go standard library are vulnerable to a data race that results in a denial of service. The highest threat from this vulnerability is to system availability.

A flaw detected in golang: crypto/elliptic, in which P-224 keys as generated can return incorrect inputs, reducing the strength of the cryptography. The highest threat from this vulnerability is confidentiality and integrity.

In the Linux kernel, the following vulnerability has been resolved:

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

In the Linux kernel, the following vulnerability has been resolved:

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

block: avoid possible overflow for chunksectors check in blkstacklimits()

In the Linux kernel, the following vulnerability has been resolved:

jbd2: prevent softlockup in jbd2logdocheckpoint()

Both jbd2logdocheckpoint() and jbd2journalshrinkcheckpointlist() periodically release jlistlock after processing a batch of buffers to avoid long hold times on the jlistlock. However, since both functions contend for jlistlock, the combined time spent waiting and processing can be significant.

jbd2journalshrinkcheckpointlist() explicitly calls condresched() when needresched() is true to avoid softlockups during prolonged operations. But jbd2logdocheckpoint() only exits its loop when needresched() is true, relying on potentially sleeping functions like flushbatch() or waitonbuffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.

watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wbworkfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nativequeuedspinlockslowpath+0x358/0x418 lr : jbd2logdocheckpoint+0x31c/0x438 [jbd2] Call trace: nativequeuedspinlockslowpath+0x358/0x418 jbd2logdocheckpoint+0x31c/0x438 [jbd2] jbd2logwaitforspace+0xfc/0x2f8 [jbd2] addtransactioncredits+0x3bc/0x418 [jbd2] startthishandle+0xf8/0x560 [jbd2] jbd2journalstart+0x118/0x228 [jbd2] ext4journalstartsb+0x110/0x188 [ext4] ext4dowritepages+0x3dc/0x740 [ext4] ext4writepages+0xa4/0x190 [ext4] dowritepages+0x94/0x228 writebacksingleinode+0x48/0x318 writebacksbinodes+0x204/0x590 writebackinodeswb+0x54/0xf8 wbwriteback+0x2cc/0x3d8 wbdowriteback+0x2e0/0x2f8 wbworkfn+0x80/0x2a8 processonework+0x178/0x3e8 workerthread+0x234/0x3b8 kthread+0xf0/0x108 retfromfork+0x10/0x20

So explicitly call condresched() in jbd2logdocheckpoint() to avoid softlockup.

In the Linux kernel, the following vulnerability has been resolved:

net: bridge: fix soft lockup in brmulticastqueryexpired()

When set multicastqueryinterval to a large value, the local variable 'time' in brmulticastsendquery() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call modtimer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rbconsumer:66] CPU: 1 UID: 0 PID: 66 Comm: rbconsumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> netdevallocskb+0x2e/0x3a0 brip6multicastallocquery+0x212/0x1b70 brmulticastsendquery+0x376/0xac0 brmulticastsendquery+0x299/0x510 brmulticastqueryexpired.constprop.0+0x16d/0x1b0 calltimerfn+0x3b/0x2a0 runtimers+0x619/0x950 runtimersoftirq+0x11c/0x220 handlesoftirqs+0x18e/0x560 irqexitrcu+0x158/0x1a0 sysvecapictimerinterrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicastquerier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicastqueryinterval ip link set dev br0 up

The multicaststartupqueryinterval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.

fs: Prevent file descriptor table allocations exceeding INTMAX

In the Linux kernel, the following vulnerability has been resolved:

x86/cpu/hygon: Add missing resctrlcpudetect() in bspinit helper

Since

923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")

resctrlcpudetect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code.

This triggers a division by zero fault during early booting stage on our machines with X86FEATURECQM supported, where getrdtmonresources() tries to calculate monl3config with uninitialized bootcpudata.x86cacheoccscale.

Add the missing resctrlcpudetect() in the Hygon BSP init helper.

[ bp: Massage commit message. ]

In the Linux kernel, the following vulnerability has been resolved:

netlink: avoid infinite retry looping in netlinkunicast()

netlinkattachskb() checks for the socket's read memory allocation constraints. Firstly, it has:

rmem < READONCE(sk->skrcvbuf)

to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:

rmem + skb->truesize > READONCE(sk->skrcvbuf)

The checks don't cover the case when skb->truesize + sk->skrmemalloc is equal to sk->skrcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:

rcu: INFO: rcusched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: <IRQ> dumpstack lib/dumpstack.c:120 nmicpubacktrace.cold lib/nmibacktrace.c:105 nmitriggercpumaskbacktrace lib/nmibacktrace.c:62 rcudumpcpustacks kernel/rcu/treestall.h:335 rcuschedclockirq.cold kernel/rcu/tree.c:2590 updateprocesstimes kernel/time/timer.c:1953 tickschedhandle kernel/time/tick-sched.c:227 tickschedtimer kernel/time/tick-sched.c:1399 hrtimerrunqueues kernel/time/hrtimer.c:1652 hrtimerinterrupt kernel/time/hrtimer.c:1717 sysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1113 asmcallirqonstack arch/x86/entry/entry64.S:808 </IRQ>

netlinkattachskb net/netlink/afnetlink.c:1234 netlinkunicast net/netlink/afnetlink.c:1349 kauditdsendqueue kernel/audit.c:776 kauditdthread kernel/audit.c:897 kthread kernel/kthread.c:328 retfromfork arch/x86/entry/entry64.S:304

Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.

Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

In the Linux kernel, the following vulnerability has been resolved:

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Fix crash in iclupdatetopdownevent()

The perffuzzer found a hard-lockup crash on a RaptorLake machine:

Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0 Comm: swapper/23 Tainted: [W]=WARN Hardware name: Dell Inc. Precision 9660/0VJ762 RIP: 0010:nativereadpmc+0x7/0x40 Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046 .... Call Trace: <TASK> iclupdatetopdownevent+0x165/0x190 ? ktimeget+0x38/0xd0 intelpmureadevent+0xf9/0x210 perfeventread+0xf9/0x210

CPUs 16-23 are E-core CPUs that don't support the perf metrics feature. The iclupdatetopdownevent() should not be invoked on these CPUs.

It's a regression of commit:

f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read")

The bug introduced by that commit is that the istopdownevent() function is mistakenly used to replace the istopdowncount() call to check if the topdown functions for the perf metrics feature should be invoked.

Fix it.

In the Linux kernel, the following vulnerability has been resolved:

Input: mtk-pmic-keys - fix possible null pointer dereference

In mtkpmickeysprobe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer.

Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.

In the Linux kernel, the following vulnerability has been resolved:

net: lan743x: Fix memleak issue when GSO enabled

Always map the skb to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak

In the Linux kernel, the following vulnerability has been resolved:

net: Fix null-ptr-deref by socklockinitclassandname() and rmmod.

When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]

Reproduction Steps:

1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule

At step 3), the CIFS module calls sockrelease() for the underlying TCP socket, and it returns quickly. However, the socket remains in FINWAIT1 because incoming FIN packets are dropped.

At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds.

# ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445

# lsmod | grep cifs cifs 1159168 0

This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sockrelease() and it returns, the TCP socket does not die immediately in order to close the connection gracefully.

While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sklock using socklockinitclassandname().

Once an incoming packet is processed for the socket or a timer fires, sk->sklock is acquired.

Then, LOCKDEP checks the lock context in checkwaitcontext(), where hlockclass() is called to retrieve the lock class. However, since the module has already been unloaded, hlockclass() logs a warning and returns NULL, triggering the null-ptr-deref.

If LOCKDEP is enabled, we must ensure that a module calling socklockinitclassandname() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue.

Let's hold the module reference in socklockinitclassandname() and release it when the socket is freed in skprotfree().

Note that socklockinit() clears sk->skowner for svccreatesocket() that calls socklockinitclassandname() for a listening socket, which clones a socket by skclonelock() without GFPZERO.

[0]: CIFSSERVER="10.0.0.137" CIFSPATH="//${CIFSSERVER}/Users/Administrator/Desktop/CIFSTEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt"

MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFSPATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echointerval=1

iptables -A INPUT -s ${CIFSSERVER} -j DROP

for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done

rm -r ${MNT}

iptables -D INPUT -s ${CIFSSERVER} -j DROP

[1]: DEBUGLOCKSWARNON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifsarc4 nlsucs2utils cifsmd4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: <IRQ> lockacquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lockacquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) rawspinlocknested (kernel/locking/spinlock.c:379) tcpv4rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcpipv4.c:2350) ...

BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: errorcode(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockacquire (kernel/ ---truncated---

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

bpf: Fix deadlock between rcutaskstrace and eventmutex.

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

In the Linux kernel, the following vulnerability has been resolved:

media: platform: exynos4-is: Add hardware sync wait to fimcishwchangemode()

In fimcishwchangemode(), the function changes camera modes without waiting for hardware completion, risking corrupted data or system hangs if subsequent operations proceed before the hardware is ready.

Add fimcishwwaitintmsr0intmsd0() after mode configuration, ensuring hardware state synchronization and stable interrupt handling.

In the Linux kernel, the following vulnerability has been resolved:

jfs: Fix null-ptr-deref in jfsioctrim

[ Syzkaller Report ]

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000087: 0000 [#1 KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f] CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted 6.13.0-rc6-gfbfd64d25c7a-dirty #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Schedext: serialise (enabled+all), task: runnableat=-30ms RIP: 0010:jfsioctrim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? diebody+0x61/0xb0 ? dieaddr+0xb1/0xe0 ? excgeneralprotection+0x333/0x510 ? asmexcgeneralprotection+0x26/0x30 ? jfsioctrim+0x34b/0x8f0 jfsioctl+0x3c8/0x4f0 ? pfxjfsioctl+0x10/0x10 ? pfxjfsioctl+0x10/0x10 sesysioctl+0x269/0x350 ? pfxsesysioctl+0x10/0x10 ? dosyscall64+0xfb/0x210 dosyscall64+0xee/0x210 ? syscallexittousermode+0x1e0/0x330 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fe51f4903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:jfsioctrim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Kernel panic - not syncing: Fatal exception

[ Analysis ]

We believe that we have found a concurrency bug in the fs/jfs module that results in a null pointer dereference. There is a closely related issue which has been fixed:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234

... but, unfortunately, the accepted patch appears to still be susceptible to a null pointer dereference under some interleavings.

To trigger the bug, we think that JFSSBI(ipbmap->isb)->bmap is set to NULL in dbFreeBits and then dereferenced in jfsioctrim. This bug manifests quite rarely under normal circumstances, but is triggereable from a syz-program.

A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.

In ISC BIND9 versions BIND 9.11.14 -> 9.11.19, BIND 9.14.9 -> 9.14.12, BIND 9.16.0 -> 9.16.3, BIND Supported Preview Edition 9.11.14-S1 -> 9.11.19-S1: Unless a nameserver is providing authoritative service for one or more zones and at least one zone contains an empty non-terminal entry containing an asterisk ("") character, this defect cannot be encountered. A would-be attacker who is allowed to change zone content could theoretically introduce such a record in order to exploit this condition to cause denial of service, though we consider the use of this vector unlikely because any such attack would require a significant privilege level and be easily traceable.

A flaw was found in bind. When flooding the target resolver with special queries, an attacker can significantly impair the resolver's performance, effectively denying legitimate clients access to the DNS resolution service.

A race condidition in systemd-coredump allows a local attacker to crash a SUID program and gain read access to the resulting core dump

HID: core: zero-initialize the report buffer

ext/openssl: Memory corruption in opensslencrypt with AES-WRAP-PAD

A vulnerability classified as critical has been found in Linux Kernel. Affected is the function btfdumpnamedups of the file tools/lib/bpf/btfdump.c of the component libbpf. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211032.