https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 09 Nov 2026 17:52:25 +0000 https://db.gcve.eu/vuln/certfr-2026-avi-1473 certfr-2026-avi-1473 https://db.gcve.eu/vuln/certfr-2026-avi-1473 https://db.gcve.eu/vuln/fkie_cve-2026-99211 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netlink: reset skb headers before unicast and multicast filtering</p> <p>Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb&#39;s network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket&#39;s filter to read data before the initialized message.</p> <p>For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast().</p> <p>Reset both headers before running the receiver&#39;s filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netlink: reset skb headers before unicast and multicast filtering</p> <p>Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb&#39;s network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket&#39;s filter to read data before the initialized message.</p> <p>For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast().</p> <p>Reset both headers before running the receiver&#39;s filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code.</p> https://db.gcve.eu/vuln/fkie_cve-2026-99211 https://db.gcve.eu/vuln/ghsa-rx9x-87v5-hrch <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netlink: reset skb headers before unicast and multicast filtering</p> <p>Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb&#39;s network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket&#39;s filter to read data before the initialized message.</p> <p>For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast().</p> <p>Reset both headers before running the receiver&#39;s filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netlink: reset skb headers before unicast and multicast filtering</p> <p>Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb&#39;s network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket&#39;s filter to read data before the initialized message.</p> <p>For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast().</p> <p>Reset both headers before running the receiver&#39;s filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code.</p> https://db.gcve.eu/vuln/ghsa-rx9x-87v5-hrch https://db.gcve.eu/vuln/msrc_cve-2026-99211 msrc_CVE-2026-99211 https://db.gcve.eu/vuln/msrc_cve-2026-99211 https://db.gcve.eu/vuln/ubuntu-cve-2026-99211 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 257 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: netlink: reset skb headers before unicast and multicast filtering Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb&#39;s network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket&#39;s filter to read data before the initialized message. For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast(). Reset both headers before running the receiver&#39;s filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 257 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: netlink: reset skb headers before unicast and multicast filtering Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb&#39;s network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket&#39;s filter to read data before the initialized message. For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast(). Reset both headers before running the receiver&#39;s filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-99211 https://db.gcve.eu/vuln/wid-sec-w-2026-4224 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.</p> https://db.gcve.eu/vuln/wid-sec-w-2026-4224