Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

EFFECT DMX modes read beyond short Art-Net/E1.31 packets

Open Beginner friendly
  • Is something wrong?
#5,940 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
embedded-iot

Research direction

Start in wled00/e131.cpp at handleDMXData() and compare the effect modes with the neighboring modes that check availDMXLen. Trace how dmxChannels and dataOffset determine the available channel range, including for segment modes. The fix is done when each effect mode ignores packets missing any required channels and the short packet case no longer reaches out-of-bounds reads.

Written by the indexing model from the issue text.

Description

bug
What happened?

In wled00/e131.cpp, handleDMXData() reads fixed channel offsets in DMX_MODE_EFFECT, DMX_MODE_EFFECT_W, and their segment variants. These modes require 15 or 18 channels, but use this check before reading them:

if (dataOffset > dmxChannels - dmxEffectChannels + 1) return;

dmxEffectChannels is unsigned. If dmxChannels is below 14 or 17 respectively, the subtraction wraps, so a short packet passes the check. The later reads reach e131_data[dataOffset+14] or +17. The upstream Art-Net/E1.31 code clamps dmxChannels to the received packet length, but e131_data still points into that packet, not a full-size DMX buffer. In segment modes, dataOffset grows for each segment, so later reads can go farther beyond the packet. Other DMX modes use availDMXLen checks instead.

This is an out-of-bounds read. Out-of-range bytes can affect segment state and LED output, and a fault is possible. This path does not automatically rebroadcast those bytes over UDP; a practical information leak has not been demonstrated. There is no out-of-bounds write shown here. The included ASan reproducer is standalone, not a hardware test.

To Reproduce Bug
  1. Select an EFFECT DMX mode (the default DMX_MODE_MULTIPLE_RGB is not affected), set the DMX start address to 1, configure its universe, and use unicast receive mode.
  2. Send an Art-Net OpDmx packet to WLED's configured e131Port (default 5568, even for Art-Net), with art_universe == e131Universe and fewer channel bytes than the mode requires. For example, send a 20-byte packet with art_length = 2 and two DMX bytes. A short E1.31 packet can reach the same code.
  3. The short length passes the check above and handleDMXData() reads missing channel bytes. This path is confirmed from source; device behavior has not been tested.
Expected Behavior

WLED should ignore effect data unless all 15 or 18 required channels are present at the selected offset. Check the available channel count before the subtraction.

Install Method

Binary from WLED.me

What version of WLED?

The code is present in source revisions 296eec3 and fce41f2.

Which microcontroller/board are you seeing the problem on?

ESP8266

Relevant log/trace output
Anything else?

No response

Code of Conduct
  • I agree to follow this project's Code of Conduct
Dominant language
C++
Stars
18.8k
Forks
4.4k
Avg merge
2d 19h
Merged PRs (30d)
16

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from wled/WLED

All issues in wled/WLED

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.