Vulnerabilities

Before Airflow 3.2.0, it was unclear that secure Airflow deployments require the Deployment Manager to take appropriate actions and pay attention to security details and security model of Airflow. Some assumptions the Deployment Manager could make were not clear or explicit enough, even though Airflow&amp;#39;s intentions and security model of Airflow did not suggest different assumptions. The overall security model [1], workload isolation [2], and JWT authentication details [3] are now described in more detail. Users concerned with role isolation and following the Airflow security model of Airflow are advised to upgrade to Airflow 3.2, where several security improvements have been implemented. They should also read and follow the relevant documents to make sure that their deployment is secure enough. It also clarifies that the Deployment Manager is ultimately responsible for securing your Airflow deployment. This had also been communicated via Airflow 3.2.0 Blog announcement [4].<br /> <br /> [1] Security Model: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html <br /> [2] Workload isolation: https://airflow.apache.org/docs/apache-airflow/stable/security/workload.html <br /> [3] JWT Token authentication: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html <br /> [4] Airflow 3.2.0 Blog announcement: https://airflow.apache.org/blog/airflow-3.2.0/ <br /> <br /> <br /> <br /> Users are recommended to upgrade to version 3.2.0, which fixes this issue.

Sourcecodester Computer and Mobile Repair Shop Management System v1.0 is vulnerable to SQL Injection in the file /rsms/admin/services/view_service.php.

Sourcecodester Computer and Mobile Repair Shop Management System v1.0 is vulnerable to SQL injection in the file /rsms/admin/inquiries/view_details.php.

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 /> 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 /> 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 /> ==================================================================

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 /> 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()`.