NewAbora OS v4.1 Horizon is out.Community Q&A
Abora OS

Trust / Security

Security, without guesswork.

Review upstream security advisories and Abora OS assessments. We distinguish confirmed facts from investigations in progress, and never infer Abora exposure from another distribution’s package status.

Sitewide announcements

High-priority CVE alerts

New NIST NVD Linux-kernel matches and recent CISA KEV entries are rated on Abora Team Priority. ATP 4+ is announced sitewide; Abora package impact remains separately assessed.

CVE-2026-99153Abora P4InvestigatingCVSS v3.1 · 9.8 · Critical

In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Validate the ITT reflected in a Reject PDUA Reject PDU carries a copy of the header it rejects, andiscsi_handle_reject() takes the ITT out of that copy to find the task toclean up: memcpy(&rejected_pdu, data, sizeof(struct iscsi_hdr)); ... task = iscsi_itt_to_task(conn, rejected_pdu.itt);That value is whatever the target put there. iscsi_itt_to_task() boundsthe index against cmds_max and checks nothing else, so an

In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Validate the ITT reflected in a Reject PDUA Reject PDU carries a copy of the header it rejects, andiscsi_handle_reject() takes the ITT out of that copy to find the task toclean up: memcpy(&rejected_pdu, data, sizeof(struct iscsi_hdr)); ... task = iscsi_itt_to_task(conn, rejected_pdu.itt);That value is whatever the target put there. iscsi_itt_to_task() boundsthe index against cmds_max and checks nothing else, so any task in thepool can be named, and iscsi_nop_out_rsp() then completes it.An index that has never been used gives a NULL task->conn: the pool iszeroed at session setup and conn is assigned only when a task isallocated. If the task was used and returned, iscsi_complete_task() hitsits WARN_ON_ONCE(task->state == ISCSI_TASK_FREE) and the refcountunderflows. An in-flight SCSI command is completed as successful - a 1MiB read returned 1048576 with none of its buffer written and nowarning.Validate the reflected ITT the way iscsi_itt_to_ctask() validates acommand ITT, and require the task to be in flight and not a SCSIcommand.[ 6.248477] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI[ 6.249357] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067][ 6.249951] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy)[ 6.250718] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 6.251616] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160[ 6.252043] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00[ 6.252813] RSP: 0018:ffff88806c907b80 EFLAGS: 00010206[ 6.253042] RAX: dffffc0000000000 RBX: ffff88800607e000 RCX: ffffffff8d571a25[ 6.253345] RDX: 000000000000000c RSI: ffff88806c907c38 RDI: 0000000000000060[ 6.253642] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff235a504[ 6.253947] R10: 0000000000000003 R11: 7463656e6e6f6320 R12: 0000000000000000[ 6.254251] R13: 0000000000000000 R14: ffff88806c907c38 R15: 0000000000000000[ 6.254549] FS: 0000000000000000(0000) GS:ffff8880d95bc000(0000) knlGS:0000000000000000[ 6.254887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 6.255140] CR2: 00007fc393e8ffc0 CR3: 0000000005252006 CR4: 0000000000770ef0[ 6.255439] PKRU: 55555554[ 6.255564] Call Trace:[ 6.255674] <IRQ>[ 6.255768] __iscsi_complete_pdu+0x18bf/0x22a0[ 6.256733] iscsi_complete_pdu+0x54/0xa0[ 6.256905] iscsi_tcp_data_recv_done+0xf4/0x250[ 6.257103] iscsi_tcp_recv_skb+0x31e/0xec0[ 6.257680] iscsi_sw_tcp_recv+0x12f/0x390[ 6.258061] __tcp_read_sock+0x1ab/0x810[ 6.258853] iscsi_sw_tcp_data_ready+0x18b/0x510[ 6.259808] tcp_data_queue+0x1f13/0x4cd0[ 6.260567] tcp_rcv_established+0x8a5/0x3a00[ 6.261931] tcp_v4_do_rcv+0x449/0x960[ 6.262269] tcp_v4_rcv+0x2245/0x3bc0

Source: NIST NVD · Last checked 2026-11-01

NVD record
CVE-2026-99154Abora P4InvestigatingCVSS v3.1 · 9.8 · Critical

In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Reject a negative task index from parse_pdu_ittA transport that implements parse_pdu_itt hands libiscsi an index takenfrom the PDU, and both lookups bound it from above only: if (i >= session->cmds_max)i and cmds_max are both int, so a negative index passes andsession->cmds[i] is read from before the array.be2iscsi produces one. beiscsi_parse_pdu() assigns the raw tag, *index = (int)itt;and beiscsi_complete_pdu()

In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Reject a negative task index from parse_pdu_ittA transport that implements parse_pdu_itt hands libiscsi an index takenfrom the PDU, and both lookups bound it from above only: if (i >= session->cmds_max)i and cmds_max are both int, so a negative index passes andsession->cmds[i] is read from before the array.be2iscsi produces one. beiscsi_parse_pdu() assigns the raw tag, *index = (int)itt;and beiscsi_complete_pdu() forwards an unsolicited NOP-In from thehardware async ring without replacing its ITT, so the value is thetarget's. It also reports the session's own age rather than the one inthe tag, which leaves the age comparison in iscsi_verify_itt() withnothing to reject.Bound the index from below in both lookups.

Source: NIST NVD · Last checked 2026-11-01

NVD record
CVE-2026-98323Abora P4InvestigatingCVSS v3.1 · 9.8 · Critical

In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Bound fragmented header copies by the remaining lengthsiw_get_hdr() can receive an extended DDP/RDMAP header across more thanone TCP callback.

In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Bound fragmented header copies by the remaining lengthsiw_get_hdr() can receive an extended DDP/RDMAP header across more thanone TCP callback. The first callback may receive most of the header,while the next one still limits the copy to hdrlen - MIN_DDP_HDR insteadof the number of missing bytes. This makes the destination move past theend of the header and overwrite the receive state, includingfpdu_part_rcvd. A later callback can then use a negative fpdu_part_rcvdvalue as a copy offset, which creates an OOB write.Use the number of header bytes already received when calculating thenext copy length.

Source: NIST NVD · Last checked 2026-11-01

NVD record
CVE-2026-98365Abora P4InvestigatingCVSS v3.1 · 9.8 · Critical

In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB accessmr_check_range() validates that [iova, iova+length) falls within theregistered MR range using wraparound-prone arithmetic: if (iova < mr->ibmr.iova || iova + length > mr->ibmr.iova + mr->ibmr.length)A remote peer can craft an RDMA-Write/Read RETH so that iova + lengthwraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing thecheck. rxe_mr_iova_to_index

In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB accessmr_check_range() validates that [iova, iova+length) falls within theregistered MR range using wraparound-prone arithmetic: if (iova < mr->ibmr.iova || iova + length > mr->ibmr.iova + mr->ibmr.length)A remote peer can craft an RDMA-Write/Read RETH so that iova + lengthwraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing thecheck. rxe_mr_iova_to_index() then computes a huge index (int idx, onlyguarded by WARN_ON) and rxe_mr_copy_xarray() dereferencesmr->page_info[huge], causing an out-of-bounds read/write and a kerneloops that is triggerable by an unauthenticated remote peer.Rewrite the check in overflow-safe form; the first two clauses guaranteethat the subsequent subtractions do not underflow: if (iova < mr->ibmr.iova || length > mr->ibmr.length || iova - mr->ibmr.iova > mr->ibmr.length - length)With the fix, mr_check_range() returns -EINVAL for the crafted iova andthe responder reports REMOTE_ACCESS_ERROR instead of triggering the OOB.

Source: NIST NVD · Last checked 2026-11-01

NVD record
CVE-2026-99999Abora P4InvestigatingCVSS v3.1 · 9.3 · Critical

In the Linux kernel, the following vulnerability has been resolved:ipv4: validate checksum_start before completing checksumIf a packet with bad checksum metadata gets into the ipv4 stack,skb_checksum_help can corrupt the network header and cause a bunch ofmischief.This was discovered and reported by Paulos, and has been reporoducedby others independently since.We really shouldn't allow such packets in, but as a defencein depth measure, let's also check before we complete the checksum.A more comp

In the Linux kernel, the following vulnerability has been resolved:ipv4: validate checksum_start before completing checksumIf a packet with bad checksum metadata gets into the ipv4 stack,skb_checksum_help can corrupt the network header and cause a bunch ofmischief.This was discovered and reported by Paulos, and has been reporoducedby others independently since.We really shouldn't allow such packets in, but as a defencein depth measure, let's also check before we complete the checksum.A more complete validation at input is forthcoming, but needs more work.

Source: NIST NVD · Last checked 2026-11-01

NVD record
CVE-2026-98464Abora P4InvestigatingCVSS v3.1 · 9.3 · Critical

In the Linux kernel, the following vulnerability has been resolved:RISC-V: KVM: Synchronize hrtimer callback during teardownThe non-Sstc hrtimer callback clears next_set before its final uses ofthe enclosing vCPU.

In the Linux kernel, the following vulnerability has been resolved:RISC-V: KVM: Synchronize hrtimer callback during teardownThe non-Sstc hrtimer callback clears next_set before its final uses ofthe enclosing vCPU. If teardown observes next_set as false while thecallback is still running, kvm_riscv_vcpu_timer_cancel() skipshrtimer_cancel() and kvm_destroy_vcpus() can free the vCPU before thecallback enters kvm_riscv_vcpu_set_interrupt().A guest can arm the timer with SBI TIME and request shutdown with SBIlegacy shutdown or SRST. A VMM that honors KVM_EXIT_SYSTEM_EVENT anddestroys the VM supplies the teardown side of the race; no post-launchhost ioctl is needed to arm or request teardown.On upstream master 62cc90241548, generic KASAN reported: BUG: KASAN: slab-use-after-free in do_raw_spin_lock Write of size 4 at addr ff60000005e58898 kvm_riscv_vcpu_set_interrupt kvm_riscv_vcpu_hrtimer_expired __hrtimer_run_queues hrtimer_interruptThe object was allocated by KVM_CREATE_VCPU and freed concurrently by: kvm_destroy_vcpus kvm_arch_destroy_vm kvm_destroy_vm __fputFor deterministic validation, I added mdelay(1000) immediately afterthe existing next_set = false assignment. This only widens theexisting post-clear callback window. A no-delay trace build naturallyreached the callback-after-teardown-start/before-deinit ordering in 12of 200 runs, but 1,500 stock-kernel stress iterations did not produce aKASAN report, so natural reproduction is timing-sensitive.Always invoke hrtimer_cancel() for an initialized timer. Preserve theexisting -EINVAL result when the timer is no longer set, but only aftersynchronizing with a running callback.With this patch, hrtimer_cancel() blocked for the full widened callbackwindow before vCPU destruction. KASAN reported no error in 100fixed-and-widened runs or 200 fix-only timing-sweep runs.

Source: NIST NVD · Last checked 2026-11-01

NVD record
CVE-2026-98490Abora P4InvestigatingCVSS v3.1 · 9.8 · Critical

In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: conntrack: fix helper UAF due to extensions reallocWhile calling the helpers, a raw pointer to the extensions area iswired into expectations list: -> nf_ct_helper() -> helper->help() -> nf_ct_expect_related_report() -> nf_ct_expect_insert() -> hlist_add_head_rcu(&exp->lnode, &master_help->expectations)In case the connection is not confirmed yet, more extensions can beadded afterwards with *_ext_add() calls reall

In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: conntrack: fix helper UAF due to extensions reallocWhile calling the helpers, a raw pointer to the extensions area iswired into expectations list: -> nf_ct_helper() -> helper->help() -> nf_ct_expect_related_report() -> nf_ct_expect_insert() -> hlist_add_head_rcu(&exp->lnode, &master_help->expectations)In case the connection is not confirmed yet, more extensions can beadded afterwards with *_ext_add() calls reallocating the extensionspace and leaving the now invalid pointer in the expectations listthat is later accessed while removing the expectation.Make sure that helpers are called at the end after all the otherextensions are already added.Note that the helper rejection now leaves the mark and labels set,but that's not different from how the NAT was handled before or howthe mark and the labels were handled on confirmation failure. Andthere are no atomicity guarantees provided by the API anyway.

Source: NIST NVD · Last checked 2026-11-01

NVD record
CVE-2026-98548Abora P4InvestigatingCVSS v3.1 · 9.8 · Critical

In the Linux kernel, the following vulnerability has been resolved:sctp: discard the rest of the packet on a stale-cookie errorWhen an association is in COOKIE-ECHOED state and the peer sends abundled [ERROR(Stale Cookie)][DATA] packet from one of its non-primaryaddresses, processing the ERROR chunk takes the non-fatal stale-cookieretry path sctp_sf_do_5_2_6_stale(), which queuesSCTP_CMD_DEL_NON_PRIMARY while keeping the association alive.sctp_cmd_del_non_primary() removes every non-primary tran

In the Linux kernel, the following vulnerability has been resolved:sctp: discard the rest of the packet on a stale-cookie errorWhen an association is in COOKIE-ECHOED state and the peer sends abundled [ERROR(Stale Cookie)][DATA] packet from one of its non-primaryaddresses, processing the ERROR chunk takes the non-fatal stale-cookieretry path sctp_sf_do_5_2_6_stale(), which queuesSCTP_CMD_DEL_NON_PRIMARY while keeping the association alive.sctp_cmd_del_non_primary() removes every non-primary transport -including the very transport this packet arrived on, which is stillreferenced by the receive lookup and shared by all chunks of thepacket via chunk->transport.sctp_assoc_rm_peer() does redirect asoc->peer.last_data_from away fromthe removed transport, but right afterwards the bundled DATA chunkmakes sctp_assoc_bh_rcv() re-registerasoc->peer.last_data_from = chunk->transport unconditionally, undoingthe redirection with the just-removed transport.Once the packet is done, the receive reference is dropped and thetransport is RCU-freed, while the surviving association keeps thedangling last_data_from. A later FWD-TSN (or the delayed SACK timer)makes sctp_gen_sack() dereference it (->param_flags and friends), andsctp_make_sack()/sctp_outq_select_transport() may write to the freedobject and link it into the live transport list. This is ause-after-free triggerable by any malicious SCTP peer (or a localunprivileged user acting as one) with no capabilities required: BUG: KASAN: slab-use-after-free in sctp_do_sm+0x498a/0x5660 Read of size 4 at addr ffff88800e1e356c by task poc/115 Call Trace: sctp_do_sm <- sctp_assoc_bh_rcv <- sctp_inq_push <- sctp_rcv <- ip_protocol_deliver_rcu <- ip_rcv Allocated: sctp_transport_new <- sctp_assoc_add_peer <- sctp_process_init (INIT-ACK processing) Freed: kfree <- sctp_transport_destroy_rcu <- rcu_core (call_rcu queued by sctp_transport_put at end of sctp_rcv) The buggy address is located 364 bytes inside of freed 1024-byte region [ffff88800e1e3400, ffff88800e1e3800), cache kmalloc-1kNote that commit 03a9d10ecf71 ("sctp: drop a chunk if its transportwas removed") only covers the window between the receive lookup andthe chunk processing (e.g. an ASCONF DEL-IP racing the socket backlog);here the transport is removed *while* the packet is being processed,by an earlier chunk of the same packet, so the drop in sctp_inq_push()does not reach this path. Verified with the bundled [ERROR(StaleCookie)][DATA] + FWD-TSN reproducer: the KASAN report above stillfires with that commit applied, and is gone with this patch on top.Fix it by discarding the rest of the packet on this path, as suggestedby Xin. After the stale-cookie ERROR has sent the association back toCOOKIE-WAIT and removed the non-primary transports, the remainingchunks of the packet can only run against the restarted handshakewhile referencing the removed arrival transport throughchunk->transport: besides the last_data_from registration above,sctp_cmd_setup_t2() and the sctp_make_*() reply builders would alsocopy that pointer into association-lifetime state thatsctp_assoc_rm_peer() has already sanitized. Let the peer retransmitthem, in line with what sctp_inq_push() does for chunks whosetransport was removed before processing.

Source: NIST NVD · Last checked 2026-11-01

NVD record
CVE-2026-98549Abora P4InvestigatingCVSS v3.1 · 9.1 · Critical

In the Linux kernel, the following vulnerability has been resolved:tcp: prevent collapsing skbs across boundary in rtx queuetcp_write_collapse_fence() sets TCP_SKB_CB(skb)->eor = 1 ontcp_write_queue_tail(sk) to prevent skbs queued after a switch todevice encryption from being collapsed into earlier skbs.The fence is a no-op if all earlier data has already been transmittedwhen the switch happens: sk->sk_write_queue is empty. The not yetacknowledged earlier skbs wait in sk->tcp_rtx_queue with eor

In the Linux kernel, the following vulnerability has been resolved:tcp: prevent collapsing skbs across boundary in rtx queuetcp_write_collapse_fence() sets TCP_SKB_CB(skb)->eor = 1 ontcp_write_queue_tail(sk) to prevent skbs queued after a switch todevice encryption from being collapsed into earlier skbs.The fence is a no-op if all earlier data has already been transmittedwhen the switch happens: sk->sk_write_queue is empty. The not yetacknowledged earlier skbs wait in sk->tcp_rtx_queue with eor 0.On a subsequent retransmit or SACK shift, tcp_retrans_try_collapse() ortcp_shift_skb_data() can then merge an skb queued after the switch intoone queued before it.Both users of the fence are affected:- psp: devices only encrypt skbs with skb->decrypted set. The merged skb keeps decrypted = 0 from the earlier skb, so merged data sent after psp_sock_assoc_set_tx() is retransmitted in cleartext.- tls device offload: the merged skb straddles the start marker set in tls_set_device_offload(). The software fallback (fill_sg_in() returns -EINVAL) and the mlx5, nfp and funeth drivers cannot handle such an skb and drop it. Every retransmit rebuilds the same skb, so the connection stalls.Fix this in two places, for defense in depth:1. Fall back to tcp_rtx_queue_tail(sk) in tcp_write_collapse_fence() when tcp_write_queue_tail(sk) is NULL.2. Check !skb_cmp_decrypted(to, from) in tcp_skb_can_collapse(), as tcp_skb_can_collapse_rx() does on receive. skb_shift(), which both collapse paths call, already has a DEBUG_NET_WARN_ON_ONCE() for this condition.

Source: NIST NVD · Last checked 2026-11-01

NVD record
CVE-2026-98959Abora P4InvestigatingCVSS v3.1 · 9.8 · Critical

In the Linux kernel, the following vulnerability has been resolved:btrfs: fix xattr replace when multiple xattrs are packed in the same itemIf we have a btrfs_dir_item item that packs multiple xattrs and then wereplace the value of one of them (with the setxattr(2) family of syscalls)with another value of a different size, we end up not having a fullyinitialized btrfs_dir_item, resulting in a corruption that the treechecker will detect at extent buffer writeback time.This is because in btrfs_set

In the Linux kernel, the following vulnerability has been resolved:btrfs: fix xattr replace when multiple xattrs are packed in the same itemIf we have a btrfs_dir_item item that packs multiple xattrs and then wereplace the value of one of them (with the setxattr(2) family of syscalls)with another value of a different size, we end up not having a fullyinitialized btrfs_dir_item, resulting in a corruption that the treechecker will detect at extent buffer writeback time.This is because in btrfs_setxattr() when we find a btrfs_dir_item withmultiple xattrs (due to the crc32c hash of their name being the same)we delete one of the xattr items (btrfs_dir_item) and then insert a newone, but the deletion and insertion results in shifting existing data inthe leaf and therefore when the new value of a xattr has a different size,the new btrfs_dir_item is placed in a leaf section that was notinitialized and we only copy the value's data and set the value's lengthin the new btrfs_dir_item, without setting the name, the name's length,the key (which must be all zeroes for xattrs), flags (BTRFS_FT_XATTR) andtransaction ID.The following script reproduces the issue: $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi mkfs.btrfs -f $DEV mount $DEV $MNT touch $MNT/testfile # Add two xattrs that, on btrfs, have the same hash (crc32c) for their # name and therefore are packed into the same btrfs_dir_item. setfattr -n user.foobar -v 123 $MNT/testfile setfattr -n user.WvG1c1Td -v qwerty $MNT/testfile # Verify the xattrs are present. echo "xattrs before:" getfattr --absolute-names --dump $MNT/testfile # Now replace the value of the foobar xattr with a significantly larger # value. setfattr -n user.foobar -v abcdefghijklmnopqrstuvwxyz $MNT/testfile # Check the xattrs have the expected values. echo "xattrs after:" getfattr --absolute-names --dump $MNT/testfile umount $MNTRunning it: $ ./test.sh (...) xattrs before: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty" user.foobar="123" xattrs after: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty"So the "user.foobar" xattr is missing and there was a transaction abortwhen unmounting the fs with the following traces in dmesg: $ dmesg [869800.159271] BTRFS warning (device sdi): access to eb bytenr 30474240 len 16384 out of range start 16015 len 25964 [869800.159293] ------------[ cut here ]------------ [869800.159296] WARNING: fs/btrfs/extent_io.c:4408 at report_eb_range+0x44/0x60 [btrfs], CPU#8: getfattr/2605179 [869800.168961] Modules linked in: btrfs dm_thin_pool (...) [869800.190527] CPU: 8 UID: 0 PID: 2605179 Comm: getfattr Tainted: G W 7.3.0-rc3-btrfs-next-244+ #1 PREEMPT(full) [869800.193726] Tainted: [W]=WARN [869800.194502] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [869800.197576] RIP: 0010:report_eb_range+0x44/0x60 [btrfs] [869800.198985] Code: 48 8b 7b 18 (...) [869800.203531] RSP: 0018:ffffce4541937d58 EFLAGS: 00010246 [869800.204609] RAX: 0000000000000000 RBX: ffff8dde054b8738 RCX: 0000000000000000 [869800.206137] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffc04c92a0 [869800.207645] RBP: 0000000000003e8f R08: 0000000000000000 R09: 3fffffffffefffff [869800.226175] R10: ffffce4541937a88 R11: 0000000000000003 R12: 000000000000656c [869800.227594] R13: ffff8dde14be800f R14: 000000000000656c R15: 0000000000000069 [869800.229097] FS: 00007f59023bb780(0000) GS:ffff8de5788ed000(0000) knlGS:0000000000000000 [869800.231137] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [869800.232321] CR2: 0000558dc45e6a78 CR3: 0000000765b16004 CR4: 0000000000370ef0 [869800.233783] Call Trace: [869800.234330] <TASK> [869800.234791] read_extent_buffer+0x4d/0x100 [btrfs] [869800.235898] btrfs_listxattr+0x199/0x240 [btrfs] [869800.236912] vfs_listxattr+0x51/0---truncated---

Source: NIST NVD · Last checked 2026-11-01

NVD record

Latest advisories

CVE tracker

Browse all CVEs
CVE-2026-98432Affected
CVSS v3.1 · 9.8 · CriticalCVSS v4.0 · 8.3 · High
Abora P5 · Critical / Urgent

Linux kernel IPv4 TCP option lifetime use-after-free

A race in Linux kernel IPv4 TCP connection handling can free inet_opt data while another CPU is still reading it under RCU protection. The Ubuntu record describes possible use-after-free access while building a SYN-ACK packet; a similar race can occur during request-socket migration. The upstream fix changes the relevant frees to kfree_rcu().

Upstream affected versions: Linux kernel versions 4.4 and newer are affected until the fix is present. Compare each kernel against its own branch's fixed version below; branches without a listed fix remain affected upstream unless a vendor backport is confirmed.

Read advisory
CVE-2024-1086Not Affected
CVSS v3.1 · 7.8 · High
Abora priority not assigned

Linux kernel nf_tables use-after-free

A use-after-free in the Linux kernel netfilter nf_tables component can cause a double free and allow local privilege escalation. CISA lists this vulnerability in its Known Exploited Vulnerabilities catalog.

Upstream affected versions: NVD lists affected upstream versions from 3.15 up to (but not including) 5.15.149; 6.1 up to 6.1.76; 6.2 up to 6.6.15; 6.7 up to 6.7.3; and 6.8-rc1.

Read advisory
CVE-2024-44945Not Affected
CVSS v3.1 · 7.8 · High
Abora priority not assigned

Linux kernel nfnetlink extack initialization

The Linux kernel's nfnetlink code failed to initialize extended-acknowledgment data before acknowledging batch begin/end operations. NVD rates the issue High; the kernel.org record identifies the affected file as net/netfilter/nfnetlink.c.

Upstream affected versions: NVD lists Linux 6.10.0 through 6.10.6 and 6.11-rc1 through 6.11-rc3 as affected.

Read advisory

Abora OS release matrix

Which releases are affected?

By upstream version comparison, the known Abora kernels fall in CVE-2026-98432's affected range unless they include a branch fix or backport. The Alpha's 7.x and v4.2's TBD kernel need exact versions. CVE-2024-1086 and CVE-2024-44945 are outside their listed affected ranges for all known kernels.

Abora OS release versions, Linux kernels, CVE assessments, and recommended actions
Abora releaseRelease dateLinux kernelCVE-2026-98432CVE-2024-1086CVE-2024-44945What to do
v4.2 SolsticeIn developmentTBD
Cannot assess
Cannot assess
Cannot assess
Confirm the final kernel version to assess all listed CVEs.
v4.1 HorizonOctober 3, 2026Linux 7.2.9
Affected
Not affected
Not affected
Upstream-affected: CVE-2026-98432. Update to the matching fix or verify an Abora backport.
v4.0 Everest (2026.08.28)August 29, 2026Linux 7.2
Affected
Not affected
Not affected
Upstream-affected: CVE-2026-98432. Update to the matching fix or verify an Abora backport.
2026.07.27 AlphaJuly 27, 2026Linux 7.x
Needs verification
Not affected
Not affected
Get the full kernel build to decide CVE-2026-98432.
v3 Denali (v3.14)June 2026Linux 7.0 / 7.1
Affected
Not affected
Not affected
Upstream-affected: CVE-2026-98432. Update to the matching fix or verify an Abora backport.
v2.5.0 / v2May / June 2026Linux 7.0
Affected
Not affected
Not affected
Upstream-affected: CVE-2026-98432. Update to the matching fix or verify an Abora backport.
v1.0.1 / v1March 26, 2026Linux 6.19 / 7.0
Affected
Not affected
Not affected
Upstream-affected: CVE-2026-98432. Update to the matching fix or verify an Abora backport.
v36 (First Beta)March 17, 2026Linux 6.19
Affected
Not affected
Not affected
Upstream-affected: CVE-2026-98432. Update to the matching fix or verify an Abora backport.

Affected status compares upstream kernel versions with published CVE ranges and fixes; it is not a certified Abora package audit. Horizontal scrolling is available on narrow screens.