Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

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

vxlan: require CAP_NET_ADMIN in the device netns for changelink

A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net.

vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here.

Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series.

Found by 0sec automated security-research tooling (https://0sec.ai).

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

vxlan: require CAP_NET_ADMIN in the device netns for changelink

A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net.

vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here.

Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series.

Found by 0sec automated security-research tooling (https://0sec.ai).

Security update for the Linux Kernel

kernel: nvme-pci: fix mempool alloc size kernel: Linux kernel: Denial of Service in RDMA/bnxt_re driver due to race condition during QP destruction kernel: Linux kernel: Use-after-free in xc5000 tuner driver due to race condition kernel: gfs2: Fix unlikely race in gdlm_put_lock kernel: Linux kernel: Denial of Service in QFQ scheduler via child qlen manipulation kernel: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send kernel: gfs2: Fix slab-use-after-free in qd_put kernel: net/sched: act_ct: Only release RCU read lock after ct_ft kernel: crypto: af_alg - Cap AEAD AD length to 0x80000000 kernel: gfs2: add some missing log locking kernel: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list kernel: ipvs: clear the svc scheduler ptr early on edit kernel: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path kernel: net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink kernel: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() kernel: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() kernel: vxlan: require CAP_NET_ADMIN in the device netns for changelink kernel: net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink kernel: netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst kernel: KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is active kernel: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_…

Security update for the Linux Kernel

Affected: Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more

In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai).