Recent changes to bugs

Buffer overflow

2023-09-09T07:15:27.382000Z

There is an old crashing bug which I've been ignoring for ten years or so but finally got around to patching. It's easy to reproduce. Start nedit, select "Execute command line" from the "Shell" menu and click "OK". As I recall, doing that was always fatal for my i686-pc-linux-gnu builds on Gentoo/Linux. The problem is detected thanks to the stack smashing protector. It's caused (in part) by a bogus line number. Please see attached patch. The patch is not a complete solution but it does prevent the crash by use of a little defensive programming.

#692 Can't enter numbers on numeric keypad

2023-04-30T08:02:01.700000Z

It turns out that this was fixed in a newer version of xnedit and that fix also works for nedit. I still think the underlying issue is in libXt but this fix works and that's what matters.

The attached patch fixes the issue for nedit. The suggestions I made in my initial bug report should be ignored.

Credit goes to Olaf Wintermann for the fix in xnedit that this patch is based on.

#692 Can't enter numbers on numeric keypad

2023-04-28T10:49:56.946000Z

Related: Link to xnedit bug report

Can't enter numbers on numeric keypad

2023-04-28T10:46:50.865000Z

On some platforms the numeric keypad is stuck in navigation mode (irrespective
of the NumLock state)[1]. I believe I've isolated the source of the problem
to libXt, specifically when it is compiled with Xkb support[2].

I've submitted a bug report to libXt but there are a few ways to work around
or fix this issue in nedit[3]:

1) Work-around: Run nedit using XKB_DISABLE=1 nedit

2) Temporary fix: Edit nedit.c and insert the following line immediately
before the TheDisplay = XtOpenDisplay(...) call:

putenv("XKB_DISABLE=1");

Note that either of these effectively disables Xkb support so may have
knock-on effects.

3) Proper fix: Correct the issue in libXt (assuming the problem actually lies
there). This is outside the scope of this bug report.

Links to related bug reports:

libXt
xnedit TBD
nedit Debian

[1] Except for the 5 key which does follow NumLock. This was first observed
by myself on Ubuntu 22.04 (jammy).

[2] The problem seems to lie in libXt’s XtTranslateKey(...) function (in
src/TMkey.c). When compiled with Xkb support this simply makes a call to
XkbLookupKeySym(...) and does no further processing. I believe that what it
should be doing is then processing the returned “list of modifiers that should
still be applied” (per the XkbLookupKeySym(3) manpage).

[3] There are suggestions that running setxkbmap -option numpad:mac will
fix the problem however I found that this works only occasionally, temporarily,
and inconsistently.

#691 Detect strange newlines in certain files

2022-08-20T18:15:18.908000Z

This is the file that has the issue. It's a log generated by mplayer which uses 0x0a to separate normal lines and 0x0d when it outputs the audio and video frames to terminal, so the lines don't advance.

#691 Detect strange newlines in certain files

2022-08-20T18:14:45.120000Z

#691 Detect strange newlines in certain files

2022-08-19T00:33:33.654000Z

md5
1eb6e4723671a653bb6546434b8f4f0e weird-newline.txt

Detect strange newlines in certain files

2022-08-19T00:31:27.491000Z

Certain files have specific newline which some text editors detect properly while other not. Check the file let me know what you think.

#690 potential buffer overflow in server_common.c

2021-08-19T03:26:44.110000Z

Hello kangwoosukeq!

So two things.

You are absolutely correct, this is definitely a buffer overflow.
NEdit 5.x is now considered to be "legacy" and has no planned active development going forward. The good news is that NEdit-NG https://github.com/eteran/nedit-ng/ is going to be officially considered NEdit 6.0 at some point (hopefully soon, but it's subject to the amount of time I can dedicate to it and for the past several months, I have just been absolutely swamped).

NG is is in a very workable state and is only held up from being christened "6.0" by a select few currently outstanding regressions from the 5.x series. (https://github.com/eteran/nedit-ng/milestone/1)

potential buffer overflow in server_common.c

2021-08-17T16:55:14.446000Z

Hi, there is a potential buffer overflow vulnerability in nedit-5.7.

These code examples show the vulnerable line in source/server_common.c.

63 sprintf(propName, "NEDIT_SERVER_EXISTS_%s_%s_%s", hostName, userName, serverName);
65 sprintf(propName, "NEDIT_SERVER_REQUEST_%s_%s_%s", hostName, userName, serverName);
94 sprintf(propName, "NEDIT_FILE_%s_%s_%s_%s_WF_OPEN", hostName, userName, serverName, path);
108 sprintf(propName, "NEDIT_FILE_%s_%s_%s_%s_WF_CLOSED", hostName, userName, serverName, path);
122 int length = sprintf(propNamePrefix, "NEDIT_FILE_%s_%s_%s_", hostName, userName, serverName);

A malicious attack can make 'userName' to arbitrary large string by manipulating environment variable.

const char *userName = GetUserName();

util/utils.c:143 return getenv("USER");

Since the size of propName and propNamePrefix are fixed, it can cause stack buffer overflow, which leads to buggy behavior.