Yiqi Sun and Kevin Wang discovered that the cgroups implementation in the
Linux kernel did not properly restrict access to the cgroups v1
release_agent feature. A local attacker could use this to gain
administrative privileges. (CVE-2022-0492)

It was discovered that an out-of-bounds (OOB) memory access flaw existed in
the f2fs module of the Linux kernel. A local attacker could use this issue
to cause a denial of service (system crash). (CVE-2021-3506)

Brendan Dolan-Gavitt discovered that the Marvell WiFi-Ex USB device driver
in the Linux kernel did not properly handle some error conditions. A
physically proximate attacker could use this to cause a denial of service
(system crash). (CVE-2021-43976)

It was discovered that the ARM Trusted Execution Environment (TEE)
subsystem in the Linux kernel contained a race condition leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service or possibly execute arbitrary code. (CVE-2021-44733)

It was discovered that the Phone Network protocol (PhoNet) implementation
in the Linux kernel did not properly perform reference counting in some
error conditions. A local attacker could possibly use this to cause a
denial of service (memory exhaustion). (CVE-2021-45095)

Samuel Page discovered that the Transparent Inter-Process Communication
(TIPC) protocol implementation in the Linux kernel contained a stack-based
buffer overflow. A remote attacker could use this to cause a denial of
service (system crash) for systems that have a TIPC bearer configured.
(CVE-2022-0435)

Read More

Yiqi Sun and Kevin Wang discovered that the cgroups implementation in the
Linux kernel did not properly restrict access to the cgroups v1
release_agent feature. A local attacker could use this to gain
administrative privileges. (CVE-2022-0492)

Jürgen Groß discovered that the Xen subsystem within the Linux kernel did
not adequately limit the number of events driver domains (unprivileged PV
backends) could send to other guest VMs. An attacker in a driver domain
could use this to cause a denial of service in other guest VMs.
(CVE-2021-28711, CVE-2021-28712, CVE-2021-28713)

Jürgen Groß discovered that the Xen network backend driver in the Linux
kernel did not adequately limit the amount of queued packets when a guest
did not process them. An attacker in a guest VM can use this to cause a
denial of service (excessive kernel memory consumption) in the network
backend domain. (CVE-2021-28714, CVE-2021-28715)

It was discovered that the simulated networking device driver for the Linux
kernel did not properly initialize memory in certain situations. A local
attacker could use this to expose sensitive information (kernel memory).
(CVE-2021-4135)

Brendan Dolan-Gavitt discovered that the Marvell WiFi-Ex USB device driver
in the Linux kernel did not properly handle some error conditions. A
physically proximate attacker could use this to cause a denial of service
(system crash). (CVE-2021-43976)

It was discovered that the ARM Trusted Execution Environment (TEE)
subsystem in the Linux kernel contained a race condition leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service or possibly execute arbitrary code. (CVE-2021-44733)

It was discovered that the Phone Network protocol (PhoNet) implementation
in the Linux kernel did not properly perform reference counting in some
error conditions. A local attacker could possibly use this to cause a
denial of service (memory exhaustion). (CVE-2021-45095)

It was discovered that the Reliable Datagram Sockets (RDS) protocol
implementation in the Linux kernel did not properly deallocate memory in
some error conditions. A local attacker could possibly use this to cause a
denial of service (memory exhaustion). (CVE-2021-45480)

Samuel Page discovered that the Transparent Inter-Process Communication
(TIPC) protocol implementation in the Linux kernel contained a stack-based
buffer overflow. A remote attacker could use this to cause a denial of
service (system crash) for systems that have a TIPC bearer configured.
(CVE-2022-0435)

It was discovered that the KVM implementation for s390 systems in the Linux
kernel did not properly prevent memory operations on PVM guests that were
in non-protected mode. A local attacker could use this to obtain
unauthorized memory write access. (CVE-2022-0516)

Read More

It was discovered that the BPF verifier in the Linux kernel did not
properly restrict pointer types in certain situations. A local attacker
could use this to cause a denial of service (system crash) or possibly
execute arbitrary code. (CVE-2022-23222)

Yiqi Sun and Kevin Wang discovered that the cgroups implementation in the
Linux kernel did not properly restrict access to the cgroups v1
release_agent feature. A local attacker could use this to gain
administrative privileges. (CVE-2022-0492)

Jürgen Groß discovered that the Xen subsystem within the Linux kernel did
not adequately limit the number of events driver domains (unprivileged PV
backends) could send to other guest VMs. An attacker in a driver domain
could use this to cause a denial of service in other guest VMs.
(CVE-2021-28711, CVE-2021-28712, CVE-2021-28713)

Jürgen Groß discovered that the Xen network backend driver in the Linux
kernel did not adequately limit the amount of queued packets when a guest
did not process them. An attacker in a guest VM can use this to cause a
denial of service (excessive kernel memory consumption) in the network
backend domain. (CVE-2021-28714, CVE-2021-28715)

Szymon Heidrich discovered that the USB Gadget subsystem in the Linux
kernel did not properly restrict the size of control requests for certain
gadget types, leading to possible out of bounds reads or writes. A local
attacker could use this to cause a denial of service (system crash) or
possibly execute arbitrary code. (CVE-2021-39685)

It was discovered that a race condition existed in the poll implementation
in the Linux kernel, resulting in a use-after-free vulnerability. A local
attacker could use this to cause a denial of service (system crash) or
possibly execute arbitrary code. (CVE-2021-39698)

It was discovered that the simulated networking device driver for the Linux
kernel did not properly initialize memory in certain situations. A local
attacker could use this to expose sensitive information (kernel memory).
(CVE-2021-4135)

Eric Biederman discovered that the cgroup process migration implementation
in the Linux kernel did not perform permission checks correctly in some
situations. A local attacker could possibly use this to gain administrative
privileges. (CVE-2021-4197)

Brendan Dolan-Gavitt discovered that the aQuantia AQtion Ethernet device
driver in the Linux kernel did not properly validate meta-data coming from
the device. A local attacker who can control an emulated device can use
this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2021-43975)

It was discovered that the ARM Trusted Execution Environment (TEE)
subsystem in the Linux kernel contained a race condition leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service or possibly execute arbitrary code. (CVE-2021-44733)

It was discovered that the Phone Network protocol (PhoNet) implementation
in the Linux kernel did not properly perform reference counting in some
error conditions. A local attacker could possibly use this to cause a
denial of service (memory exhaustion). (CVE-2021-45095)

It was discovered that the eBPF verifier in the Linux kernel did not
properly perform bounds checking on mov32 operations. A local attacker
could use this to expose sensitive information (kernel pointer addresses).
(CVE-2021-45402)

It was discovered that the Reliable Datagram Sockets (RDS) protocol
implementation in the Linux kernel did not properly deallocate memory in
some error conditions. A local attacker could possibly use this to cause a
denial of service (memory exhaustion). (CVE-2021-45480)

It was discovered that the BPF subsystem in the Linux kernel did not
properly track pointer types on atomic fetch operations in some situations.
A local attacker could use this to expose sensitive information (kernel
pointer addresses). (CVE-2022-0264)

It was discovered that the TIPC Protocol implementation in the Linux kernel
did not properly initialize memory in some situations. A local attacker
could use this to expose sensitive information (kernel memory).
(CVE-2022-0382)

Samuel Page discovered that the Transparent Inter-Process Communication
(TIPC) protocol implementation in the Linux kernel contained a stack-based
buffer overflow. A remote attacker could use this to cause a denial of
service (system crash) for systems that have a TIPC bearer configured.
(CVE-2022-0435)

It was discovered that the KVM implementation for s390 systems in the Linux
kernel did not properly prevent memory operations on PVM guests that were
in non-protected mode. A local attacker could use this to obtain
unauthorized memory write access. (CVE-2022-0516)

It was discovered that the ICMPv6 implementation in the Linux kernel did
not properly deallocate memory in certain situations. A remote attacker
could possibly use this to cause a denial of service (memory exhaustion).
(CVE-2022-0742)

Read More

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Apple Safari. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

Read More

FEDORA-2022-47da296f2b

Packages in this update:

unrealircd-5.2.4-1.fc34

Update description:

UnrealIRCd 5.2.4

This release fixes a crash bug that can be triggered by ordinary users.

Fixes

Fix crash that can be triggered by regular users if you have any deny dcc blocks in the config or any spamfilters with the d (DCC) target.

Also important

UnrealIRCd 6 is the new “stable” (available for Fedora 35 and later)
UnrealIRCd 5.2.x (“oldstable”) receives upstream bug fixes only until July 1, 2022 (no more feature enhancements)

Read More

FEDORA-2022-a9349c1299

Packages in this update:

unrealircd-6.0.2-1.fc35

Update description:

UnrealIRCd 6.0.2

UnrealIRCd 6.0.2 comes with several nice feature enhancements along with some fixes. It also includes a fix for a crash bug that can be triggered by ordinary users.

Fixes

Fix crash that can be triggered by regular users if you have any deny dcc blocks in the config or any spamfilters with the d (DCC) target.
Fix infinite hang on “Loading IRCd configuration” if DNS is not working. For example if the 1st DNS server in /etc/resolv.conf is down or refusing requests.
Some MODE server-to-server commands were missing a timestamp at the end, even though this is mandatory for modes coming from a server.
The channeldb module now converts letter extbans to named extbans (e.g. ~a to ~account). Previously it did not, which caused letter extbans to appear in the banlist. Later on, when linking servers, this would cause duplicate entries to appear as well, with both the old and new format. The extbans were still effective though, so this is mostly a visual +b/+e/+I list issue.
Some Extended Server Bans were not working correctly for WEBIRC proxies. In particular, a server ban or exempt (ELINE) on ~country:XX was only checked against the WEBIRC proxy.

Enhancements

Support for logging to a channel. Similar to snomasks but then for channels.
Command line interface changes:
The CLI tool now communicates to the running UnrealIRCd process via a UNIX socket to send commands and retrieve output.
The command unrealircdctl rehash will now show the rehash output, including warnings and errors, and return a proper exit code.
The same for unrealircdctl reloadtls
The command unrealircdctl status to show if UnrealIRCd is running, the version, channel and user count, ..
The command unrealircdctl genlinkblock is now documented and is referred to from the Linking servers tutorial.

New option set::server-notice-show-event which can be set to no to hide the event information (e.g. connect.LOCAL_CLIENT_CONNECT) in server notices. This can be overridden per-oper in the Oper block via oper::server-notice-show-event.
Support for IRC over UNIX sockets (on the same machine), if you specify a file in the listen block instead of an ip/port. This probably won’t be used much, but the option is there. Users will show up with a host of localhost and IP 127.0.0.1 to keep things simple.
The MAP command now shows percentages of users
Add WHO option to search clients by time connected (e.g. WHO <300 t to search for less than 300 seconds)
Rate limiting of MODE nick -x and -t via new vhost-flood option in set::anti-flood block.

Changes

Update Russian help.ru.conf.

Protocol

SVSMODE #chan -b nick will now correctly remove extbans that prevent nick from joining. This fixes a bug where it would remove too much (for ~time) or not remove extbans (most other extbans, e.g. ~account). SVSMODE #chan -b has also been fixed accordingly (remove all bans preventing joins). Note that all these commands do not remove bans that do not affect joins, such as ~quiet or ~text.

UnrealIRCd 6.0.1.1

Fixes

In 6.0.1.1: extended bans were not properly synced between U5 and U6. This caused missing extended bans on the U5 side (MODE was working OK, this only happened when linking servers)
Text extbans did not have any effect (+b ~text:censor:*badword*)
Timed bans were not expiring if all servers on the network were on U6
Channel mode +f could place a timed extban with ~t instead of ~time
Crash when unloading any of the vhoaq modules at runtime
Some log messages being wrong (CHGIDENT, CHGNAME)
Remove confusing high cpu load warning

Enhancements

Error on unknown snomask in set::snomask-on-oper and oper::snomask.
TKL add/remove/expire messages now show [duration: 60m] instead of the [expires: ZZZ GMT] string since that is what people are more interested in and is not affected by time zones. The format in all the 3 notices is also consistent now.

UnrealIRCd 6.0.0

Many thanks (by upstream) to k4be for his help during development, other contributors for their feedback and patches, the people who tested the beta’s and release candidates, translators and everyone else who made this release happen!

Summary

UnrealIRCd 6 comes with a completely redone logging system (with optional JSON support), named extended bans, four new IRCv3 features, geoip support and remote includes support built-in.

Additionally, things are more customizable such as what gets sent to which snomask. All the +vhoaq channel modes are now modular as well, handy for admins who don’t want or need halfops or +q/+a. For WHOIS it is now customizable in detail who gets to see what.

A summary of the features is available at What’s new in UnrealIRCd 6. For complete information, continue reading the release notes below. The sections below contain all the details.

Upgrading from UnrealIRCd 5

When upgrading from UnrealIRCd 5 to 6 then you can use your existing configuration and files. There’s no need to start from scratch. However, you will need to make a few updates, see Upgrading from 5.x to 6.x.

Enhancements

Completely new log system and snomasks overhaul
Both logging and snomask sending is done by a single logging function
Support for JSON logging to disk, instead of the default text format. JSON logging adds lot of detail to log messages and consistently expands things like client with properties like hostname, connected_since, reputation, modes, etc.
The JSON data is also sent to all IRCOps who request the unrealircd.org/json-log capability. The data is then sent in a message-tag called unrealircd.org/json-log. This makes it ideal for client scripts and bots to do automated things.
A new style log { } block is used to map what log messages should be logged to disk, and which ones should be sent to snomasks.
The default logging to snomask configuration is in snomasks.default.conf which everyone should include from unrealircd.conf. That is, unless you wish to completely reconfigure which logging goes to which snomasks yourself, which is also an option now.
See Snomasks on the new snomasks – lots of letters changed!
See FAQ: Converting log { } block on how to change your existing log { } blocks for disk logging.
We now have a consistent log format and log messages can be multiline.
Colors are enabled by default in snomask server notices, these can be disabled via set::server-notice-colors and also in oper::server-notice-colors
Support for logging to a channel. Similar to snomasks but then for channels. Requires UnrealIRCd 6.0.2 or later

Almost all channel modes are modularized
Only the three list modes (+b/+e/+I) are still in the core
The five level modes (+vhoaq) are now also modular. They are all loaded by default but you can blacklist one or more if you don’t want them. For example to disable halfop: blacklist-module chanmodes/halfop;
Support for compiling without PREFIX_AQ has been removed because people often confused it with disabling +a/+q which is something different.

Named extended bans
Extbans now no longer show up with single letters but with names. For example +b ~c:#channel is now +b ~channel:#channel.
Extbans are automatically converted from the old to the new style, both from clients and from/to older UnrealIRCd 5 servers. The auto-conversion also works fine with complex extbans such as +b ~t:5:~q:nick!user@host to +b ~time:5:~quiet:nick!user@host.

New IRCv3 features
MONITOR: an alternative for WATCH to monitor other users (“notify list”).
draft/extended-monitor: extensions for MONITOR, still in draft.
invite-notify: report channel invites to other chanops (or users) in a machine readable way.
setname: notify clients about realname (gecos) changes.

GeoIP lookups can be configured
This shows the country of the user to IRCOps in WHOIS and in the “user connecting” line.
By downstream default, no module is loaded.
Options are the geoip_maxmind and geoip_csv modules.

Configure WHOIS output in a very precise way
You can now decide which fields (e.g. modes, geo, certfp, etc) you want to expose to who (everyone, self, oper).
See set::whois-details for more details.

We now ship with 3 cloaking modules and you need to load 1 explicitly via loadmodule:
cloak_sha256: the recommended module for anyone starting a new network. It uses the SHA256 algorithm under the hood.
cloak_md5: for anyone who is upgrading their network from older UnrealIRCd versions. Use this so your cloaked host bans remain the same.
cloak_none: if you don’t want any cloaking, not even as an option to your users (rare)

Remote includes are now supported everywhere in the config file.
Support for https:// fetching is now always available, even if you don’t compile with libcurl support.
Anywhere an URL is encountered on its own, it will be fetched automatically. This makes it work not only for includes and motd (which was already supported) but also for any other file.
To prevent something from being interpreted as a remote include URL you can use ‘value’ instead of “value”.

Invite notification: set set::normal-user-invite-notification yes; to make chanops receive information about normal users inviting someone to their channel. The name of this setting may change in a later version.
Websocket: you can add a listen::options::websocket::forward 1.2.3.4 option to make unrealircd accept a Forwarded (RFC 7239) header from a reverse proxy connecting from 1.2.3.4 (plans to accept legacy X-Forwarded-For and a proxy password too). This feature is currently experimental.

Changes

TLS cipher and some other information is now visible for remote clients as well, also in [secure: xyz] connect line.
Error messages in remote includes use the url instead of a temporary file
Downgrading from UnrealIRCd 6 is only supported down to 5.2.0 (so not lower like 5.0.x). If this is a problem then make a copy of your db files (e.g.: reputation.db).

Removed

/REHASH -motd and -opermotd are gone, just use /REHASH

Breaking changes

See https://www.unrealircd.org/docs/Upgrading_from_5.x, but in short:

You can use the unrealircd.conf from UnrealIRCd 5, but you need to make a few changes:

You need to add include “snomasks.default.conf”;
You need to load a cloaking module explicitly. Assuming you already have a network then add: loadmodule “cloak_md5”;
The log block(s) need to be updated, use something like:

log {
source {
!debug;
all;
}
destination {
file “ircd.log” { maxsize 100M; }
}
}

Server protocol

When multiple related SJOIN messages are generated for the same channel then we now only send the current channel modes (e.g. +sntk key) in the first SJOIN and not in the other ones as they are unneeded for the immediate followup SJOINs, they waste unnecessary bytes and CPU. Such messages may be generated when syncing a channel that has dozens of users and/or bans/exempts/invexes. Ideally this should not need any changes in other software, since we already supported such messages in the past and code for handling it exists way back to 3.2.x, but you better check to be sure!
If you send PROTOCTL NEXTBANS then you will receive extended bans with Named EXTended BANs instead of letters (e.g.: +b ~account:xyz), otherwise you receive them with letters (e.g.: +b ~a:xyz).
Some ModData of users is (also) communicated in the UID message while syncing using a message tag that only appears in server-to-server traffic, s2s-md/moddataname=value. Thus, data such as operinfo, tls cipher, geoip, certfp, sasl and webirc is communicated at the same time as when a remote connection is added. This makes it that a “connecting from” server notice can include all this information and also so code can make an immediate decission on what to do with the user in hooks. ModData modules need to set mreq.sync = MODDATA_SYNC_EARLY; if they want this. Servers of course need to enable MTAGS in PROTOCTL to see this.
The SLOG command is used to broadcast logging messages. This is done for log::destination remote, as used in doc/conf/snomasks.default.conf, for example for link errors, oper ups, flood messages, etc. It also includes all JSON data in a message tag when PROTOCTL MTAGS is used.
Bounced modes are gone: these were MODEs that started with a & which servers were to act on with reversed logic (add becoming remove and vice versa) and never to send something back to that server. In practice this was almost never used and complicated the code (way) too much.

Client protocol

Extended bans now have names instead of letters. If a client sends the old format with letters (e.g. +b ~a:XYZ) then the server will convert it to the new format with names (e.g.: +b ~account:XYZ)
Support for MONITOR and the other IRCv3 features (see Enhancements)

Read More