In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix reference count leak in rxrpc_server_keyring()
This patch fixes a reference count leak in rxrpc_server_keyring()
by checking if rx->securities is already set.
In the Linux kernel, the following vulnerability has been resolved:
fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO
Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide
by zero error"), we also need to prevent that same crash from happening
in the udlfb driver as it uses pixclock directly when dividing, which
will crash.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: fireworks: bound device-supplied status before string array lookup
The status field in an EFW response is a 32-bit value supplied by the
firewire device. efr_status_names[] has 17 entries so a status value
outside that range goes off into the weeds when looking at the %s value.
Even worse, the status could return EFR_STATUS_INCOMPLETE which is
0x80000000, and is obviously not in that array of potential strings.
Fix this up by properly bounding the index against the array size and
printing "unknown" if it's not recognized.
In the Linux kernel, the following vulnerability has been resolved:
NFC: digital: Bounds check NFC-A cascade depth in SDD response handler
The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3
or 4 bytes to target->nfcid1 on each round, but the number of cascade
rounds is controlled entirely by the peer device. The peer sets the
cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the
cascade-incomplete bit in the SEL_RES (deciding whether another round
follows).
ISO 14443-3 limits NFC-A to three cascade levels and target->nfcid1 is
sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver
actually enforces this. This means a malicious peer can keep the
cascade running, writing past the heap-allocated nfc_target with each
round.
Fix this by rejecting the response when the accumulated UID would exceed
the buffer.
Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays")
fixed similar missing checks against the same field on the NCI path.
In the Linux kernel, the following vulnerability has been resolved:
net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()
A malicious USB device claiming to be a CDC Phonet modem can overflow
the skb_shared_info->frags[] array by sending an unbounded sequence of
full-page bulk transfers.
Drop the skb and increment the length error when the frag limit is
reached. This matches the same fix that commit f0813bcd2d9d ("net:
wwan: t7xx: fix potential skb->frags overflow in RX path") did for the
t7xx driver.
In the Linux kernel, the following vulnerability has been resolved:
HID: core: clamp report_size in s32ton() to avoid undefined shift
s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device. The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32()
does.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()
Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using
uninitialized data.
Smatch warns that only 6 bytes are copied to this 8-byte (u64)
variable, leaving the last two bytes uninitialized:
drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify()
warn: not copying enough bytes for '&le_tmp64' (8 vs 6 bytes)
Initializing the variable at the start of the function fixes this
warning and ensures predictable behavior.
In the Linux kernel, the following vulnerability has been resolved:
smb: server: avoid double-free in smb_direct_free_sendmsg after smb_direct_flush_send_list()
smb_direct_flush_send_list() already calls smb_direct_free_sendmsg(),
so we should not call it again after post_sendmsg()
moved it to the batch list.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: avoid double-free in smbd_free_send_io() after smbd_send_batch_flush()
smbd_send_batch_flush() already calls smbd_free_send_io(),
so we should not call it again after smbd_post_send()
moved it to the batch list.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: renesas_usb3: validate endpoint index in standard request handlers
The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint
number from the host-supplied wIndex without any sort of validation.
Fix this up by validating the number of endpoints actually match up with
the number the device has before attempting to dereference a pointer
based on this math.
This is just like what was done in commit ee0d382feb44 ("usb: gadget:
aspeed_udc: validate endpoint index for ast udc") for the aspeed driver.