The documentation specifies that the BTGATTPERMREADLESC and BTGATTPERMWRITELESC defines for a Bluetooth characteristic: Attribute read/write permission with LE Secure Connection encryption. If set, requires that LE Secure Connections is used for read/write access, however this is only true when it is combined with other permissions, namely BTGATTPERMREADENCRYPT/BTGATTPERMREADAUTHEN (for read) or BTGATTPERMWRITEENCRYPT/BTGATTPERMWRITEAUTHEN (for write), if these additional permissions are not set (even in secure connections only mode) then the stack does not perform any permission checks on these characteristics and they can be freely written/read.
In Zephyr's Bluetooth Mesh PB-ADV provisioning bearer (subsys/bluetooth/mesh/pbadv.c), provmsgrecv() rescheduled the provisioning protocol watchdog timer unconditionally at the top of the function, before the FCS check and before the ADVLINKINVALID check. Once a provisioning attempt fails, provfailed() sets ADVLINKINVALID and the only recovery path is the protocol timer firing (protocoltimeout -> provlinkclose -> closelink -> resetadvlink and re-enabling of scanning and the unprovisioned device beacon).
A remote, unauthenticated attacker on the BLE advertising channel can first induce a provisioning failure (e.g. with a malformed generic-provisioning PDU) and then transmit any FCS-valid PB-ADV transaction PDU on the same link ID more often than once per protocol timeout (60 s, or 120 s for OOB input/output). Because each such packet reset the timer even on an invalidated link, protocoltimeout never fired, the dead link was never torn down, and the device remained pinned in an un-provisionable state with its unprovisioned beacon disabled and new Link Open requests rejected.
PB-ADV PDUs are processed without authentication and the FCS is a keyless CRC, so no pairing or prior trust is required and the attacker chooses the link ID itself. The impact is a persistent denial of provisioning/re-provisioning service; there is no memory-safety, confidentiality, or integrity impact.
The vulnerable code shipped in releases through v4.4.1. The fix moves the timer reschedule to after the ADVLINKINVALID check (and the FCS check before the reset) so an invalidated link can no longer be kept alive by incoming packets.
The Zephyr ext2 file system validates the on-disk superblock in ext2verifydisksuperblock() (subsys/fs/ext2/ext2impl.c) before completing a mount. The validator checked the magic number, block size, revision and feature flags, but did not verify that the on-disk fields sblockspergroup and sinodespergroup are non-zero. Both fields are read directly from the image and are later used as divisors during mount-time initialization.
During mount, getngroups() divides and modulos sblockscount by sblockspergroup (reached via ext2fetchblockgroup() from ext2initfs()), and getitableentry() divides (ino - 1) by sinodespergroup when fetching the root inode (both in subsys/fs/ext2/ext2diskops.c). A superblock with either field set to zero therefore causes an integer division by zero during the mount sequence.
An attacker who can present a crafted ext2 image to a device that mounts ext2 — removable media such as an SD card or a USB mass-storage device — can trigger this. On ARMv7-M / ARMv8-M-mainline Cortex-M targets, divide-by-zero trapping is enabled (SCBCCRDIV0TRP), so the division raises a UsageFault that Zephyr treats as a fatal error, producing a denial of service. The impact is limited to availability; the malformed value is consumed only as a divisor.
The fix rejects a zero sblockspergroup or sinodespergroup in the superblock validator, returning -EINVAL so the mount fails before any block-group or inode I/O occurs.