Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO<br /> <br /> Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide<br /> by zero error"), we also need to prevent that same crash from happening<br /> in the udlfb driver as it uses pixclock directly when dividing, which<br /> will crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: fireworks: bound device-supplied status before string array lookup<br /> <br /> The status field in an EFW response is a 32-bit value supplied by the<br /> firewire device. efr_status_names[] has 17 entries so a status value<br /> outside that range goes off into the weeds when looking at the %s value.<br /> <br /> Even worse, the status could return EFR_STATUS_INCOMPLETE which is<br /> 0x80000000, and is obviously not in that array of potential strings.<br /> <br /> Fix this up by properly bounding the index against the array size and<br /> printing "unknown" if it&amp;#39;s not recognized.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usx2y: us144mkii: fix NULL deref on missing interface 0<br /> <br /> A malicious USB device with the TASCAM US-144MKII device id can have a<br /> configuration containing bInterfaceNumber=1 but no interface 0. USB<br /> configuration descriptors are not required to assign interface numbers<br /> sequentially, so usb_ifnum_to_if(dev, 0) returns will NULL, which will<br /> then be dereferenced directly.<br /> <br /> Fix this up by checking the return value properly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: digital: Bounds check NFC-A cascade depth in SDD response handler<br /> <br /> The NFC-A anti-collision cascade in digital_in_recv_sdd_res() appends 3<br /> or 4 bytes to target-&gt;nfcid1 on each round, but the number of cascade<br /> rounds is controlled entirely by the peer device. The peer sets the<br /> cascade tag in the SDD_RES (deciding 3 vs 4 bytes) and the<br /> cascade-incomplete bit in the SEL_RES (deciding whether another round<br /> follows).<br /> <br /> ISO 14443-3 limits NFC-A to three cascade levels and target-&gt;nfcid1 is<br /> sized accordingly (NFC_NFCID1_MAXSIZE = 10), but nothing in the driver<br /> actually enforces this. This means a malicious peer can keep the<br /> cascade running, writing past the heap-allocated nfc_target with each<br /> round.<br /> <br /> Fix this by rejecting the response when the accumulated UID would exceed<br /> the buffer.<br /> <br /> Commit e329e71013c9 ("NFC: nci: Bounds check struct nfc_target arrays")<br /> fixed similar missing checks against the same field on the NCI path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()<br /> <br /> A malicious USB device claiming to be a CDC Phonet modem can overflow<br /> the skb_shared_info-&gt;frags[] array by sending an unbounded sequence of<br /> full-page bulk transfers.<br /> <br /> Drop the skb and increment the length error when the frag limit is<br /> reached. This matches the same fix that commit f0813bcd2d9d ("net:<br /> wwan: t7xx: fix potential skb-&gt;frags overflow in RX path") did for the<br /> t7xx driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: initialize le_tmp64 in rtw_BIP_verify()<br /> <br /> Initialize le_tmp64 to zero in rtw_BIP_verify() to prevent using<br /> uninitialized data.<br /> <br /> Smatch warns that only 6 bytes are copied to this 8-byte (u64)<br /> variable, leaving the last two bytes uninitialized:<br /> <br /> drivers/staging/rtl8723bs/core/rtw_security.c:1308 rtw_BIP_verify()<br /> warn: not copying enough bytes for &amp;#39;&amp;le_tmp64&amp;#39; (8 vs 6 bytes)<br /> <br /> Initializing the variable at the start of the function fixes this<br /> warning and ensures predictable behavior.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: alps: fix NULL pointer dereference in alps_raw_event()<br /> <br /> Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event<br /> callbacks missing them") attempted to fix up the HID drivers that had<br /> missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:<br /> Fix potential NULL dereference at raw event handle"), but the alps<br /> driver was missed.<br /> <br /> Fix this up by properly checking in the hid-alps driver that it had been<br /> claimed correctly before attempting to process the raw event.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix OOB reads parsing symlink error response<br /> <br /> When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message()<br /> returns success without any length validation, leaving the symlink<br /> parsers as the only defense against an untrusted server.<br /> <br /> symlink_data() walks SMB 3.1.1 error contexts with the loop test "p ErrorId at offset 4 and p-&gt;ErrorDataLength at offset<br /> 0. When the server-controlled ErrorDataLength advances p to within 1-7<br /> bytes of end, the next iteration will read past it. When the matching<br /> context is found, sym-&gt;SymLinkErrorTag is read at offset 4 from<br /> p-&gt;ErrorContextData with no check that the symlink header itself fits.<br /> <br /> smb2_parse_symlink_response() then bounds-checks the substitute name<br /> using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from<br /> iov_base. That value is computed as sizeof(smb2_err_rsp) +<br /> sizeof(smb2_symlink_err_rsp), which is correct only when<br /> ErrorContextCount == 0.<br /> <br /> With at least one error context the symlink data sits 8 bytes deeper,<br /> and each skipped non-matching context shifts it further by 8 +<br /> ALIGN(ErrorDataLength, 8). The check is too short, allowing the<br /> substitute name read to run past iov_len. The out-of-bound heap bytes<br /> are UTF-16-decoded into the symlink target and returned to userspace via<br /> readlink(2).<br /> <br /> Fix this all up by making the loops test require the full context header<br /> to fit, rejecting sym if its header runs past end, and bound the<br /> substitute name against the actual position of sym-&gt;PathBuffer rather<br /> than a fixed offset.<br /> <br /> Because sub_offs and sub_len are 16bits, the pointer math will not<br /> overflow here with the new greater-than.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_phonet: fix skb frags[] overflow in pn_rx_complete()<br /> <br /> A broken/bored/mean USB host can overflow the skb_shared_info-&gt;frags[]<br /> array on a Linux gadget exposing a Phonet function by sending an<br /> unbounded sequence of full-page OUT transfers.<br /> <br /> pn_rx_complete() finalizes the skb only when req-&gt;actual length,<br /> where req-&gt;length is set to PAGE_SIZE by the gadget. If the host always<br /> sends exactly PAGE_SIZE bytes per transfer, fp-&gt;rx.skb will never be<br /> reset and each completion will add another fragment via<br /> skb_add_rx_frag(). Once nr_frags exceeds MAX_SKB_FRAGS (default 17),<br /> subsequent frag stores overwrite memory adjacent to the shinfo on the<br /> heap.<br /> <br /> Drop the skb and account a length error when the frag limit is reached,<br /> matching the fix applied in t7xx by commit f0813bcd2d9d ("net: wwan:<br /> t7xx: fix potential skb-&gt;frags overflow in RX path").

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ncm: validate minimum block_len in ncm_unwrap_ntb()<br /> <br /> The block_len read from the host-supplied NTB header is checked against<br /> ntb_max but has no lower bound. When block_len is smaller than<br /> opts-&gt;ndp_size, the bounds check of:<br /> ndp_index &gt; (block_len - opts-&gt;ndp_size)<br /> will underflow producing a huge unsigned value that ndp_index can never<br /> exceed, defeating the check entirely.<br /> <br /> The same underflow occurs in the datagram index checks against block_len<br /> - opts-&gt;dpe_size. With those checks neutered, a malicious USB host can<br /> choose ndp_index and datagram offsets that point past the actual<br /> transfer, and the skb_put_data() copies adjacent kernel memory into the<br /> network skb.<br /> <br /> Fix this by rejecting block lengths that cannot hold at least the NTB<br /> header plus one NDP. This will make block_len - opts-&gt;ndp_size and<br /> block_len - opts-&gt;dpe_size both well-defined.<br /> <br /> Commit 8d2b1a1ec9f5 ("CDC-NCM: avoid overflow in sanity checking") fixed<br /> a related class of issues on the host side of NCM.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: renesas_usb3: validate endpoint index in standard request handlers<br /> <br /> The GET_STATUS and SET/CLEAR_FEATURE handlers extract the endpoint<br /> number from the host-supplied wIndex without any sort of validation.<br /> Fix this up by validating the number of endpoints actually match up with<br /> the number the device has before attempting to dereference a pointer<br /> based on this math.<br /> <br /> This is just like what was done in commit ee0d382feb44 ("usb: gadget:<br /> aspeed_udc: validate endpoint index for ast udc") for the aspeed driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: avoid double-free in smbd_free_send_io() after smbd_send_batch_flush()<br /> <br /> smbd_send_batch_flush() already calls smbd_free_send_io(),<br /> so we should not call it again after smbd_post_send()<br /> moved it to the batch list.