Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()<br /> <br /> m2sm() converts a u32 slope to a u64 scaled value. For large inputs<br /> (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores<br /> the difference of two such u64 values in a u32 variable `dsm` and<br /> uses it as a divisor. When the difference is exactly 2^32 the<br /> truncation yields zero, causing a divide-by-zero oops in the<br /> concave-curve intersection path:<br /> <br /> Oops: divide error: 0000<br /> RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601)<br /> Call Trace:<br /> init_ed (net/sched/sch_hfsc.c:629)<br /> hfsc_enqueue (net/sched/sch_hfsc.c:1569)<br /> [...]<br /> <br /> Widen `dsm` to u64 and replace do_div() with div64_u64() so the full<br /> difference is preserved.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP<br /> <br /> Weiming Shi says:<br /> <br /> xt_match and xt_target structs registered with NFPROTO_UNSPEC can be<br /> loaded by any protocol family through nft_compat. When such a<br /> match/target sets .hooks to restrict which hooks it may run on, the<br /> bitmask uses NF_INET_* constants. This is only correct for families<br /> whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge<br /> all share the same five hooks (PRE_ROUTING ... POST_ROUTING).<br /> <br /> ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different<br /> semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks<br /> validation silently passes for the wrong reasons, allowing matches to<br /> run on ARP chains where the hook assumptions (e.g. state-&gt;in being<br /> set on input hooks) do not hold. This leads to NULL pointer<br /> dereferences; xt_devgroup is one concrete example:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]<br /> RIP: 0010:devgroup_mt+0xff/0x350<br /> Call Trace:<br /> <br /> nft_match_eval (net/netfilter/nft_compat.c:407)<br /> nft_do_chain (net/netfilter/nf_tables_core.c:285)<br /> nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61)<br /> nf_hook_slow (net/netfilter/core.c:623)<br /> arp_xmit (net/ipv4/arp.c:666)<br /> <br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> Fix it by restricting arptables to NFPROTO_ARP extensions only.<br /> Note that arptables-legacy only supports:<br /> <br /> - arpt_CLASSIFY<br /> - arpt_mangle<br /> - arpt_MARK<br /> <br /> that provide explicit NFPROTO_ARP match/target declarations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rds: ib: reject FRMR registration before IB connection is established<br /> <br /> rds_ib_get_mr() extracts the rds_ib_connection from conn-&gt;c_transport_data<br /> and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a<br /> fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with<br /> i_cm_id = NULL because the connection worker has not yet called<br /> rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with<br /> RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses<br /> the control message before any connection establishment, allowing<br /> rds_ib_post_reg_frmr() to dereference ic-&gt;i_cm_id-&gt;qp and crash the<br /> kernel.<br /> <br /> The existing guard in rds_ib_reg_frmr() only checks for !ic (added in<br /> commit 9e630bcb7701), which does not catch this case since ic is allocated<br /> early and is always non-NULL once the connection object exists.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920<br /> Call Trace:<br /> rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167)<br /> rds_ib_map_frmr (net/rds/ib_frmr.c:252)<br /> rds_ib_reg_frmr (net/rds/ib_frmr.c:430)<br /> rds_ib_get_mr (net/rds/ib_rdma.c:615)<br /> __rds_rdma_map (net/rds/rdma.c:295)<br /> rds_cmsg_rdma_map (net/rds/rdma.c:860)<br /> rds_sendmsg (net/rds/send.c:1363)<br /> ____sys_sendmsg<br /> do_syscall_64<br /> <br /> Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all<br /> non-NULL before proceeding with FRMR registration, mirroring the guard<br /> already present in rds_ib_post_inv(). Return -ENODEV when the connection<br /> is not ready, which the existing error handling in rds_cmsg_send() converts<br /> to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to<br /> start the connection worker.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp<br /> <br /> process_sdp() declares union nf_inet_addr rtp_addr on the stack and<br /> passes it to the nf_nat_sip sdp_session hook after walking the SDP<br /> media descriptions. However rtp_addr is only initialized inside the<br /> media loop when a recognized media type with a non-zero port is found.<br /> <br /> If the SDP body contains no m= lines, only inactive media sections<br /> (m=audio 0 ...) or only unrecognized media types, rtp_addr is never<br /> assigned. Despite that, the function still calls hooks-&gt;sdp_session()<br /> with &amp;rtp_addr, causing nf_nat_sdp_session() to format the stale stack<br /> value as an IP address and rewrite the SDP session owner and connection<br /> lines with it.<br /> <br /> With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this<br /> results in the session-level o= and c= addresses being rewritten to<br /> 0.0.0.0 for inactive SDP sessions. Without stack auto-init the<br /> rewritten address is whatever happened to be on the stack.<br /> <br /> Fix this by pre-initializing rtp_addr from the session-level connection<br /> address (caddr) when available, and tracking via a have_rtp_addr flag<br /> whether any valid address was established. Skip the sdp_session hook<br /> entirely when no valid address exists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD<br /> <br /> __build_packet_message() manually constructs the NFULA_PAYLOAD netlink<br /> attribute using skb_put() and skb_copy_bits(), bypassing the standard<br /> nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes<br /> are allocated (including NLA alignment padding), only data_len bytes<br /> of actual packet data are copied. The trailing nla_padlen(data_len)<br /> bytes (1-3 when data_len is not 4-byte aligned) are never initialized,<br /> leaking stale heap contents to userspace via the NFLOG netlink socket.<br /> <br /> Replace the manual attribute construction with nla_reserve(), which<br /> handles the tailroom check, header setup, and padding zeroing via<br /> __nla_reserve(). The subsequent skb_copy_bits() fills in the payload<br /> data on top of the properly initialized attribute.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()<br /> <br /> When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware<br /> platforms, it has already started the EC and installed the address<br /> space handler with the struct acpi_ec pointer as handler context.<br /> However, acpi_ec_setup() propagates the error without any cleanup.<br /> <br /> The caller acpi_ec_add() then frees the struct acpi_ec for non-boot<br /> instances, leaving a dangling handler context in ACPICA.<br /> <br /> Any subsequent AML evaluation that accesses an EC OpRegion field<br /> dispatches into acpi_ec_space_handler() with the freed pointer,<br /> causing a use-after-free:<br /> <br /> BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289)<br /> Write of size 8 at addr ffff88800721de38 by task init/1<br /> Call Trace:<br /> <br /> mutex_lock (kernel/locking/mutex.c:289)<br /> acpi_ec_space_handler (drivers/acpi/ec.c:1362)<br /> acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293)<br /> acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246)<br /> acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509)<br /> acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700)<br /> acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327)<br /> acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392)<br /> <br /> <br /> Allocated by task 1:<br /> acpi_ec_alloc (drivers/acpi/ec.c:1424)<br /> acpi_ec_add (drivers/acpi/ec.c:1692)<br /> <br /> Freed by task 1:<br /> kfree (mm/slub.c:6876)<br /> acpi_ec_add (drivers/acpi/ec.c:1751)<br /> <br /> The bug triggers on reduced-hardware EC platforms (ec-&gt;gpe

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: mrp: reject zero test interval to avoid OOM panic<br /> <br /> br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied<br /> interval value from netlink without validation. When interval is 0,<br /> usecs_to_jiffies(0) yields 0, causing the delayed work<br /> (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule<br /> itself with zero delay. This creates a tight loop on system_percpu_wq<br /> that allocates and transmits MRP test frames at maximum rate, exhausting<br /> all system memory and causing a kernel panic via OOM deadlock.<br /> <br /> The same zero-interval issue applies to br_mrp_start_in_test_parse()<br /> for interconnect test frames.<br /> <br /> Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both<br /> IFLA_BRIDGE_MRP_START_TEST_INTERVAL and<br /> IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the<br /> netlink attribute parsing layer before the value ever reaches the<br /> workqueue scheduling code. This is consistent with how other bridge<br /> subsystems (br_fdb, br_mst) enforce range constraints on netlink<br /> attributes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: drop logically empty buckets in mtype_del<br /> <br /> mtype_del() counts empty slots below n-&gt;pos in k, but it only drops the<br /> bucket when both n-&gt;pos and k are zero. This misses buckets whose live<br /> entries have all been removed while n-&gt;pos still points past deleted slots.<br /> <br /> Treat a bucket as empty when all positions below n-&gt;pos are unused and<br /> release it directly instead of shrinking it further.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_fw: fix NULL pointer dereference on shared blocks<br /> <br /> The old-method path in fw_classify() calls tcf_block_q() and<br /> dereferences q-&gt;handle. Shared blocks leave block-&gt;q NULL, causing a<br /> NULL deref when an empty cls_fw filter is attached to a shared block<br /> and a packet with a nonzero major skb mark is classified.<br /> <br /> Reject the configuration in fw_change() when the old method (no<br /> TCA_OPTIONS) is used on a shared block, since fw_classify()&amp;#39;s<br /> old-method path needs block-&gt;q which is NULL for shared blocks.<br /> <br /> The fixed null-ptr-deref calling stack:<br /> KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]<br /> RIP: 0010:fw_classify (net/sched/cls_fw.c:81)<br /> Call Trace:<br /> tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)<br /> tc_run (net/core/dev.c:4401)<br /> __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_flow: fix NULL pointer dereference on shared blocks<br /> <br /> flow_change() calls tcf_block_q() and dereferences q-&gt;handle to derive<br /> a default baseclass. Shared blocks leave block-&gt;q NULL, causing a NULL<br /> deref when a flow filter without a fully qualified baseclass is created<br /> on a shared block.<br /> <br /> Check tcf_block_shared() before accessing block-&gt;q and return -EINVAL<br /> for shared blocks. This avoids the null-deref shown below:<br /> <br /> =======================================================================<br /> KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]<br /> RIP: 0010:flow_change (net/sched/cls_flow.c:508)<br /> Call Trace:<br /> tc_new_tfilter (net/sched/cls_api.c:2432)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)<br /> [...]<br /> =======================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: Fix overflow when accumulating packets<br /> <br /> Add a check to ensure that `x25_sock.fraglen` does not overflow.<br /> <br /> The `fraglen` also needs to be resetted when purging `fragment_queue` in<br /> `x25_clear_queues()`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bonding: fix use-after-free in bond_xmit_broadcast()<br /> <br /> bond_xmit_broadcast() reuses the original skb for the last slave<br /> (determined by bond_is_last_slave()) and clones it for others.<br /> Concurrent slave enslave/release can mutate the slave list during<br /> RCU-protected iteration, changing which slave is "last" mid-loop.<br /> This causes the original skb to be double-consumed (double-freed).<br /> <br /> Replace the racy bond_is_last_slave() check with a simple index<br /> comparison (i + 1 == slaves_count) against the pre-snapshot slave<br /> count taken via READ_ONCE() before the loop. This preserves the<br /> zero-copy optimization for the last slave while making the "last"<br /> determination stable against concurrent list mutations.<br /> <br /> The UAF can trigger the following crash:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in skb_clone<br /> Read of size 8 at addr ffff888100ef8d40 by task exploit/147<br /> <br /> CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:123)<br /> print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)<br /> kasan_report (mm/kasan/report.c:597)<br /> skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108)<br /> bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334)<br /> bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593)<br /> dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887)<br /> __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838)<br /> ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136)<br /> ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219)<br /> ip6_output (net/ipv6/ip6_output.c:250)<br /> ip6_send_skb (net/ipv6/ip6_output.c:1985)<br /> udp_v6_send_skb (net/ipv6/udp.c:1442)<br /> udpv6_sendmsg (net/ipv6/udp.c:1733)<br /> __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206)<br /> __x64_sys_sendto (net/socket.c:2209)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> <br /> Allocated by task 147:<br /> <br /> Freed by task 147:<br /> <br /> The buggy address belongs to the object at ffff888100ef8c80<br /> which belongs to the cache skbuff_head_cache of size 224<br /> The buggy address is located 192 bytes inside of<br /> freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)<br /> <br /> Memory state around the buggy address:<br /> ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> &gt;ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> ^<br /> ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb<br /> ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ==================================================================