https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 07 Nov 2026 03:19:16 +0000 https://db.gcve.eu/vuln/certfr-2026-avi-1375 certfr-2026-avi-1375 https://db.gcve.eu/vuln/certfr-2026-avi-1375 https://db.gcve.eu/vuln/fkie_cve-2026-98482 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()</p> <p>nfc_llcp_recv_hdlc() reads the sequence byte skb-&gt;data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control.</p> <p>Guard the read with pskb_may_pull(), as commit 95674f506c63 (&#34;nfc: llcp: reject PDUs shorter than the LLCP header&#34;) did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()</p> <p>nfc_llcp_recv_hdlc() reads the sequence byte skb-&gt;data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control.</p> <p>Guard the read with pskb_may_pull(), as commit 95674f506c63 (&#34;nfc: llcp: reject PDUs shorter than the LLCP header&#34;) did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply.</p> https://db.gcve.eu/vuln/fkie_cve-2026-98482 https://db.gcve.eu/vuln/ghsa-8vvq-jjhc-wfc4 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()</p> <p>nfc_llcp_recv_hdlc() reads the sequence byte skb-&gt;data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control.</p> <p>Guard the read with pskb_may_pull(), as commit 95674f506c63 (&#34;nfc: llcp: reject PDUs shorter than the LLCP header&#34;) did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc()</p> <p>nfc_llcp_recv_hdlc() reads the sequence byte skb-&gt;data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control.</p> <p>Guard the read with pskb_may_pull(), as commit 95674f506c63 (&#34;nfc: llcp: reject PDUs shorter than the LLCP header&#34;) did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply.</p> https://db.gcve.eu/vuln/ghsa-8vvq-jjhc-wfc4 https://db.gcve.eu/vuln/msrc_cve-2026-98482 msrc_CVE-2026-98482 https://db.gcve.eu/vuln/msrc_cve-2026-98482 https://db.gcve.eu/vuln/suse-su-2026:24550-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://db.gcve.eu/vuln/suse-su-2026:24550-1 https://db.gcve.eu/vuln/ubuntu-cve-2026-98482 <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 248 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc() nfc_llcp_recv_hdlc() reads the sequence byte skb-&gt;data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control. Guard the read with pskb_may_pull(), as commit 95674f506c63 (&#34;nfc: llcp: reject PDUs shorter than the LLCP header&#34;) did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply.</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 248 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: drop truncated I/RR/RNR PDUs in nfc_llcp_recv_hdlc() nfc_llcp_recv_hdlc() reads the sequence byte skb-&gt;data[2], via nfc_llcp_ns()/nfc_llcp_nr(), before any length check. The receive path only guarantees the two-byte LLCP header -- __nfc_llcp_recv() checks it with pskb_may_pull() and nfc_llcp_recv_agf() admits two-byte inner PDUs -- so a two-byte I, RR or RNR PDU reads one byte of uninitialised skb tailroom. The byte becomes N(R)/N(S); a peer can already set those with a well-formed PDU, so this is acting on uninitialised memory, not new peer control. Guard the read with pskb_may_pull(), as commit 95674f506c63 (&#34;nfc: llcp: reject PDUs shorter than the LLCP header&#34;) did for the two-byte header, so the sequence byte is present and linear before it is read. RR and RNR PDUs are LLCP_HEADER_SIZE + LLCP_SEQUENCE_SIZE bytes and an I PDU is longer, so no valid frame is rejected; a truncated PDU is malformed, so return without a DM reply.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-98482