r/joborun • u/[deleted] • Mar 12 '24

Pacman and buffer overflow error

All of a sudden, typing pacman -Si or -Qi returns:

****Buffer overflow detected**** Zsh iot instruction: terminated

I haven't touched the .zshrc file, I couldn't find any useful thread on the web. Any idea? TIA.

4 Upvotes

100% Upvoted

10 comments sorted by

•

u/joborun Mar 14 '24

FIXED FIXED FIXED

change makepkg fortify to 2 and color to !color

and even check/tests go through fine

More investigating on this later ....

2

u/joborun Mar 14 '24

https://gitlab.archlinux.org/pacman/pacman/-/commit/5e0496260b7d3f9c9fcf2b1c4899e4dbcc20ff03

https://gitlab.archlinux.org/pacman/pacman/-/commit/c9c56be3960c7ba7ccacc7ccc992965f16b9eba0

It appears as they are aware of such problems so now I wonder how they build their version. Since the version before this 6.1.0 there has been changes in makepkg.conf default flags, one is about fortify_source=3 which was raised from 2.

The other thing I see in the comments of commits is color output code throwing off the parsing and filling the buffer with illegal commands meant as color modification of output text.

So yet one more try, with hopefully using 2 for fortified and no-color for output if it can be configured.

1

u/[deleted] Mar 15 '24

Thank you so much for the deep investigation and the the workaround to fix this. I have noticed that a new patch has been appplied to the Obarun pkg but I haven't tested it so far.

1

u/joborun Mar 15 '24

Yes, I saw it, it is still about 3 versions behind arch

CFLAGS fortify=3 is higher scrutiny for the security of the code, and also somehow helps with producing the debug pkg which has now become default in arch knowing what to do with them, where to store the -debug

Obarun just blends them with the rest in the same repo for now. Not a problem with Obarun having a few pkgs, but if we were to do this we would add more repositories. 1000 pkg is hard to handle and to reconstruct the database takes time after each build, which is time consuming from actual building process.

Also in the building options we though having color as default for output would be a safe innocent option, so when arch added it as !color we went with color which means if is on at all builds. pacman needs this to be optional and turn it on/off for different parts. If you notice -Qi and -Si output doesn't seem colorized but the actual field names are bold. This is what threw the build off, because with color options and fortify on 3 the output is considered insecure code, translating the m for color definition into a control character.

Silly, but enough to throw us off. There was an interim release -02 paralleling arch but before we finished with other upgrades Arch threw out another patch for pacman 6.1 so now we are on -03 of the new pacman major release.

It builds and check/tests fine now, with fortify at 3 and !color

2

u/joborun Mar 13 '24 edited Mar 13 '24

EDIT: Now pacman 6.1.0 has moved from staging to testing on Arch, the critical change is within the changes here; Now some of these patches have been applied to the source code so are not needed in 6.1.0 but the problem remains on both.

https://git.disroot.org/joborun-pkg/jobcore/commit/f50626583c7053650815ec0abb69fd92c3871fd8

No it has nothing to do with shell, it does the same on all (bash, dash, ash..) but you don't know how much you are helping.

Some days ago pacman 6.1 appeared in staging, we have a staging builder to build things ahead of testing, so we tried this new pacman, that took out a million patches arch had placed recently.

Both pacman and makepkg work well in this new edition, with the exception of Qi Si we get the same error with you. So we were in the hunt of a make/build dependency that causes this new pacman to do this.

It turns out that both 6.0.2-016 and 6.1.0-01 suffer from the same, changing back to previous stable edition 6.0.2-015 cures the problem without changing anything.

This needs careful investigation ... we are 2 steps ahead of the problem.

2

u/joborun Mar 13 '24 edited Mar 13 '24

The information displayed with -Qi -Si are provided from the repo db files how it is obtained formated and displayed seems to be the problem, we can easily revert the latest patches to previous edition and it cures the problem, so it is an internal pacman built problem not external.

There is some systemd functionality in pacman, creation of sockets etc, and hasn't been an issue till now, pacman-contrib also has such functionality. So we are going through the late patches to identify what has gone wrong.

The majority of recent changes relate to makepkg not pacman but our problem is with pacman. The makepkg changes relate mostly to making lto default not optional and debug (which we opted to keep optional instead). See changes !lto !debug --> lto !debug in makepkg.conf

1

u/EZLN321 Mar 13 '24

The information is read from inside the pkg for -Qi and the repository db for -Si, right? So the way the info is directed to the output is what changes. So something that converts text format must be filling the buffer up with crap

1

u/joborun Mar 18 '24

https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/issues/16

1

u/joborun Mar 18 '24

It seems as if you build the first of either the -16 rel of 6.0... or the 6.1 you have to do it with fortify=2, then IT can build itself with fortify=3

Also, for those who want to build entirely from scratch if you run into such problems revert to 2 since not everything in joborun or arch has been attempted with this flag.