Threat database

In the Linux kernel, the following vulnerability has been resolved: fbdev: of: display_timing: fix refcount leak in of_get_display_timings() of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup.

In the Linux kernel, the following vulnerability has been resolved: md-cluster: fix NULL pointer dereference in process_metadata_update The function process_metadata_update() blindly dereferences the 'thread' pointer (acquired via rcu_dereference_protected) within the wait_event() macro. While the code comment states "daemon thread must exist", there is a valid race condition window during the MD array startup sequence (md_run): 1. bitmap_load() is called, which invokes md_cluster_ops->join(). 2. join() starts the "cluster_recv" thread (recv_daemon). 3. At this point, recv_daemon is active and processing messages. 4. However, mddev->thread (the main MD thread) is not initialized until later in md_run(). If a METADATA_UPDATED message is received from a remote node during this specific window, process_metadata_update() will be called while mddev->thread is still NULL, leading to a kernel panic. To fix this, we must validate the 'thread' pointer. If it is NULL, we release the held lock (no_new_dev_lockres) and return early, safely ignoring the update request as the array is not yet fully ready to process it.

In the Linux kernel, the following vulnerability has been resolved: io_uring/zcrx: fix sgtable leak on mapping failures In an unlikely case when io_populate_area_dma() fails, which could only happen on a PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA machine, io_zcrx_map_area() will have an initialised and not freed table. It was supposed to be cleaned up in the error path, but !is_mapped prevents that.

In the Linux kernel, the following vulnerability has been resolved: net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak __radix_tree_create() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radix_tree_for_each_slot() only visits slots containing leaf values. The radix_tree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead of fixing the radix_tree itself [1]. xarray properly handles cleanup of internal nodes — xa_destroy() frees all internal xarray nodes when the qrtr_node is released, preventing the leak. [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/

In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix memory leak on failure path cfg80211_inform_bss_frame() may return NULL on failure. In that case, the allocated buffer 'buf' is not freed and the function returns early, leading to potential memory leak. Fix this by ensuring that 'buf' is freed on both success and failure paths.

In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/sh_tmu: Always leave device running after probe The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe.

In the Linux kernel, the following vulnerability has been resolved: crypto: af-alg - fix NULL pointer dereference in scatterwalk The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL) when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent sendmsg() allocates a new SGL and chains it, but fails to clear the end marker on the previous SGL's last data entry. This causes the crypto scatterwalk to hit a premature end, returning NULL on sg_next() and leading to a kernel panic during dereference. Fix this by explicitly unmarking the end of the previous SGL when performing sg_chain() in af_alg_alloc_tsgl().

In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix URB leak in pvr2_send_request_ex When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.

In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: fix state inconsistency on gadget init failure When cdns3_gadget_start() fails, the DRD hardware is left in gadget mode while software state remains INACTIVE, creating hardware/software state inconsistency. When switching to host mode via sysfs: echo host > /sys/class/usb_role/13180000.usb-role-switch/role The role state is not set to CDNS_ROLE_STATE_ACTIVE due to the error, so cdns_role_stop() skips cleanup because state is still INACTIVE. This violates the DRD controller design specification (Figure22), which requires returning to idle state before switching roles. This leads to a synchronous external abort in xhci_gen_setup() when setting up the host controller: [ 516.440698] configfs-gadget 13180000.usb: failed to start g1: -19 [ 516.442035] cdns-usb3 13180000.usb: Failed to add gadget [ 516.443278] cdns-usb3 13180000.usb: set role 2 has failed ... [ 1301.375722] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 1301.377716] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 1301.382485] pc : xhci_gen_setup+0xa4/0x408 [ 1301.393391] backtrace: ... xhci_gen_setup+0xa4/0x408 <-- CRASH xhci_plat_setup+0x44/0x58 usb_add_hcd+0x284/0x678 ... cdns_role_set+0x9c/0xbc <-- Role switch Fix by calling cdns_drd_gadget_off() in the error path to properly clean up the DRD gadget state.

In the Linux kernel, the following vulnerability has been resolved: NFC: pn533: bound the UART receive buffer pn532_receive_buf() appends every incoming byte to dev->recv_skb and only resets the buffer after pn532_uart_rx_is_frame() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skb_put_u8() hits the tail limit. Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532_UART_SKB_BUFF_LEN.

In the Linux kernel, the following vulnerability has been resolved: auxdisplay: line-display: fix NULL dereference in linedisp_release linedisp_release() currently retrieves the enclosing struct linedisp via to_linedisp(). That lookup depends on the attachment list, but the attachment may already have been removed before put_device() invokes the release callback. This can happen in linedisp_unregister(), and can also be reached from some linedisp_register() error paths. In that case, to_linedisp() returns NULL and linedisp_release() dereferences it while freeing the display resources. The struct device released here is the embedded linedisp->dev used by linedisp_register(), so retrieve the enclosing object directly with container_of() instead.

In Progress® Telerik® UI for WinUI versions prior to 2025 Q1 (3.0.0), a command injection attack is possible through improper neutralization of hyperlink elements.

electerm is an open-sourced terminal/ssh/sftp/telnet/serialport/RDP/VNC/Spice/ftp client. In versions 3.8.15 and prior, Electerm's terminal hyperlink handler passes any URL clicked in the terminal directly to shell.openExternal without any protocol validation. An attacker who controls terminal output (e.g., via a malicious SSH server, compromised remote host, or malicious plugin rendering terminal content) can thus achieve arbitrary code execution or local file access on the victim's machine, requiring only that the victim clicks a displayed link. At time of publication, there are no publicly available patches.

Kimai is an open-source time tracking application. Prior to version 2.54.0, the Team API endpoints use #[IsGranted('edit_team')] instead of #[IsGranted('edit', 'team')], causing Symfony TeamVoter to abstain from voting. This removes entity-level ownership checks on team operations, allowing any user with the edit_team permission to modify any team, not just teams they are authorized to manage. This issue has been patched in version 2.54.0.

locize is a localization platform that connects code and i18n setup. Prior to version 4.0.21, the locize client SDK registers a window.addEventListener("message", …) handler that dispatches to registered internal handlers (editKey, commitKey, commitKeys, isLocizeEnabled, requestInitialize, …) without validating event.origin. The pre-patch listener in src/api/postMessage.js gates dispatch on event.data.sender === "i18next-editor-frame" — that value sits inside the attacker-controlled message payload, not the browser-enforced origin. Any web page that could embed or be embedded by a locize-enabled host — an iframe on a third-party page, a window.open-ed victim, a parent frame reaching down — could send a crafted postMessage and trigger the internal handlers. This issue has been patched in version 4.0.21.

MapServer is a system for developing web-based GIS applications. From version 6.0 to before version 8.6.2, a reflected XSS vulnerability in MapServer's WMS server allows an unauthenticated attacker to inject arbitrary HTML/JavaScript into the browser of any user who opens a crafted WMS URL. The vulnerability is triggered via FORMAT=application/openlayers combined with an unsanitized SRS parameter in WMS 1.3.0 requests. This issue has been patched in version 8.6.2.

### Summary Remote Denial of Service (DoS) via Nil Pointer Dereference in BGP Update Processing An unauthenticated remote BGP peer can trigger a fatal panic in GoBGP by sending a specially crafted BGP UPDATE message. When the server receives a message with inconsistent attribute lengths, it improperly handles the internal state transition to a "withdraw" action, leading to a nil pointer dereference in the AdjRib.Update function. This causes the entire GoBGP process to crash, resulting in a complete loss of service availability. ### Details The vulnerability originates in the interaction between the BGP message decoding logic and the Adj-RIB table management. Triggering Condition: When a BGP UPDATE message contains attributes that fail validation (e.g., "attribute value length is short"), GoBGP logs a warning: the received Update message was treated as withdraw. Code Path: The message reaches github.com/osrg/gobgp/v4/pkg/server.(*peer).handleUpdate. Due to the malformed attributes, the message is processed as a withdrawal, but the internal representation of the path or its attributes becomes nil. The execution flows to internal/pkg/table/adj.go:127 within (*AdjRib).Update. The Flaw: At line 127 in adj.go, the code attempts to access a member of a structure (likely the path or a specific attribute container) that is nil due to the previous validation failure. Log Snippet: ``` {"time":"2026-04-21T12:43:10.009107962+08:00","level":"WARN","msg":"the received Update message was treated as withdraw","Topic":"Peer","Key":"192.168.31.195","State":"BGP_FSM_ESTABLISHED","Error":"attribute value length is short"} panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xbca9e8] goroutine 52 [running]: github.com/osrg/gobgp/v4/internal/pkg/table.(*AdjRib).Update(0x1fec929b4480, {0x1fec928ca0e8, 0x1, 0xfffffffffffffffc?}) /home/base/Desktop/gobgp/internal/pkg/table/adj.go:127 +0xa8 github.com/osrg/gobgp/v4/pkg/server.(*peer).handleUpdate(0x1fec92b90c40, 0x1fec92c0c900) /home/base/Desktop/gobgp/pkg/server/peer.go:656 +0xed4 github.com/osrg/gobgp/v4/pkg/server.(*BgpServer).handleFSMMessage(0x1fec928c8488, 0x1fec92b90c40, 0x1fec92c0c900) /home/base/Desktop/gobgp/pkg/server/server.go:1670 +0x14c6 github.com/osrg/gobgp/v4/pkg/server.(*BgpServer).startFsmHandler.func1(0x1fec935c0b00?) /home/base/Desktop/gobgp/pkg/server/server.go:253 +0x25 github.com/osrg/gobgp/v4/pkg/server.(*fsmHandler).recvMessageloop(0x1fec92acee40, {0x105c750, 0x1fec92970500}, {0x106a558, 0x1fec933bc000}, 0x1fec92c1a2a0, 0x1fec92c18a10, 0x0?) /home/base/Desktop/gobgp/pkg/server/fsm.go:1893 +0xe82 created by github.com/osrg/gobgp/v4/pkg/server.(*fsmHandler).established in goroutine 37 /home/base/Desktop/gobgp/pkg/server/fsm.go:1920 +0x2d5 ``` ### PoC ``` [SEND] OPEN Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 1d 01 04 fd ea 00 5a c3 a8 1f c3 00 [RECV] Type: 1 | Length: 77 Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 4d 01 04 fd e9 00 5a c0 a8 1f 82 30 02 2e 02 00 49 16 14 62 61 73 65 2d 76 69 72 74 75 61 6c 2d 6d 61 63 68 69 6e 65 00 01 04 00 19 00 46 41 04 00 00 fd e9 05 06 00 19 00 46 00 02 [+] Received OPEN from peer [SEND] KEEPALIVE Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 13 04 [RECV] Type: 4 | Length: 19 Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 13 04 [+] BGP Session Established [SEND] Crafted UPDATE Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 50 02 00 04 18 ac 10 01 00 35 35 01 01 04 2d 02 00 90 0e 00 19 3e 01 a8 c0 1f 82 00 02 21 00 01 c0 a8 1f 12 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 11 22 33 44 55 0f 11 80 00 [*] Waiting for peer reaction... [+] Done. ``` ### Impact Remote Denial of Service (DoS) in GoBGP v4.4.0

### Impact A server-side request forgery (SSRF) vulnerability in monetr's Lunch Flow integration allowed any authenticated user on a self-hosted instance to cause the monetr server to issue HTTP GET requests to arbitrary URLs supplied by the caller, with the response body from non-200 upstream responses reflected back in the API error message. The URL validator on `POST /api/lunch_flow/link` only checked the URL scheme and rejected query parameters; it did not filter loopback, RFC1918, link-local, or cloud-provider metadata addresses. The outbound HTTP client read the response body via an unbounded `io.ReadAll`, and the controller intentionally surfaced the resulting error (which contained the upstream body) as the JSON `error` field of the API response. **Who is affected:** self-hosted monetr deployments running the default configuration. Out of the box, `LunchFlow.Enabled=true`, `AllowSignUp=true`, and billing is not enforced, so any user who can register on the instance can reach the vulnerable endpoint. Deployments running in a cloud environment where instance metadata is reachable from the pod (e.g. AWS EC2 without IMDSv2 enforced) expand the impact to include potential exposure of instance metadata through the reflected error body. **Who is NOT affected:** the hosted `my.monetr.app` service, which runs with `LunchFlow.Enabled=false`. Self-hosted operators who had already disabled public sign-up (`MONETR_ALLOW_SIGN_UP=false`) substantially reduce their exposure since only operator-trusted users can reach the endpoint. A secondary denial-of-service vector also existed: because the outbound response body was read with no size cap, an attacker-influenced upstream could return a multi-GB body that monetr would fully buffer into memory. ### Patches Fixed in monetr `v1.12.5`. Users should upgrade to this release or later. The fix introduces a new config field `LunchFlow.AllowedApiUrls` (a list of permitted Lunch Flow API URLs) with a default of `["https://lunchflow.app/api/v1"]`. URLs outside the allowlist are rejected both at link-creation time and at client-construction time, with a server-side warning log on rejection. Response body reads are capped at 10 MiB for both success and error paths. The UI renders the API URL field as a disabled pre-filled input when a single URL is allowed, or a dropdown when multiple are allowed, so operators who need to use a staging or self-hosted Lunch Flow API opt in explicitly via config. **Upgrade note for self-hosters with a custom Lunch Flow URL:** if your existing `LunchFlowLink` records point at a URL other than `https://lunchflow.app/api/v1`, set your `lunchFlow.allowedApiUrls` in your yaml config to include your custom URL before upgrading. Otherwise existing links will fail on next refresh or sync with a `"Rejected Lunch Flow API URL that is not in the configured allowlist"` warning in the server log. ### Workarounds For operators who cannot upgrade immediately, any of the following materially reduces or eliminates exposure: - **Disable public sign-up:** set `MONETR_ALLOW_SIGN_UP=false` so only operator-trusted users can reach the vulnerable endpoint. Recommended in general for internet-exposed self-hosted deployments. - **Disable Lunch Flow entirely:** set `lunchFlow.enabled: false` in your config file. The endpoints will return 404 for all callers. - **Network-level egress restriction:** restrict outbound HTTP egress from the monetr pod/container to only `lunchflow.app` (or whichever legitimate Lunch Flow hosts you use). Blocks the SSRF primitive regardless of application-layer validation. - **On AWS EC2 specifically:** enforce IMDSv2 on the instance. This eliminates the cloud-metadata exfil path even if the SSRF primitive remains reachable.

### Summary A remote Denial of Service (DoS) vulnerability exists in GoBGP where a malformed BGP UPDATE message can trigger a runtime error: index out of range panic. This occurs during the processing of 4-byte AS attributes when the message structure causes an internal slice index shift that is not properly handled. ### Details The vulnerability is located in internal/pkg/table/message.go within the UpdatePathAttrs4ByteAs function. When GoBGP processes a BGP UPDATE message containing both an AS_PATH and an AS4_PATH attribute, it attempts to merge or validate them to support 4-byte AS numbers. If the attributes are ordered such that AS4_PATH (Type 17) appears before AS_PATH (Type 2), and the AS4_PATH is deemed invalid/malformed, the code attempts to remove the AS4_PATH attribute from the msg.PathAttributes slice. It appears the crash happens due to an index shift in msg.PathAttributes: ``` #GoBGP v4.2.0 // Line 112: If AS4_PATH precedes AS_PATH, the deletion causes all subsequent attributes to shift left. msg.PathAttributes = append(msg.PathAttributes[:as4AttrPos], msg.PathAttributes[as4AttrPos+1:]...) // Line 206: The stale asAttrPos index is used here. //The function continues to use the stale index (asAttrPos) to update the AS_PATH. Since the slice length has decreased, accessing the old index leads to a panic. msg.PathAttributes[asAttrPos] = bgp.NewPathAttributeAsPath(newIntfParams) ``` This deletion causes all subsequent attributes in the slice to shift left by one position. However, the function continues to use the original asAttrPos index (calculated before the deletion) to access or modify the AS_PATH attribute later at [Line 206](https://www.google.com/search?q=https://github.com/osrg/gobgp/blob/v4.2.0/internal/pkg/table/message.go%23L206). Because the slice is now shorter, the "stale" index points out of bounds, triggering a panic and crashing the entire GoBGP process. ### PoC Environment: * GoBGP version: 4.2.0 Configuration: Passive peering enabled. Reproduction Steps: Configure GoBGP with a neighbor (e.g., 192.168.31.195). Send a specially crafted BGP UPDATE hex payload: ``` ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 22 02 00 00 # Withdrawn Routes Length 00 0b # Total Path Attribute Length 40 11 01 02 # AS4_PATH (Type 17, Len 1, Val 02) - Triggers the bug 40 02 04 ff ff de ad # AS_PATH (Type 2, Len 4) ``` The GoBGP process will immediately crash with: panic: runtime error: index out of range [1] with length 1. ### Impact Vulnerability Type: Remote Denial of Service (DoS). Impacted Users: Any GoBGP deployment (v4.2.0 and earlier) that accepts BGP UPDATE messages from peers. Since this crash occurs in the FSM (Finite State Machine) handling loop, a single malicious peer or a malformed route propagated through a transit provider can consistently crash the BGP daemon, leading to a complete loss of routing capabilities.

### Summary A remote Denial of Service (DoS) vulnerability exists in GoBGP due to a nil pointer dereference. When a malformed BGP UPDATE message contains an unrecognized Path Attribute marked as "Well-known," the daemon fails to interrupt the message handling flow. This results in an illegal memory access and a full process crash (panic). ### Details The vulnerability is located in the Finite State Machine (FSM) message handling loop in pkg/server/fsm.go. According to RFC 4271, any Path Attribute with the Optional bit set to 0 is treated as "Well-known." If the Type Code is unrecognized, the BGP speaker MUST send a NOTIFICATION message. In GoBGP v4.3.0, when such an attribute (e.g., Type 0xEE or 0xFF with flags 0x40) is received, the parsing layer identifies the error. However, the logic in recvMessageloop (around Line 1826) does not properly halt execution. It proceeds to reference the body of the parsed message. Because the message was deemed invalid during the initial attribute check, the body pointer is nil, leading to: panic: runtime error: invalid memory address or nil pointer dereference. This bypasses the intended error-handling mechanism and causes the entire BGP daemon to terminate, rather than just closing the affected session. ``` panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xc225e4] goroutine 50 [running]: github.com/osrg/gobgp/v4/pkg/server.(*fsmHandler).recvMessageloop(0x19f29bca92c0, {0x10069f0, 0x19f29bc48780}, {0x1014658, 0x19f29bc2a890}, 0x19f29baa0540, 0x19f29bc393b0, 0x19f29bc96cc0?) /home/base/Desktop/gobgp/pkg/server/fsm.go:1826 +0xa44 created by github.com/osrg/gobgp/v4/pkg/server.(*fsmHandler).established in goroutine 37 /home/base/Desktop/gobgp/pkg/server/fsm.go:1916 +0x2d5 exit status 2 ``` ### PoC GoBGP Version: v4.3.0 Configure GoBGP with a neighbor (e.g., 192.168.31.195) in passive mode. Establish a standard BGP session (OPEN/KEEPALIVE exchange). Send a specifically crafted UPDATE packet containing an unrecognized Type Code marked as "Well-known" (Optional bit = 0). Payload 1 (Hex): ``` FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 17 # Length: 23 02 # Type: UPDATE 00 00 # Withdrawn Routes Length: 0 00 04 # Total Path Attribute Length: 4 40 EE 00 # Flag: 0x40 (Well-known, Transitive), Type: 0xEE (Unknown), Len: 0 ``` Payload 2 (Hex): ``` FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 17 # Length: 23 02 # Type: UPDATE 00 00 # Withdrawn Routes Length: 0 00 04 # Total Path Attribute Length: 4 40 01 01 00 # IGP Attribute 40 FF 00 # Flag: 0x40 (Well-known, Transitive), Type: 0xFF (Unknown), Len: 0 ``` ### Impact This vulnerability affects all GoBGP deployments peering with external or internal speakers. A single malformed UPDATE message from any peer can trigger a nil pointer dereference, causing the GoBGP daemon to panic and crash.